[11:08] <nabdev> hello, Geary n'accepte pas POP protocol ?
[11:09] <elacheche> No idea.. never used it :/
[11:10] <nabdev> :/
[11:11] <nabdev> j'ai seuelement les params de pop et smtp
[11:12] <elacheche> Why you use Geary x)
[11:16] <nabdev> with thunderbird i can't have autocomplete of mail
[11:16] <elacheche> mail @?
[11:16] <nabdev> yes
[11:16] <elacheche> My thunderbird do that for me!
[12:33] <nabdev> by all the mail that you have ( received or sended ) ? or just the sended mail ? , i checked by the sended mail it word
[12:34] <nabdev> other think , we have a big collection of mail in our webmail interface with thunderbird i havn't any mail out of the list ( received or sended )
[12:40] <elacheche> nabdev, you should import your contact list to thunderbird
[15:30] <Dro> bonjour
[15:49] <Neo31> hi Dro
[15:51] <Dro> ahla Neo31, how are you?
[15:51] <Neo31> good
[15:51] <Neo31> u ?
[15:53] <Dro> a bit bored, but fine! :D
[15:55] <Neo31> lol
[15:55] <Neo31> rabi ytochna bel bored hhh
[15:56] <Dro> haha à ce point dima 3amel jaw, t7eb ta9le9 ? :D
[15:56] <Neo31> nn mouch 7keyet 3amel jaw
[15:56] <Neo31> ama bored ma3neha rekich w ma l9it ma ta3mal w hbat 3lik le9la9
[15:56] <Neo31> :p
[15:56] <Neo31> rakcha w ra7a behia de temps en temps :)
[15:56] <Dro> nn, ynejem ykoun bored men kothr ma 3andou ma ya3mel :p
[15:57] <Neo31> hhh
[15:57] <Neo31> s3iba chwaya
[15:57] <Neo31> momken yehbil
[15:57] <Neo31> wala yjoujim
[15:57] <Dro> lol
[15:57] <Neo31> wala 7aja du genre
[15:57] <Neo31> bored s3iba
[15:58] <Neo31> anyway wish u some fun :)
[15:59] <Dro> thanks, wish u some boredom hahaha since you like that :D
[15:59] <Neo31> hhh not much ama from time to time it is ok :)
[15:59] <Neo31> thx anyway
[16:00] <Dro> Neo31, have you ever passed any oracle certification exam?
[16:04] <Neo31> nope
[16:05] <Neo31> i prepared for java certified programmer when it was with sun microsystems
[16:10] <Dro> hmm
[16:10] <Dro> I'm planning to pass Oracle Database SQL expert, do you think it worth passing it?


[04:22] <winstonw> hello how do i fix this error I get emailed when I upload my package to my ppa: PPA uploads must be signed by an Ubuntu Code of Conduct signer.
[04:32] <winstonw> nvm
[08:01] <cprov> winstonw: please follow the instructions in https://help.launchpad.net/Packaging/PPA for signing the Ubuntu code of conduct.
[08:02] <winstonw> yeah i figured that out
[08:11] <dysmann> Hello !
[08:12] <winstonw> hi
[08:12] <dysmann> I have a question about PPAs
[08:12] <dysmann> I just created a PPA to trie but I have to change my ID too
[08:12] <dysmann> How can I delete my PPA ?
[08:28] <dysmann> does anyone know how to do this ?
[08:29] <cody-somerville> dysmann, You have to file a request against the launchpad project.
[08:29] <dysmann> ok thank you !
[09:32] <Laibsch> I'm here to report problems with the LP service.  Every time I try to report a bug, I get a timeout or 502 Bad Gateway error.
[09:33] <Laibsch> (Error ID: OOPS-1309D878), for example
[09:42] <lifeless> Laibsch: how long has this been happening?
[09:43] <wgrant> I got a 502 from edge a few minutes ago.
[09:44] <wgrant> But that OOPS ID suggests that it's not just edge (although it's a separate problem).
[09:44] <mwhudson> yeah, that was a prod url
[09:44] <cody-somerville> I too a "launchpad is down" page a few minutes ago.
[09:44] <mwhudson> timed out for me too with the same query string
[09:44] <cody-somerville> *got
[09:45] <wgrant> But the timeout is separate from the 502s.
[09:45] <wgrant> Was it a dupe-search FTI timeout?
[09:46] <mwhudson> wgrant: yes
[09:46] <wgrant> Laibsch: Try using a shorter initial summary; you can complete it later.
[09:46] <cody-somerville> hmm... I got "Sorry, there was a problem connecting to the Launchpad server. " again
[09:46] <wgrant> cody-somerville: lpnet or edge?
[09:47] <cody-somerville> edge
[09:47] <Laibsch> I'm using requestsync as well
[09:47] <Laibsch> that script will often crash before I can even enter a summary
[09:47] <wgrant> Ah.
[09:48] <wgrant> Does lpstats show which appserver is broken?
[09:48] <mwhudson> not directly
[09:48] <lifeless> I've escalated it
[09:48] <mwhudson> lifeless: thanks
[09:48] <wgrant> Thanks lifeless.
[09:51] <mwhudson> (doesn't look like an appserver is dead from the graphs, fwiw)
[09:52] <wgrant> Damn.
[09:52] <wgrant> That's always an obvious fix.
[10:19] <lifeless> Laibsch: please try again. That particular bug you're trying to file is timing out, possibly an index problem. But there were other issues we hope we've resolved.
[10:56] <Amaranth> pretty sure this is a spammer of some kind: https://edge.launchpad.net/~hance83
[11:43] <BUGabundo>            If this is blocking your work, let us know by sending an  message to<EMAIL_ADDRESS>          Include the error ID           OOPS-1309EA109           in your message.
[12:25] <funkyHat> https://bugs.edge.launchpad.net/ubuntu/+source/pidgin/+bug/354605 this is marked as "Fix Committed" in Ubuntu, but I am still experiencing the bug. Is it only committed for Karmic, or am I missing something?
[12:32] <Laibsch> funkyHat: "nominate for release"
[12:35] <funkyHat> Laibsch: ah, so I should have done that weeks ago, I guess
[12:36] <Laibsch> lifeless: sorry for the delay, I just returned
[12:37] <Laibsch> the error seems at least partially fixed, but requestsync still crashes.  only at a later point.  what is see is "HTTP Error 412: Precondition Failed"
[12:37] <Laibsch> unfortunately, I don't see an oops id
[12:38] <mwhudson> ??
[12:39] <wgrant> Laibsch: That's more than likely a bug in requestsync. Check with the ubuntu-dev-tools developers.
[12:41] <mwhudson> hm
[12:41] <mwhudson> does requestsync use the api?
[12:42] <Laibsch> I can hardly imagine that.  It would imply that the script is completely broken.  It really has only one function and that function doesn't work for me.
[12:42] <mwhudson> i think you can get 412 when the resource you try to modify through the api has been modified since you last read it
[12:42] <Laibsch> that = a bug in requestsync being the cause
[12:42] <mwhudson> (like failing to commit a transaction in the SERIALIZABLE isolation level)
[12:42] <Laibsch> It would be broken for everyone and I don't see any indication of that in the bug tracker
[12:42] <Laibsch> Nonetheless, I'll file a ticket, of course.
[12:44] <Laibsch> mwhudson: does the "launchpadlib" use the API?
[12:44] <wgrant> Yes.
[12:44] <wgrant> launchpadlib is one of the primary API clients.
[12:44] <Laibsch> according to the manpage, that is what requestsync uses
[12:44] <mwhudson> very much so
[12:45] <Laibsch> http://paste.debian.net/43124/
[12:45] <mwhudson> wow gosh, the highlighting of http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/annotate/head%3A/requestsync is ugly :*
[12:45] <Laibsch> Hehe
[12:45] <Laibsch> Funny
[12:45]  * Laibsch just received the confirmation from Launchpad about a newly filed ticket
[12:45] <Laibsch> ;-)
[12:46] <mwhudson> Laibsch: did you keep the traceback that mentioned the 412 problem?
[12:46] <Laibsch> I'm not sure I received a traceback
[12:46] <Laibsch> You mean the python traceback?
[12:46] <mwhudson> yes
[12:46] <Laibsch> OK
[12:47] <Laibsch> I'll spare you the part from the editor, everything after the editor closed is: http://paste.debian.net/43125/
[12:48] <mwhudson> hm, looked like trying to set the status failed
[12:49] <wgrant> But it has the permission check there.
[12:49]  * mwhudson tries to stop worrying about this sort of thing at 23:50 on a saturday
[12:50] <mwhudson> wgrant: lp_save() will end up 412-ing if the etag of the resource you're changing is different it seems
[12:50] <Laibsch> FWIW, another sync request I just filed went through without a problem: bug 407655
[12:50] <mwhudson> (looking at lazr.restful source)
[12:50]  * mwhudson goes away
[12:50] <wgrant> mwhudson: Right, that makes sense.
[12:50] <wgrant> Night.
[13:37] <mb74> is it possible to set a different base version than the automatically detected by dpkg-parsechangelog when i  call "debuild -S"? I've created a package which already has version 0.4.24-ep3, but the originally available version in jaunty is 0.4.22. When I call "debuild -S" then it searches for ...0.4.24.orig.tar.gz, but I want it to search for ...0.4.22.orig.tar.gz.
[13:43] <Laibsch> mb74: try #ubuntu or #ubuntu-motu
[14:17] <sysadmin> hi, trying to install a local launchpad, I'd like to know if I can just explode the lauchpad.tar.gz rather than having lots of downloads via rocketfuel-setup .... can someone tell me where to explode the file pls :)
[14:27] <sysadmin> trustno1
[15:57] <pablo> which is the difference between reactivating an account and registering? why is it called deactivating an account instead of deleting it? which data is not removed?
[15:58] <LarstiQ> no data is removed afaik
[15:59] <pablo> LarstiQ: nothing at all?
[16:00] <LarstiQ> pablo: I think so.
[16:00]  * LarstiQ bases that on his experience as a user
[16:03] <pablo> LarstiQ: which data are you refering to?
[16:04] <LarstiQ> pablo: all data
[16:04] <LarstiQ> pablo: an identity is still useful even if someone doesn't login with it anymore
[16:05] <LarstiQ> pablo: in particular its association to bugs, code, answers, translation, etc
[16:06] <pablo> LarstiQ: https://help.launchpad.net/YourAccount/Closing?action=show&redirect=DeactivatingYourAccount
[16:06] <LarstiQ> okay, so I was wrong :)
[16:07] <LarstiQ> pablo: reading that, all data is retained, _except_ the data that would imply you're active on a project
[16:08] <LarstiQ> pablo: so the account is no longer taking responsibilityh (assignees) and other people can get the work done
[16:08] <LarstiQ> pablo: but historic data is still there
[16:09] <pablo> LarstiQ: what do you mean with historic data? commits, bug tickets and what else
[16:09] <LarstiQ> pablo: comments, answers, mailing list posts, etc
[16:10] <LarstiQ> pablo: a useful way to think of it -
[16:10] <LarstiQ> pablo: does the data contribute to giving other people a complete picture?
[16:11] <LarstiQ> pablo: say you had commented in some bug threads, removing those comments would mean the thread no longer makes sense
[16:11] <pablo> LarstiQ: right
[16:12] <LarstiQ> pablo: in other words, an identity is useful to more people than just the person who can login with it
[16:13] <pablo> LarstiQ: mm
[16:14] <pablo> LarstiQ: but comments on bugs is not an identity
[16:15] <LarstiQ> pablo: right
[16:15] <LarstiQ> pablo: they are linked to one though
[16:16] <LarstiQ> pablo: and in a philosophical sense contribute to it, but that's outside the scope here I guess :)
[20:08] <mhall119> is there any trick to meta-packages other than just having no source and including Depends?
[20:44] <maxb> That's pretty much all there is to it
[20:49] <mhall119> okay, with debian/changelog am I supposed to replace or append when I'm making a new version?
[21:03] <jpds> mhall119: Append.
[21:04] <mhall119> whoops, oh well, thanks
[21:04] <jpds> mhall119: 'dch -i' from devscripts will create a new entry for you.
[21:04] <mhall119> ah, okay, thanks
[21:06] <mhall119> so far so good
[22:13] <pablo> hi, why uppon reactivation launchpad remembers username? isnt it deleted?
[22:28] <mhall119> pablo: it's probably just deactivated
[22:38] <pablo> mhall119: yes, uppon deactivation isnt the profile deleted?
[22:39] <mhall119> I would doubt it, that account would be tied to any entries in LP that you created or modified while it was active, that relationship would need to remain
[22:51] <maxb> Technically, you *prepend* to debian/changelog
[22:51] <maxb> Fortunately, dch takes all the pain out of maintaining it
[22:57] <mhall119> good to know


[09:11] <wgrant> Anyone around for a review?
[09:11] <wgrant> https://code.launchpad.net/~wgrant/launchpad/rebuilds-without-nai/+merge/46070
[17:54] <leonardr> jcsackett, if you please: https://code.launchpad.net/~leonardr/launchpad/fix-apidoc/+merge/46161
[17:55] <jcsackett> leonardr: sure thing.
[18:24] <jtv> jcsackett: can I push one onto your queue?
[18:24] <jcsackett> jtv: sure. link to the MP?
[18:25] <jtv> jcsackett: https://code.launchpad.net/~jtv/launchpad/bug-702228/+merge/46165
[18:36] <jcsackett> leonardr: r=me. i've requested follow up from sinzui.
[18:36] <leonardr> jcsackett,great
[18:36] <jcsackett> sinzui: i probably should not review your branch, since you're still my mentor.
[18:37] <sinzui> jcsackett: I think you should because someone needs to know about mailman oddities.
[18:37] <sinzui> I will find a mentor after your review
[18:37] <jcsackett> sinzui: fair enough.
[18:37] <jcsackett> sinzui: okay.
[18:41] <sinzui> leonardr: ping
[18:43] <leonardr> sinzui, yo
[18:43] <sinzui> leonardr: what is the magic with scalar_value?
[18:43] <sinzui> ScalarValue I mean
[18:44] <leonardr> sinzui: it's like HostedFile--a special resource type that we don't want to document
[18:44] <sinzui> Is there an example in the live docs?
[18:45] <leonardr> no, it doesn't show up. i'm just making 100% sure it doesn't show up in the future
[18:46] <sinzui> okay
[18:46] <StevenK> Can we flag it with @hidden or something that makes WADL generation skip it?
[18:46] <sinzui> leonardr: r=me. I noted that the copyright needs updating
[18:47] <leonardr> StevenK: we want it in the WADL, we just don't want it in the HTML docs
[18:47] <leonardr> it's a resource that the end-user never sees
[18:47] <StevenK> @undocumented ? :-)
[18:49] <leonardr> i don't think it's the server side's job to make that kind of distinction
[18:52] <jcsackett> sinzui: so MailmanTestCase doesn't actually isolate from the real proxy?
[18:53] <sinzui> I agree with leonardr. We want the xslt public so users can see how we interpret it, but other's may want to make their own interpretation of the data
[18:53] <sinzui> jcsackett: it does. I was stumped by the impossible timeouts when I sketched out the test you are reading.
[18:54] <jcsackett> sinzui: okay.
[18:54] <sinzui> reading XMLRPCRunner.__init__, I realised it already has a reference to the real proxy
[19:00] <leonardr> jcsackett: https://code.launchpad.net/~leonardr/launchpadlib/remove-xslt/+merge/46167
[19:01] <jcsackett> sinzui: shouldn't the isolation you do in your test be part of the MailmanTestcase setup?
[19:01] <jcsackett> sinzui: not asking you to make that change, but if it's something that should be done, perhaps file a bug?
[19:01] <jcsackett> i acknowledge i don't have a full understanding of what we want in a mailman test, but unplugging from the proxy seems correct.
[19:04] <sinzui> jcsackett: which setup. I think the test setup id DRY
[19:05] <jcsackett> sinzui: nevermind, i was misunderstanding what was being done.
[19:05] <jcsackett> sinzui: i thought that you were patching around something the base class for your test should have done. that is not the case.
[19:06] <sinzui> yeah, get_mailing_list_api_test_proxy() looks like duplication, but it is changing an instance, where as super() is changing the module
[19:06] <sinzui> reset_log and get_mark may move to the base class. I am pondering a test in a new branch that may need them
[19:08] <sinzui> jcsackett: when you are done this my branch, I want to to talk about the implementation of my current bug, the one you looked at this morning
[19:08] <jcsackett> sinzui: sure.
[19:13] <jcsackett> sinzui: r=me, with two minor things.
[19:13] <jcsackett> notes are on on your diff, but it's basically some docs/comments stuff.
[19:14] <jcsackett> leonardr: your MP shows zero lines diff.
[19:14] <leonardr> hmm...
[19:14] <sinzui> jcsackett: I will follow up on you comments
[19:15] <jcsackett> sinzui: sounds good. feel free to ping me when you want to mumble re: your current branch.
[19:15] <jcsackett> leonardr: the file you wanted to remove (as i understand it) is still in your branch. http://bazaar.launchpad.net/%7Eleonardr/launchpadlib/remove-xslt/files/head%3A/src/launchpadlib/
[19:16] <leonardr> jcsackett: i didn't commit anything. new version is pushed
[19:19] <sinzui> jcsackett: can we mumble for a few minutes?
[19:28] <sinzui> jcsackett: http://pastebin.ubuntu.com/553725/
[19:56] <pcjc2> Can someone take a look at https://code.launchpad.net/~pcjc2/launchpad/fix-tag-search-bug-501945/+merge/46075 for me?
[20:20] <jcsackett> pcjc2: you're on the queue.
[20:20] <jcsackett> pcjc2: you're a new contributor?
[20:39] <jcsackett> jtv: r=me, but it looks lifeless hit it a bit earlier. i won't request follow up from sinzui since lifeless already approved it.
[20:39] <jcsackett> leonardr: r=me.
[20:39] <pcjc2> newish - this is my second patch
[20:40] <jcsackett> pcjc2: cool. so, in the channel info here there is frequently an on call reviewer, who you can usually ping to get into the queue.
[20:40] <jcsackett> in this instance, that's me. :-)
[20:40] <pcjc2> I hashed out some of this with lifeless (He got the SQL tested), but he's a bit busy at the moment to review it
[20:41] <pcjc2> Thanks - I've not been here before
[20:41] <pcjc2> The other patch I did was with gmb helping, and it related to bug import, not an actual part of the web service.
[20:58]  * pcjc2 approves of Peter B's config API
[20:58] <pcjc2> Might want to consider the possibility of freeze and thaw for the callbacks
[20:58] <pcjc2> Also, possibly add save APIs?
[20:59] <pcjc2> export either a given context, or a "flattened" (borrowing from gimp layers) context ?
[21:00] <pcjc2> (OOPS: -E_WRONG_WINDOW)
[21:09] <sinzui> EdwinGrubbs: thumper: can either of you mentor jcsackett review of my branch? https://code.launchpad.net/~sinzui/launchpad/mailman-heartbeat-0/+merge/46160
[21:09] <EdwinGrubbs>  sinzui: I can do it
[21:23] <jcsackett> pcjc2: there are comments on your MP.
[21:24] <pcjc2> thanks
[21:24]  * pcjc2 checsk
[21:24] <EdwinGrubbs> sinzui: it seems strange to log "--MARK--" since syslogd can be configured to add that to a logfile automatically. Of course, when the xmlrpcrunner does it, it would be preceded by a timestamp.
[21:25] <pcjc2> "You should flip those back; by convention we put the expected value first in assertEqual statements."
[21:25] <pcjc2> correct fix is then to swap the parameters passed to each caller then
[21:25] <pcjc2> (and swap the assert back)
[21:25] <sinzui> EdwinGrubbs: I was following the suggestion of the losa.
[21:25]  * sinzui looks at mailman's own logging lib again
[21:25] <jcsackett> pcjc2: that may be correct, my comment was limited to the scope of your MP.
[21:26] <pcjc2> I swapped them because every test had the parameters reversed, I didn't know there was a convention
[21:26] <sinzui> EdwinGrubbs: mailman does not use python batteries. I think it still thinks we live with Python 2.1
[21:26] <pcjc2> RE: comment - a docstring at the start of the function ok to explain the SQL?
[21:27] <jcsackett> pcjc2: that should work, yes. please remember that the first line of a docstring should be one line quick explanation of the method, then a blank line, then the longer details.
[21:27] <jcsackett> and thanks for making these changes. :-)
[21:27] <pcjc2> like a git commit ;). NP
[21:28] <jcsackett> exactly like a git commit. :-)
[21:28] <jcsackett> pcjc2: ping me when you have pushed the changes, i can approve the MP and alert my mentor to follow up.
[21:29] <jcsackett> even if i'm in the middle of another review i can do that quickly.
[21:29] <pcjc2> ok, will do. Am merging some git conflicts another project right now, but should look at it tonight
[21:30] <jcsackett> pcjc2: ok.
[21:36] <EdwinGrubbs> sinzui: I just checked, and rsyslog puts the timestamp in front of its autogenerated "-- MARK --", so I think it is a bad idea to use that as your heartbeat text. If the losas insist on that, I'll agree to it, but I'm guessing they didn't think about the confusion it could cause.
[21:37] <sinzui> EdwinGrubbs: I think we want a timestamp so that nagios nows when the heatbeat took place
[21:37]  * StevenK hands sinzui a 'k'
[21:38] <EdwinGrubbs> sinzui: yes, but if nagios is grepping for "-- MARK --" with a timestamp, and syslogd is configured to add "-- MARK --" entries every few minutes, and they also have a timestamp, the xmlrpcrunner could be broken and you would never know it.
[21:38] <sinzui> I am getting rid of silent letters just after I get rid of c, j, q, x
[21:39] <StevenK> You can't QQ without q
[21:40] <sinzui> EdwinGrubbs: I do not know what syslogd has to do with this. It is not managing Mailman's logs
[21:40] <sinzui> Why would the losas request that we add --MARK-- to the queue's log if they could do it themselves
[21:41] <sinzui> q is a dipthong for kw
[21:43] <lifeless> I think asking a losa is a good idea at this point :)
[21:45] <sinzui> lifeless: Mailman's Syslog puts a write lock on the log. As my test shows, some insider knowedege and access is needed to acquire access,
[21:45] <EdwinGrubbs> sinzui: what is on the receiving end of the syslog() call in the xmlrpcrunner then? Configuring syslogd to log MARK just shows that syslog is working, it doesn't show that the programs using that logfile are working.
[21:46] <sinzui> And be assured I toppled mailman several times learning the art of stealing the logs
[21:46] <lifeless> wheeee
[21:47] <lifeless> EdwinGrubbs: I think the point is that we don't know if xmlrpcrunner is hung or not
[21:47] <sinzui> Edwin Mailman.logging.syslog is a dict-like object that manages Mailman.logging.StampedLoggers. Each logger manages a file with 'a+b'
[21:48] <sinzui> Edwin each object in the chain ensures the file is closed if you were to call del on the instance
[21:49] <sinzui> EdwinGrubbs: Mailman really thinks about logging like it was the 10 years ago. It does not even have bools
[21:50] <EdwinGrubbs> sinzui: ok, that is bizarro
[21:50] <sinzui> But it would life to use with `open(ccc) as log:` Mailman 3 might do that
[21:50] <sinzui> EdwinGrubbs: I believe mailman requires Python2.1 to run
[21:52] <sinzui> EdwinGrubbs: I was looking for barry to asking about SHUNTING. I will bring up the log issue with him
[21:52] <sinzui> when I find him
[21:58] <EdwinGrubbs> sinzui: you can keep using MARK if you want, since mailman's syslog() doesn't log to syslogd. This reminds me of the time a friend created a readFoo() function that had a parameter to turn on writing.
[21:58] <EdwinGrubbs> I'll approve the mp
[21:58]  * sinzui is still looking for barry
[22:00] <sinzui> EdwinGrubbs: thanks. I really want to talk to barry. I an reading an old log and I makes me wonder if his and mthaddon's analysis is complete. I see log entries that imply my change will work by accident, in some cases
[22:03] <StevenK> sinzui: I can find Barry in Dallas if you wish
[22:03] <StevenK> (And tempt him onto IRC)
[22:03] <sinzui> please do
[22:03] <StevenK> sinzui: Aye
[22:05] <barry> sinzui: be with you in a few minutes
[22:05] <sinzui> fab
[22:05] <StevenK> \o/
[22:05] <jtv> jcsackett: thanks
[22:09] <barry> sinzui, okay, i'm all yours
[22:10] <sinzui> Looking at a mailman error log. I see that messages were shunted because of
[22:10] <sinzui> XMLROC proxy errors in LPHandler. I do not think I want the message shunted
[22:10] <sinzui> since Runner implies IncomingRunner or LPHandler should have done something
[22:10] <sinzui> itself.
[22:10] <sinzui> I will wrap the proxy call to catch and raise oopses when xmlrpc goes down, but I think I want the message reenqueued
[22:12] <barry> i can't think of a good way to prevent Runner._oneloop() from shunting when _onefile() throws an exception
[22:12] <barry> short of hacking the code, or catching the exception in _onefile()
[22:12] <sinzui> yuck
[22:13] <barry> well, actually, maybe you can set self._shunt to the retry queue
[22:13] <sinzui> I hoped for a way to reenque from the handler, or raise a specific error that tell IncomingRunner to do it
[22:13]  * barry thinks
[22:14] <sinzui> How will a shunted message ever be processed. No one manages mailman
[22:14] <barry> it has to be done manually via bin/unshunt
[22:14]  * barry shudders to think how big the shunt queue is
[22:14] <sinzui> I think then we have several years in there
[22:14] <barry> you almost certainly don't want to unshunt the whole queue ;)
[22:15] <StevenK> How can we see how large the queue is?
[22:15] <thumper> barry: hi!
[22:15] <sinzui> So as I was thinking. We just need to pause the queue until connectivity is back. just loop over the message
[22:15] <barry> thumper, hi!
[22:15] <barry> StevenK, ls queue/shunt
[22:15] <barry> er, queues/shunt
[22:16] <barry> note tho that the queue files have a timestamp encoded in the file names so you could potentially decode that and only unshunt the ones from whatever date you care about
[22:17] <barry> not sure what you mean by "until connectivity is back"
[22:17] <sinzui> barry, what would you do if you LPHandler has no connectivity to complete its task. this is like a lock on a list. I see we try to return 1 to imply try again later
[22:18] <barry> sinzui, right.  just leave the message in the queue and it will be picked up the next time 'round
[22:18] <barry> or, enqueue it to queues/retry, but all that does is requeue the message every so often
[22:18] <barry> so it's about equivalent
[22:19] <sinzui> barry: Sometimes the xmlrpc request times out, but the next try works. But on Dec 1, it went down and mailman stopped trying.
[22:19] <barry> sinzui, any idea why it stopped trying?
[22:20] <barry> another idea...
[22:20] <sinzui> barry: Log looks like Mailman got board shunting
[22:20] <sinzui> restart worked fine
[22:20] <barry> ;)
[22:20] <barry> so, the .pck files have two objects in them: a dict (the message metadata) and the message object
[22:20] <sinzui> My branch to add a heartbeat will warn us in the future
[22:21] <sinzui> barry: how would I signal/do an enqueue from a handler
[22:21] <barry> it would be a bit slow but you can unpickle the .pck file and look in the dict for tell-tale signs that LPHandler is where the failure occurred
[22:22] <sinzui> barry: I can see where the failure happen. There are only two calls in out monkeypatches that do not try/except arround the proxy. I am sure we can log this. I just want solve how to keep the message alive
[22:23] <barry> sinzui, you just instantiate the queue you want and call .enqueue() on it.  note tho that that makes a copy of the message, so absent anything else, it continues to get processed by the current runner
[22:23] <sinzui> barry: from inside the handers except clause? That sounds like recursion
[22:24] <barry> sinzui, so i think you catch the exception, instantiate the retry queue, enqueue the message, then reraise the exception (or raise DiscardMessage)
[22:24] <barry> just be sure we're running the retry runner (i don't remember and i don't have the lp code in front of me)
[22:24] <barry> StevenK, do you have the lp code handy?
[22:25] <StevenK> barry: Yes
[22:25] <sinzui> ahh, good point. If I raise the exception, it get shunted. raising discard just removes the copy in in the queue?
[22:25] <barry> sinzui, yep
[22:25] <barry> look at IncomingRunner.py
[22:25] <StevenK> barry: You'll need to come to me, my battery is 4% or so
[22:25] <barry> StevenK, what room are you in?
[22:25] <sinzui> barry: I know how to check that and I know how to make it run
[22:25] <StevenK> barry: Desktop
[22:25] <barry> StevenK,sec...
[22:29] <sinzui> barry: we are running the retryrunner. I wrote a test to ensure it is. Thanks I really appreciate your help
[22:29] <barry> np.  looking at the code now
[22:29] <barry> it's been a while ;)
[22:30] <barry> sinzui, which call is failing?
[22:30] <barry> proxy = proxy = ? ;)
[22:30] <sinzui>   File "/srv/lists.launchpad.net/production/launchpad-rev-9972/lib/lp/services/mailman/monkeypatches/lphandler.py", line 49, in process
[22:30] <sinzui>     is_member = proxy.isRegisteredInLaunchpad(sender)
[22:31] <sinzui> barry: there that is one of two places we call proxy that we do not wrap in try/except
[22:31] <barry> sinzui, yeah, for some reason i think the preceding comment is a lie ;)
[22:31] <sinzui> barry: I was going to reuse the except rules an log_exception from xmlrpcrunner on it
[22:32]  * barry thinks
[22:32] <sinzui> barry: This is one of many entries in the log http://pastebin.ubuntu.com/553793/
[22:33] <barry> yeah, it's not a lie because xmlrpcrunner isn't incoming runner
[22:35] <sinzui> This line and the one in lpstanding is just an oversight. All other calls are safe to use, but this one cold lose the message
[22:43]  * pcjc2 struggles to think of concise words to describe the SQL statements reasoning in his docstrings
[22:44] <barry> sinzui, so yeah, i think the best you can do is to catch the exception, enqueue the message to retry, and raise DiscardMessage.  then the retry runner should requeue it, and when it's re-processed by incoming runner it should start back up at the LaunchpadMembers handler
[22:44] <barry> sinzui, write some tests, but i think that should work ;)
[22:49] <jcsackett> pcjc2: "Because the final clause only checks the existence of results of the query, subqueries can select true rather than an actual entity, speeding up the process."
[22:49] <jcsackett> maybe.
[22:49] <jcsackett> it's a little clunky. :-P
[22:49] <pcjc2> I'm moving the EXISTS keyword into the build_tag_set_query
[22:49] <pcjc2> function
[22:49] <pcjc2> then it returns a TRUE or FALSE, and it is cleaner - as well as easier to explain
[22:50] <pcjc2> might not even NEED to explain the SQL in detail if that change is made?
[22:52] <pcjc2> http://pastebin.com/EfHtBNdE
[22:52] <pcjc2> ?
[22:52] <pcjc2> THink I will drop the comment about where it is used
[22:52] <pcjc2> that could get out of date fast
[22:52] <pcjc2> Will add one about expecting the surrounding SQL to ensure "Bug.id" is in scope
[22:55] <pcjc2> what about http://pastebin.com/QswKQ2Lg ?
[23:00] <pcjc2> See the diff: http://pastebin.com/9iViJh6Y
[23:00]  * pcjc2 re-runs tests to be sure
[23:06] <jcsackett> pcjc2: i would put quick comments above the string format statements, since you end up with things like "%s %s %s".
[23:06] <pcjc2> comment to what effect?
[23:06] <pcjc2> at some point, one has to read the context of the code ;)
[23:07] <jcsackett> pcjc2: that's an excellent question, actually.
[23:07] <jcsackett> yeah, this is just an inherently complicated bit.
[23:07] <jcsackett> looks weird, but you're right, it doesn't need anything more.
[23:07] <jcsackett> test passing?
[23:07] <pcjc2> "%s %s NOT %s" is a bit strange, I conceed
[23:07] <pcjc2> give it a month or two to run...
[23:07] <jcsackett> yeah, it's odd, but i think it's alright.
[23:07] <jcsackett> lol.
[23:08] <pcjc2> (just wanted to check the "testbug.py" test, as it compares SQL output - had to make sure I'd not shifted the way the SQL was braketed
[23:08] <pcjc2> I'm not going to re-run the other tests as the SQL is the same..
[23:09]  * jcsackett nods.
[23:10] <pcjc2> Will need some manual QA though, as I'm not sure how good the "life" test coverage is
[23:11] <jcsackett> ?
[23:11] <jcsackett> which test are you referring to by "life" test?
[23:11] <pcjc2> "live" I meant
[23:11] <pcjc2> with a big data-set
[23:11] <pcjc2> it aims to fix a problem which needs a production sized DB to reproduce
[23:13] <pcjc2>        return "%s" % include_clause
[23:13] <lifeless> pcjc2: we qa all such things ;)
[23:13] <pcjc2> should become "return include_clause"
[23:13] <lifeless> pcjc2: on qastaging.launchpad.net
[23:13] <lifeless> perhaps
[23:13] <lifeless> return str(include_clause)
[23:14] <pcjc2> include_clause is assembled from strings
[23:14] <lifeless> or even unicode(include_clause)
[23:14] <pcjc2> we don't prefix the return "(%s %s NOT %s)" % ... case with u"
[23:14] <lifeless> pcjc2: sure, explicit can be good sometimes (also its a noop if the type matches)
[23:15] <thumper> sinzui: https://code.launchpad.net/~thumper/launchpad/daily-build-page-text/+merge/46207 for your UI approval :)
[23:15] <sinzui> okay
[23:15] <pcjc2> lifeless - name your preference... unicode, str ?
[23:16] <pcjc2> meh - actually, it is only the one "NOP"  return "%s" % include_clause
[23:16] <pcjc2> the other cases around it need that syntax, so it is best we keep them consistent
[23:16] <pcjc2> even if "%s" % ...  is  a NOOP
[23:17] <pcjc2> what is the SQL'esque way of fixing this comment...
[23:17] <pcjc2> This SQL is designed to be a sub-query where the parent SQL defines Bug.id.
[23:17] <pcjc2> "defines" seems wrong
[23:18] <pcjc2> JOINs/includes/contains/?
[23:18] <jcsackett> pcjc2: i have to run for the evening. i'll check the MP in the morning for the changes. ttyl.
[23:18] <pcjc2> "parent query scope includes Bug.id" ?
[23:19] <pcjc2> @jcsackett: Thanks for the review - with luck the MP will be in good order by tomorrow
[23:19] <jcsackett> pcjc2: sounds good.
[23:19] <lifeless> pcjc2: I would leave it as is
[23:19] <pcjc2> as it was?
[23:19] <lifeless> pcjc2: it looked ok at a glance
[23:20] <lifeless> as was, yes
[23:20] <pcjc2> ok, will push that diff
[23:20] <lifeless> jcsackett's two comments were good suggestions
[23:20] <pcjc2> Do I need to mark the MP as needing further review?
[23:20] <pcjc2> Review comments have been taken into account, new push coming...
[23:26] <huwshimi> sinzui: Hi. Would you be able to review a CSS bug fix sometime (bug #684911: https://code.launchpad.net/~huwshimi/launchpad/broken-calendar-684911/+merge/46208)?
[23:27] <_mup_> Bug #684911: calendar overlay widget style broken after lazr-js 191 upgrade <javascript> <lazr-js-upgrade> <lp-web> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/684911 >
[23:27]  * sinzui hates that widget
[23:27] <sinzui> you cruel man.
[23:27] <huwshimi> sinzui: Is that a no then? :P
[23:28] <sinzui> ah, so the hack to for the yui-3 skin was lost in the last update?
[23:29] <huwshimi> sinzui: Looks like something like that. In which case, me fixing the styles this way would only be a temporary fix
[23:29] <huwshimi> I don't really understand how all the lazr-js stuff works yet but maybe the real fix is something to do with that
[23:30] <sinzui> We wanted a yui-3 widget, but one does not exist. We could make a lazr one that handles NOW
[23:30] <sinzui> this is good to land. Thanks huw.
[23:31] <huwshimi> Yeah ok that makes sense. Thanks
[23:32] <sinzui> Oh, the fonts are wrong
[23:32] <huwshimi> Ah yes
[23:32] <sinzui> huwshimi: I will find the correct font-family string
[23:32] <sinzui> I remembered that we had to hack the fonts as well as the skin 18 months ago
[23:34] <pcjc2> @jcsackett: My MP should be ready to go when you get to it tomorrow - thanks
[23:36] <sinzui> huw: do you have a strong understand of how browsers (last 5 year) handle font-size. YUI requires us to use % to guarantee consistent rendering, but that also means the engineer never knows what the actual font-size will be when all content and rules are mixed together
[23:37] <sinzui> huw I want to switch back to ems, or even px as suggested by Canonical web guidelines if I could trust consistent sizes
[23:43] <huwshimi> sinzui: Yeah font sizing gets very confusing very quickly.
[23:43] <huwshimi> Especially when you won't necessarily have control over third party widgets etc.
[23:44] <sinzui> I used to avoid px. I was surprised the Canonical insists on it. I think they may be looking a how browser engines handle px though. My phone shows me pages and I know it is ignoring the px rules
[23:45] <huwshimi> With the calendar I can either set the font to the Ubuntu one or remove the font-family settings altogether (which will then inherit the correct fonts)
[23:45] <huwshimi> Any preference
[23:45] <huwshimi> ?
[23:45] <sinzui> YUI is specifically reconciling Window with every other os/basefont. I am not sure I care about windows
[23:45] <lifeless> sadly we care
[23:45] <lifeless> because our customers have customers and suppliers on windows
[23:46] <sinzui> huwshimi: I think we need to set it. Somewhere in the chain, verdana or tahoma gets added
[23:47] <sinzui> lifeless: I think the issue windows fonts being a little big is less than the issue that we are not using the font-sizes that the CSS predicts will rendered. % rules are being nested. We cannot avoid that
[23:47] <huwshimi> sinzui: On a quick test of removing all font-family lines from calendar.css it seems to be working correctly.
[23:48] <sinzui> lifeless: http://curtis.hovey.name/2010/12/17/launchpad-font-size-broken-by-design/
[23:48] <sinzui> huwshimi: fab
[23:49] <huwshimi> sinzui: Should I go ahead and commit without font-family rules then?
[23:49] <sinzui> huwshimi: yep
[23:49] <huwshimi> ok great thanks.
[23:50] <lifeless> sinzui: I can see the brain damage on linux too ;)
[23:51] <lifeless> sinzui: would love it if we fix this.
[23:52] <sinzui> lifeless: I am hoping for a short brain storm session + a spike at the thunderdome to find a compromise that will let me close a UI bug
[23:59] <huwshimi> sinzui: When I try and land the branch it complains that the branch is not approved. On the MP the status is approved. Do I need to do anything else to get it to land?