[12:19] <DSG> hi
[12:58] <j_baer> I'm new to launchpad, is there a good learning resource available?
[01:00] <DSG> hello
[01:01] <j_baer> hello ...
[01:01] <DSG> I'm downloading ubuntu
[01:02] <j_baer> That's great how is it going?
[01:02] <DSG> good
[01:03] <DSG> but
[01:03] <DSG> i don't know how install it
[01:03] <j_baer> The installation is really easy from the live CD.
[01:04] <DSG> i ordered
[01:04] <j_baer> When the download is complete, burn the ISO to CD and then boot.
[01:05] <j_baer> I'm sorry, you orderd ...
[01:05] <DSG> sorry i don't speak much english
[01:06] <j_baer> Ok, how may I help u ?
[01:07] <DSG> i downloaded gentoo and i burned but don't make nothing
[01:07] <j_baer> I'm not familiar with Gentoo ...
[01:08] <DSG> gentoo is a linux distributor
[01:09] <DSG> the readme say burn the iso
[01:09] <DSG> and i do it
[01:10] <DSG> but don't make nothing
[01:10] <j_baer> Is the desktop KDE?
[01:10] <DSG> yes
[01:11] <j_baer> Did you use K3B?
[01:11] <DSG> no
[01:12] <DSG> what is K3B ??
[01:12] <j_baer> K3B is the CD burning program for KDE.
[01:13] <DSG> i use nero
[01:16] <j_baer> You should be able to right click the ISO file and be presented with "Burn To CD" option.
[01:17] <DSG> I ordered ubuntu
[01:18] <DSG> i ordered ubuntu in ubuntu.com
[01:21] <DSG> hellooooooooooooooo
[01:26] <DSG> some motherfucker here ??????
[05:06] <jamesh> stub: I guess I'd need another apache redirection to handle librarian.demo.launchpad.net
[05:08] <stub> Ahh... yes
[05:08] <stub> Shall I RT it?
[05:08] <stub> Or we can just run with http://carbon.ubuntu.com:666 
[05:11] <jamesh> would that get through the data centre firewall?
[05:11] <stub> Maybe ;)
[05:12] <stub> I can't remember if we are using Librarian SSL yet
[05:12] <stub> What port are you running the librarian on? I'll RT it anyway.
[05:13] <jamesh> 8000 (same as production)
[05:14] <jamesh> cron jobs on chinstrap seem to have borked again
[05:25] <jamesh> lifeless: no cron jobs on chinstrap again, so rocketfuel-built isn't being updated
[05:26] <lifeless> jamesh: care to RT it flagged as urgent ?
[05:26] <jamesh> lifeless: I sent a mail in reply to my previous RT request.  Would it be better to file another?
[05:27] <lifeless> I would file a new one, as the old would have been closed.
[05:27] <jamesh> fair enough
[05:29] <stub> I think RT is down again :-(
[05:29] <jamesh> looks like chinstrap was restarted over the weekend, which is probably related
[05:31] <lifeless> elmo: perchance you are around ? ^^ 
[05:32] <mpt> Gooooooooooooooooooooooooood afternoon Launchpadders!
[05:34] <jamesh> lifeless: okay.  sent anotherone
[05:40] <mpt> Wow, 68412 items in the import queue?
[05:40] <mpt> (for Rosetta)
[08:41] <SteveA> morning
[08:41] <SteveA> lifeless: pqm processed a request of mine from last night.  the merge went through, but I received no "success" message.
[08:43] <lifeless> SteveA: I have no idea why.
[08:43] <lifeless> SteveA: probably dc glitches - there was a mail outage @ubuntu.com in some manner
[09:24] <jamesh> stub: cool.  That'll include the branch scanner fixes (I guess there is no point in cherry picking them now)
[09:48] <carlos> morning
[09:49] <carlos> stub: hi, did you migrate POSubmission duplicates ?
[09:50] <stub> carlos: no
[09:53] <carlos> any chance to get that done today or tomorrow?
[09:53] <stub> Yes. Tomorrow definitely. Hopefully this evening.
[09:58] <carlos> ok, thanks
[10:06] <SteveA> lifeless: the "success" mail came through eventually
[10:22] <SteveA> jamesh: hi
[10:22] <jamesh> hi SteveA 
[10:22] <SteveA> jamesh: great work on the python bug imports. 
[10:22] <SteveA> I'd like you to put the zope specs on the same server
[10:22] <jamesh> good idea
[10:23] <SteveA> we can add the relevant zope people to the mail whitelist too
[10:23] <jamesh> we'll need to set up the relevant cron jobs for the demo server
[10:24] <jamesh> and I guess another POP box if we want the incomming email interface to function
[10:35] <SteveA> right
[10:35] <SteveA> stub: what have you asked the admins to set up so far for the demo server?
[10:35] <stub> outstanding or everything?
[10:35] <stub> I forgot about the POP box
[10:35] <stub> rt13853, rt14018, rt14265
[10:35] <jamesh> I only just thought of the POP box now
[10:36] <stub> plus accounts for jamesh and sudo access, for which I've lost the rt job numbers
[10:38] <SteveA> we have two weeks left for the challenge, but it would be good to get this running very soon, so that we can get feedback from the tech committee
[10:38] <SteveA> and have an opportunity to respond to it
[10:38] <SteveA> before the deadline
[10:41] <jamesh> SteveA: okay.  So we need to decide which bits are necessary for announcing our entry
[10:41] <jamesh> SteveA: some of these things could be done after the entry (like the keyword stuff): we just need to give an approximate timeframe
[10:41] <SteveA> yes
[10:42] <SteveA> although, we can't expect them to take keywords into account if they aren't available to see before the deadline
[10:44] <jamesh> Sure.  Are we in a position to get all this stuff done by the deadline?
[10:48] <SteveA> the minimum is to get stuff running on the demo server without keywords
[10:49] <SteveA> we should talk with Znarl about how this can be fitted into the current sysadmin work
[10:52] <stub> The admins seem fine on this - the only outstanding requests are the email whitelist and the librarian redirect (which was only requested today).
[10:52] <SteveA> cool
[10:56] <SteveA> stub: there's something odd going on on staging with the spec dependency trees.  I'm looking into it.  The images are rendered, but not included in a page.
[11:00] <SteveA> stub: just spoke to mark, and that' show it is meant to work
[11:02] <stub> Hmm
[11:11] <jamesh> https://blueprint.staging.launchpad.net/distros/ubuntu/+spec/ue-partitioning-tool <- the graph seems to look okay here
[11:11] <SteveA> jamesh: yep.  I was confused becuase a  spec with no dependencies/blockers doesn't have a graph
[11:12] <SteveA> So, I saw it, and thought "oh, the graphs aren't rendering"
[11:19] <jamesh> might be worth doing some tweaking for graphs like https://blueprint.staging.launchpad.net/distros/ubuntu/+spec/kubuntu-express
[11:21] <SteveA> yes
[11:21] <SteveA> two things are happening about that
[11:22] <SteveA> 1. the nodes will be getting smaller with the latest RF, as the node name will be on one line, and the (assignee) on the next
[11:22] <SteveA> 2. currently with PQM is a patch to add a page to give you the DOT output of the spec graph, so we can take that and experiment doing constraints / partial layouts to try and improve graphs we see in production
[11:25] <jamesh> if we do end up with performance issues with the graphs, a good approach would be to look at caching the results based on a hash of the dot input file (since identical input should result in identical output)
[11:26] <jamesh> which would probably be faster than having a long running daemon
[11:31] <SteveA> jamesh: that would work, as I was quite careful to give predictably sorted output, for writing the tests
[11:35] <carlos> danilos: hi, around?
[11:43] <mpt> SteveA, if the diagrams only ever show one level of dependency in each direction, it would be safer to arrange the levels horizontally rather than vertically
[11:44] <mpt> since there wouldn't be more than three of them
[11:45] <SteveA> they don't show only one level
[11:45] <SteveA> are you proposing that they should?
[11:45] <mpt> no, but the two I've seen so far do
[11:46] <SteveA> jordi: ping
[11:47] <mpt> yay, timeout
[11:48] <SteveA> mpt: that's kind of opaque.  is it an interseting timeout?
[11:50] <mpt> Only in the sense that it's the first two timeouts I've seen in several months
[11:50] <mpt> but it's on staging, so maybe matsubara hasn't tweaked the limit yet
[11:51] <mpt> matsubara's work has been paying off
[11:51] <danilos> carlos: yeah, back in a min again
[12:04] <lifeless> spiv: jamesh: SteveA: bzr-launchpad meeting time
[12:11] <jamesh> okay
[12:12] <stub> mpt: matsubara has tweaked the timeout
[12:13] <stub> Is there a process lock ensuring only one graph renders at a time? It might take a long time to render a graph for a spec with a more complex dependency tree.
[12:13] <SteveA> there is no lock
[12:14] <SteveA> what would be the point?
[12:17] <SteveA> stub: I'd like to get staging updated to RF latest rev
[12:17] <SteveA> any objection?
[12:17] <stub> Nope
[12:18] <SteveA> is there a script to run?
[12:25] <stub> It is triggered from Jubany normally. Instructions are on the wiki...
[12:26] <stub> https://launchpad.canonical.com/StagingServerUpdate
[12:39] <spiv> Hmm, there's a /people/$name/+branchlisting at the moment (similar to /product/$name/+branchlisting), but no links to it.
[12:39] <spiv> I'm tempted to remove it entirely.
[12:40] <lifeless> spiv: no links ?
[12:40] <doko> spiv: do you know, if the patch for 48301 is already in the 2.4 branch?
[12:40] <lifeless> spiv: not even from an authored branch or what have you ?
[12:41] <spiv> lifeless: not that I can find.
[12:41] <jamesh> spiv: seems to have been superceded by /people/$name/+branches
[12:41] <lifeless> spiv: also, is it a compact list, or a details list ?
[12:41] <spiv> doko: not afaik
[12:41] <spiv> lifeless: it's the details list.
[12:41] <spiv> lifeless: what you get if you click "Listing View" from /product/$name/+branches
[12:41] <spiv> Except there's no "Listing View" link from /people/$name/+branches.
[12:42] <spiv> jamesh: Yeah, I guess so.
[12:43] <spiv> Anyway, I noticed this while updating pagetests/branches to use new-style page tests.
[12:43] <spiv> (while fixing those tests for ddaa's branch-ui changes)
[12:43] <spiv> Any objections to me just removing that?
[12:44] <spiv> Didn't think so ;)
[12:55] <lifeless> review meeting in 5
[12:56] <lifeless> spiv: I'd rather add it as a Listing View link :)
[12:56] <lifeless> spiv: predictability ;)
[12:56] <spiv> lifeless: Hmm.
[12:56] <lifeless> or remove the other. 6/1 1/2 of the other
[12:56] <spiv> lifeless: And then do the same for authored, registered, and subscribed branches?
[12:57] <spiv> So have a +authoredbranchlisting, etc?
[12:57] <lifeless> noidea
[12:57] <lifeless> seems like something to be datadriven to me
[12:57] <spiv> :)
[12:57] <spiv> Perhaps.
[12:57] <lifeless> +branchlisting?show=authored
[12:57] <spiv> At the moment, we have +authoredbranches, etc, though.
[12:58] <lifeless> yup
[12:58] <jamesh> lifeless: it is the same view class and page template behind those different branch listing pages
[12:58] <lifeless> jamesh: I do realise that
[12:58] <lifeless> :)
[12:58] <spiv> I mainly just want to land David's branch-ui branch.
[12:58] <lifeless> just as a user, its kinda weird, and there are namespace issues to fit all the permutations in
[12:59] <lifeless> spiv: well, there are not all those permutations on the branches side.
[12:59] <lifeless> spiv: I'm just saying keep the two sides - product and people - in sync
[12:59] <spiv> So I'm going to take the easy option, and assume that seeing as no-one has missed the lack of a link to +branchlisting that it doesn't really matter.
[12:59] <spiv> Well, they're already out of sync.
[01:00] <lifeless> your call
[01:00] <spiv> The task of "just land ddaa's simple UI branch" is at risk of massive feature creep if I take that on :)
[01:00] <spiv> s/feature/scope/
[01:01] <lifeless> well
[01:01] <lifeless> deleting it is not a pre-req to landing
[01:01] <spiv> Sure.  But deleting the tests more-or-less is.
[01:02] <spiv> I'm unkeen on leaving a mess of half old-style/half new-style pagetests.
[01:02] <spiv> Perhaps the mistake was letting the scope creep include updating the tests to new-style, instead of merely making them pass ;)
[01:03] <spiv> Anyway, I'll remove the offending tests, file bugs, and move on.
[01:03] <spiv> Also, review meeting!
[01:04] <lifeless> I think you have pinpointed the mistake.
[01:04] <lifeless> review meeting.
[01:04] <lifeless> who art here ?
[01:04] <BjornT> me
[01:04] <jamesh> me
[01:05] <lifeless> ok
[01:06] <spiv> me
[01:06] <lifeless> ah cool
[01:06] <lifeless> so theres nothing explicit this week
[01:06] <lifeless> anyone got stuff to bring up before we look at the queue ?
[01:07] <lifeless> next meeting same bat-time, same bat-channel ?
[01:07] <salgado> I'm here too
[01:08] <spiv> Sounds good.
[01:08] <jamesh> sure.
[01:08] <lifeless> coolies
[01:08] <lifeless> queue status:
[01:08] <lifeless> 8 items in the queue
[01:08] <lifeless> 4 of which are > 3 days
[01:09] <spiv> I think kiko's already reviewed bradb/launchpad/malone-landscape-hack/ -- I saw mail on the review list, so I think he's been slack about updating the status.
[01:09] <lifeless> so that makes 3 @ 4 days
[01:10] <salgado> I've already reviewed cprov's archive-tools and danilo's bug-1788, but they need a second review. I'll do them today. and will probably review cprov/repository/launchpad/buildd-ui today too
[01:10] <lifeless> how is the review load ?
[01:10] <lifeless> 4 days means 2 in actual fact, given the weekend, so its at the upper end of what we aim for as a service level.
[01:12] <lifeless> salgado: ?
[01:12] <spiv> The load's been ok, I've had the impression it's been a little higher this last week or so, but then maybe that's just because I spent 2 hours reviewing 447 lines earlier today ;)
[01:13] <salgado> oh, sorry. I think the load has been fine
[01:13] <lifeless> ok.
[01:14] <lifeless> well, please keep an eye on the queue - and if you are not going to get something reviewed within 2 days, please be sure to bounce it to someone else
[01:14] <salgado> it took me too long to review danilos' branch, because I reviewed it with him on IRC, explaining lots of things about launchpad that he wasn't aware yet
[01:14] <lifeless> we have plenty of reviewers to share around, though I do think the load is up somewhat.
[01:16] <lifeless> any other business? 
[01:16] <lifeless> 5
[01:16] <SteveA> hi
[01:16] <lifeless> 4
[01:17] <SteveA> no comments from me
[01:17] <lifeless> 3
[01:18] <lifeless> 2
[01:18] <lifeless> 1
[01:18] <lifeless> meeting over, thanks for comin
[01:18] <SteveA> jamesh: https://blueprint.staging.launchpad.net/distros/ubuntu/+spec/kubuntu-express/+deptreedotfile
[01:19] <jamesh> SteveA: cool.
[01:22] <ivoks> hi
[01:23] <SteveA> jamesh: so, I had it set up with the dot file in vim, and a command   cat myfile.dot | dot -Tpng > out.png, and gqview looking at out.png
[01:23] <SteveA> gqview is clever enough to notice when the file changes
[01:23] <SteveA> and update its image
[01:23] <SteveA> hi ivoks 
[01:30] <carlos> ivoks: hi
[01:30] <carlos> ivoks: let me check...
[01:30] <ivoks> np
[01:35] <carlos> ivoks: where did you upload your file?
[01:35] <ivoks> in dapper
[01:35] <carlos> ok
[01:36] <ivoks> i fixed manualy most of the errors searching trough web interface
[01:36] <ivoks> so, all needs review can be droped
[01:37] <ivoks> but i'm planing to get some .pos, fix them while on vacation and upload them by the end of this month
[01:38] <carlos> could you tell me more or less last time you tried to upload?
[01:38] <ivoks> ummm... a week ago?
[01:38] <ivoks> i don't rembember exact date :/
[01:39] <carlos> ok, that's enough
[01:44] <ivoks> i can try again...
[01:46] <carlos> ivoks: your import failed
[01:46] <carlos> ivoks: and our system was not able to notify you about it (our fault)
[01:46] <carlos> ivoks: could you execute msgfmt -c -v yourfile.po
[01:46] <carlos> ?
[01:46] <ivoks> eh... but that happens to everything i upload :/
[01:46] <ivoks> sure
[01:47] <ivoks> warning: PO file header fuzzy
[01:47] <ivoks> warning: older versions of msgfmt will give an error on this
[01:47] <ivoks> that's it
[01:47] <ivoks> and 823 translated messages.
[01:48] <ivoks> so, it failed for ubuntu-docs (both server and desktop guid), gnome-applets, gnome-panel (iirc)...
[01:49] <carlos> hmm, the last one I see failing is ubuntu-docs
[01:49] <ivoks> right, that's the last i tried
[01:49] <carlos> with a 'string not terminated' error
[01:49] <ivoks> on others i gave up and did it manually
[01:50] <carlos> please, try again with the .po file you just validated
[01:50] <ivoks> sure
[01:50] <carlos> and if you don't get any confirmation email today, file a bug with that file attached
[01:50] <ivoks> ok
[01:50] <carlos> ivoks: thank you
[01:50] <ivoks> thank you
[01:51] <ivoks> ok, just uploaded
[01:53] <carlos> ok
[01:54] <carlos> mdke_: hi, around?
[01:57] <salgado> stub, ping
[02:00] <mdke_> carlos: yes
[02:01] <carlos> mdke_: never mind, I was talking with danilo and wanted to note you about him working now with me on Rosetta, but he just told me that you already know each other
[02:02] <mdke_> carlos: yes vaguely, that's great news!
[02:04] <danilos> mdke_: hi there :)
[02:05] <mdke_> very cool that you are working on rosetta now
[02:05] <danilos> mdke: yeah, it's cool, lets just see how it turns out for rosetta as well :)
[02:06] <danilos> hehe, thanks :)
[02:06] <mdke> ok, lunch
[02:07] <danilos> enjoy it
[02:12] <ploum> hello
[02:13] <ploum> can someone re-launch staging ?
[02:13] <ploum> (I don't remember if I must ping BjornT or someone else about this)
[02:17] <salgado> ploum, staging is rebuilt every day, so it's possible that it's being rebuilt right now. has it been down for a long time?
[02:17] <ploum> salgado: oh, I just saw it
[02:17] <ploum> but someone (I don't remember who) told me to tell here if staging is down
[02:19] <salgado> ploum, staging is running already. I can access it from here
[02:20] <ploum> indeed
[02:20] <ploum> so it was temporary
[02:20] <ploum> sorry
[02:27] <carlos> ploum: I did
[02:27] <ploum> thanks :-)
[02:27] <carlos> I mean
[02:27] <carlos> I I think I told you I can start it again
[02:27] <carlos> I didn't fixed it today
[02:27] <carlos> ;-)
[02:28] <ploum> ah ok, so it's a bit brighter ;-)
[02:28] <ploum> I was not sure
[02:28] <ploum> (I'm really bad at remember people on IRC)
[02:31] <carlos> ploum: me too, that's why I said 'I think I did' ;-)
[02:33] <LarstiQ> funny
[02:45] <carlos> see you later
[03:28] <jgi> hello everyone
[03:29] <jgi> jordi, hello
[03:29] <jgi> I've just uploaded a tarball of WengoPhone's po files for review
[03:30] <jordi> jgi: okay
[03:30] <jordi> let me have a look
[03:39] <jordi> jgi: any reason you upload an English file, or is that meant to be the template?
[03:39] <jgi> jordi, should the template contain only msg ids?
[03:39] <jordi> yes
[03:39] <jordi> it's typically named ".pot"
[03:40] <jgi>  ok, is it the same than a .po files but with msg strs empy and a .pot extension?
[03:40] <jordi> yes
[03:40] <jordi> the t is for template
[03:40] <jgi> ok
[03:40] <jgi> then I can upload a new tarball with only a .pot file and a fr.po
[03:40] <jordi> ok, I was just asking because we normally don't import English translations (that is a file with msgstr which are exactly the same as the msgids) because there's no poibnt
[03:40] <jordi> don't worry
[03:41] <jordi> I can approve this and make rosetta believe it's a pot file
[03:41] <jgi> ok, that would be good
[03:44] <jordi> ok
[03:44] <jgi> jordi, i'll be right back
[03:49] <jordi> jgi: voil! aThey are approved, and should appear soonish as imported
[03:49] <jgi> jordi: ok, I see there are templates here: https://launchpad.net/products/wengophone/trunk/+pots/qtwengophone/ , but there is no untranslated string. Is it normal?
[03:49] <jgi> jordi: and filtering translated strings show nothing too
[03:57] <jordi> jgi: it's being imported still I guess
[03:57] <jordi> wow my link is slow right now
[04:15] <jgi> jordi: how long does it take usually to import translations?
[04:18] <salgado> stub, I found a possible issue with that shipit constraint that checks the status and shipment. do you have some time to talk about it?
[04:19] <carlos> jgi: it depends on the amount of entries we have in the queue
[04:21] <jordi> jgi: should be in now
[04:22] <jordi> actually, your files failed.
[04:22] <jordi> You should have got an email
[04:22] <jordi> carlos: duplicate entries. 
[04:22] <jordi> qtwengophone_en.po:124: duplicate message definition
[04:22] <jordi> qtwengophone_en.po:65: ...this is the location of the first definition
[04:24] <carlos> jordi: with that kind of failures we don't send an email (yet)
[04:24] <jordi> oh ok
[04:25] <cprov> stub: ping
[04:27] <jgi> jordi, carlos: actually i got an e-mail indeed
[04:27] <jordi> jgi: that gettext error is fatal
[04:27] <jordi> how are you generating your files?
[04:28] <jgi> jordi: using ts2po
[04:28] <jordi> hm, carlos, do you know any remedy for this?
[04:30] <jgi> jordi: which are the duplicate messages?
[04:30] <stub> cprov: pong
[04:31] <cprov> stub: do you have some minutes to perform the DBA request I did ?
[04:31] <carlos> jordi: fixing the duplicates ;-)
[04:31] <jordi> jgi: msgfmt -cCv yourfile.po
[04:32] <jordi> carlos: why does ts2po do this?
[04:32] <jordi> it generates unvaild files apparently
[04:32] <carlos> jordi: I don't know what's ts2po
[04:32] <danilos> jordi: most of the tools for OOo and Firefox do that as well... just pass them through msguniq
[04:33] <jordi> converts from Qt translation files to po
[04:33] <jordi> danilos: *nod*. Is tjhere a reason they do this?
[04:33] <danilos> jordi: because there might be two differing translations for same strings, and they can't decide which one is better
[04:33] <jordi> jgi: anyway, see what danilo said, msguniq them and you'll be done.
[04:33] <danilos> jordi: that's what I do in "xml2po -r" (reusing translations from XML files) as well
[04:33] <jordi> danilos: yuck
[04:34] <danilos> I mean, it's easy to simply use the first one, but maybe the second is better (there are options for msguniq for that ;-)
[04:36] <carlos> jordi: hmmm I think gettext already supports QT translation files...
[04:36] <jordi> well rosetta chokes on them then
[04:37] <carlos> no, it doesn't
[04:37] <carlos> gettext supports format strings from qt but from .cpp files
[04:38] <jordi> oh
[04:39] <jgi> carlos: *only* from .cpp files?
[04:39] <carlos> jgi: yeah that's what it says:
[04:39] <carlos>       --qt                    recognize Qt format strings
[04:39] <carlos>                                 (only language C++)
[04:40] <jgi> ok, but I mean it can also use strings that were written in header files
[04:40] <carlos> jgi: sure, sorry, only C++ source code
[04:41] <jgi> ok
[04:41] <jgi> Our strings are located only in C++ code AFAIK, but there might be some exceptions. I'll run msguniq and upload files again
[04:43] <carlos> jgi: if you only use C++ code, I think is much better if you use directly gettext
[05:12] <jgi> jordi, should I upload msguniqed files again? If so, where should I do it?
[05:17] <cprov> stub: ping
[05:20] <jgi> jordi, carlos: i've uploaded new files which went through msuniq, is there any way to know if import has failed?
[05:21] <carlos> jgi: https://launchpad.net/rosetta/imports/+index?target=products&status=FAILED&type=all
[05:24] <jgi> carlos, on top of this page: https://launchpad.net/rosetta/imports/+index?target=products&status=all&type=all there is the first import of qtwengophone_fr.po and qtwengophone_en.po, but i can't see a trace of my second upload
[05:27] <carlos> it's there now
[05:27] <carlos> so people finds their files
[05:29] <DSG> hello
[05:31] <carlos> DSG: hi
[05:32] <DSG> do you speak spanish ??
[05:33] <danilos> carlos does, bad badly ;)
[05:34] <DSG> because i don't speak much englesh
[05:34] <carlos> danilos: go away!
[05:34] <carlos> danilos: ;-)
[05:34] <danilos> :)
[05:34] <carlos> DSG: let's move to a private chat then...
[05:35] <jgi> carlos, I can see the french translation now, but there is no message to translate apparently. Are they supposed to come later when rosetta finish to process them?
[05:37] <carlos> yes, when it moves from 'Approved to Imported'
[05:38] <jgi> carlos, it seems to be the case already
[05:39] <carlos> jgi: if Rosetta imported them, you should have a confirmation email
[05:40] <jgi> carlos, yes, I got two e-mails, one for the french translation, and one for the english translation
[05:42] <jgi> carlos, in the product status, it is also stated that WengoPhone "doesn't use Rosetta", is it ok?
[05:43] <carlos> jgi: no, you should note that you are using Rosetta. Once we have all products clean, I guess we should set it on automatically
[05:43] <jgi> carlos, ok
[05:45] <carlos> jgi: about the empy translations problem
[05:45] <carlos> jgi: you lack a .pot file upload
[05:45] <carlos> so the system thinks that you have no messages at all
[05:45] <jgi> carlos, where could I upload this? If I try to upload a .pot file it says it wants a .po file
[05:46] <jgi> I must be looking at the wrong place
[05:46] <jgi> hmm, maybe I found it: https://launchpad.net/products/wengophone/trunk/+translations-upload , right ?
[05:47] <jgi> carlos, done
[05:50] <carlos> jgi: next time, upload it to https://launchpad.net/products/wengophone/trunk/+pots/qtwengophone/+upload
[05:50] <carlos> and it will be imported automatically
[05:50] <carlos> +translations-upload requires that we review it, but don't worry
[05:58] <carlos> is not a bit problem ;-)
[05:58] <carlos> I will approve it now.
[05:58] <jgi> carlos, thanks :-)
[05:58] <carlos> jordi: wow, is drupal asking to use us to translate it officially ? there are a bunch of .pot files for drupal pending to be approved
[05:58] <carlos> jgi: done
[05:58] <jgi> carlos, ok thanks. However, it seems that there is still no message to translate :-(
[05:58] <carlos> jgi: it takes a while
[05:58] <jgi> ok
[05:58] <carlos> I just approved it
[05:58] <carlos> now we need to wait for the import script to process it
[05:58] <jgi> ok
[06:01] <carlos> see you later
[06:04] <jgi> carlos, see you
[06:09] <jordi> carlos: no, they aren't
[06:09] <jordi> it's an upload I need to sort out
[06:09] <jordi> but that'll be deleted
[06:11] <jordi> jgi: ah I see you sorted it out
[06:11] <jordi> jgi: ah I see you sorted it oui was having some food
[06:14] <jgi> jordi, yes, that's great
[06:14] <jgi> thank you very much to everyone!
[06:18] <jordi> jgi: cool!
[06:19] <jgi> brb
[06:47] <elmo> how does launchpad send mail?
[06:47] <elmo> does it invoke /usr/sbin/sendmail?
[06:49] <salgado> elmo, I think this is a question for BjornT!
[06:49] <stub> elmo: SMTP to localhost
[06:49] <stub> (or another SMTP server if you prefer)
[06:50] <elmo> stub: hum
[06:51] <elmo> got an easy way on carbon to try getting launchpad to send mail in the way it does
[06:51] <stub> telnet localhost 25
[06:52] <stub> Or I can reconfigure the launchpad instance to turn email on - I don't think it will spam anyone as long as people don't randomly click ;)
[06:52] <elmo> hmm, ok
[06:53] <elmo> the problem is we can't do recipients ACLs on non-SMTP connections in exim
[06:54] <salgado> stub, talk to me, dude! kiko thinks we should use a trigger to change the status to shipped, when we update a request's shipment attribute, to avoid possible problems with the updates to status and shipment being performed on separate statements
[06:55] <salgado> stub, do you think a trigger is necessary or can we workaround it by issuing a raw SQL update?
[06:55] <stub> salgado: Seperate statements? Why?
[06:55] <stub> Even SQLObject should get that right...
[06:55] <salgado> stub, because I do request.status = shipped; request.shipment = shipment
[06:55] <salgado> it works fine, but I guess only because we use lazyUpdates
[06:56] <stub> salgado: Lazy updates is good, so that isn't a problem.
[06:57] <stub> salgado: So kiko is tryng to work around problems that don't exist. Hasn't he got enough problems already??
[06:57] <salgado> actually, I raised the problem
[06:57] <salgado> :/
[06:57] <salgado> and he suggested using a trigger
[06:58] <stub> Stick with the way you have it. It will only break if lazy updates gets switched off, and that would be a good thing.
[06:59] <stub> elmo: What is the problem then? We are using SMTP, so we can do recipients ACLs. Or did you use one too many negatives in that sentence?
[06:59] <elmo> stub: I can't guard against the possiblity of launchpad slipping into non-SMTP mode without warning
[07:00] <elmo> and non-obvious things like mail(1) use non-SMTP
[07:01] <stub> elmo: ok. Launchpad only has one email sending routing (lib/canonical/launchpad/mail/sendmail.py), and it only uses SMTP. Z3 pulled out the sendmail stuff due to a security problem, and from Python we just use smtplib rather than calling mail or sendmail from a subprocess. So it will be safe.
[07:04] <elmo> ok
[07:10] <elmo> hmm, I have a cunning plan
[07:11] <jgi> how is it possible for a given project to change its translation group?
[08:43] <kalosaurusrex> anyone know if the email support feature is working yet?
[08:54] <salgado> kalosaurusrex, if you mean, answering support requests by email, then yes, it should be working, I think
[08:55] <LarstiQ> salgado: the issue is starting support requests by mail
[08:56] <kalosaurusrex> how about sending support requests via email?
[08:57] <kalosaurusrex> LarstiQ:  :)
[08:57] <kalosaurusrex> actually I want to be able to connect my launchpad stuff to a gmane mailing list.  and have issues emailed from the mailing list, sent to gmane (already happens) and then sent to launchpad for tracking.
[09:00] <salgado> by looking at the code it seems to me that it's only possible to reply to an existing support request by email. :-(
[09:01] <salgado> kalosaurusrex, you might want to file a bug, explaining your use case. it shouldn't be hard to implement this
[09:04] <flacoste> LarstiQ: there is
[09:05] <flacoste> LarstiQ: err, actually, it's not in the specification tracker
[09:06] <kalosaurusrex> salgado: okay I will! great. thanks!
[09:07] <flacoste> and the old one https://wiki.launchpad.canonical.com/TicketTrackerEmailInterface didn't cover creating new tickets by email
[09:09] <LarstiQ> ok, so kalosaurusrex should just file a new one on https://launchpad.net/products/launchpad-support-tracker ?
[09:09] <LarstiQ> flacoste: that wiki is not accessible for us outsiders
[09:10] <flacoste> LarstiQ: wiki.launchpad.canonical.com should be
[09:10] <radix> can anyone tell me where the "add milestone" button is?
[09:10] <flacoste> LarstiQ: it's the old public wiki
[09:10] <LarstiQ> flacoste: indeed it is
[09:12] <LarstiQ> radix: good question, I can't find it
[09:12] <salgado> radix, the milestones are tied to productseries, so you have to create one or more productseries if you want to have milestones, I think
[09:13] <radix> oh
[09:13] <salgado> radix, for instance, on https://launchpad.net/products/launchpad-support-tracker/1.0 you can see the link to add a milestone
[09:13] <radix> aha! 
[09:13] <radix> ok, I found it in my "trunk" series
[09:14] <salgado> cool. :)
[09:15] <LarstiQ> that isn't easy to find out
[09:15] <niemeyer> Anyone with SQL access to  launchpad around
[09:15] <niemeyer> ?
[09:16] <salgado> niemeyer, read or write? does it need to be production or would staging be enough?
[09:16] <niemeyer> salgado: read/write on production.. I just did something stupid adding dummy information to a product to try it out.
[09:16] <niemeyer> And I can't remove now
[09:17] <salgado> niemeyer, you need stub or SteveA, then
[09:17] <niemeyer> salgado: Thanks!
[09:18] <LarstiQ> Storm?
[09:18] <salgado> np
[09:36] <kalosaurusrex> salgado: I entered the ticket.  number 53292
[09:36] <salgado> Ubugtu, bug 53292?
[09:36] <Ubugtu> Malone bug 53292 in launchpad-support-tracker "Email submit support ticket feature" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53292
[09:37] <salgado> thanks kalosaurusrex!
[09:38] <kalosaurusrex> salgado: and to you.  I appreciate your help.
[10:09] <bradb> salgado: Can somebody log in to LP without having validated their email address (i.e. it's still NEW), and would LP prompt them to validate at that point?
[10:09] <bradb> i'm thinking of things we might see from importing data
[10:10] <bradb> and if, for example, in a demo instance we can set all email addresses to some not-validated state, to trigger this login-and-validate workflow, if there even is one
[10:12] <salgado> bradb, if that happens, we will send an email to the address that person tried to login with, with a link to validate that address and then be able to login.
[10:12] <salgado> so, although it's not possible to login without a preferred email, we catch that and start the validate-your-email process for them
[10:12] <salgado> (and we also tell them an email was sent, and that they need to follow the instructions there before logging in, obviously)
[10:12] <bradb> salgado: ok, so, IIUC:
[10:13] <bradb> let's say we have a demo instance, and we want to make sure we don't spam people...
[10:13] <bradb> i should be able to update all the emailaddresses in this instance to be NEW, by default
[10:13] <bradb> then, anytime anyone logs in, they will be prompted to validate their email address
[10:14] <bradb> so only people who have specifically gone through this login-and-validate workflow will get email from the demo instance
[10:14] <bradb> right?
[10:14] <salgado> right
[10:14] <bradb> sweet!
[10:15] <LarstiQ> bradb: if you need a guinnea pig for demo instance testing, ping me
[10:15] <bradb> LarstiQ: thanks...we're working on an import now, so i'll let you know
[10:15] <salgado> bradb, but there may be places in the code that assume .preferredemail is never None
[10:16] <bradb> salgado: right. i think we can consider those bugs, if people do find them
[10:17] <salgado> I'm not sure they're bugs, because they assume that if a person got there, that means this person had a preferredemail at some point
[10:17] <salgado> and once you have one, it's not possible (by normal means) to go back to a no-prefferedemail status
[10:17] <bradb> right
[10:18] <bradb> salgado: one other thing...if my email address is foo@bar.com, and there's an account that was created with that email address and no p/w, how can i "claim" that account?
[10:18] <bradb> (again, thinking data import)
[10:19] <salgado> you have to use the forgotten password form
[10:20] <bradb> salgado: and will this work, even if the email is not yet validated?
[10:20] <salgado> yep
[10:21] <bradb> salgado: does it reset the p/w and validate the email all at the same time in this case?
[10:21] <salgado> bradb, yes
[10:22] <bradb> salgado: nice! thanks for the info. /me continues replying to jamesh's mail.
[10:22] <salgado> bradb, no problem
[10:50] <LarstiQ> hmm
[10:53] <bradb> LarstiQ: you aren't
[10:53] <bradb> if you file a bug at /distros/$distroname/+filebug and specify a package, you won't get the bugmail
[10:53] <bradb> any other variation on filing a bug should send mail though. (i've already landed the fix and asked stub to cherrypick it into production.)
[10:54] <LarstiQ> bradb: I'm thinking of bzr-email, which should be owned by the bzr devs, yet I just saw it had bugs I've never seen before
[10:56] <LarstiQ> bradb: the difference with bzr proper is that lifeless is the registrant for the plugin, and bzr devs are the registrant for bzr
[10:56] <bradb> LarstiQ: https://launchpad.net/products/bzr-email. lifeless pwns it.
[10:56] <LarstiQ> ok, so this is user error
[10:56] <bradb> yeah
[10:57] <LarstiQ> thanks for hitting me over the head with that :)
[10:57] <bradb> heh
[10:59] <bradb> ah, interesting
[11:04] <LarstiQ> I'm afraid it is even hotter than that here :/
[11:06] <bradb> LarstiQ: wow, where's that?
[11:06] <LarstiQ> bradb: The Netherlands, flat roof
[11:06] <bradb> ah