[09:20] <adeuring> jtv: could you please review this MP: https://code.edge.launchpad.net/~adeuring/launchpad/bug-507642/+merge/20978 ?
[09:20] <jtv> adeuring: how dare you ask such a thing
[09:20] <jtv> especially of an oc...
[09:20] <jtv> oh, wait, I guess I can
[09:21] <adeuring> well I like to be a bit bold ;)
[09:24] <jtv> adeuring: bold enough for you
[09:24] <jtv> ?
[09:24] <adeuring> jtv: sure ;)
[09:25] <jtv> adeuring: bug snapshots are new to me... what is that?
[09:26] <adeuring> jtv: There is a calss Snapsshot somewhere... let me search again where exactly...
[09:26] <jtv> adeuring: not Schnapps-shot, surely
[09:27] <adeuring> jtv: erm, yes ;)
[09:27] <jtv> lazr.lifecycle..?
[09:28] <adeuring> jtv: yes
[09:29] <adeuring> jtv: anyway, for POSTs to the webservice API, a snapshot of the changed object is created.
[09:29] <al-maisan> jtv: is it OK if I enqueue https://code.edge.launchpad.net/~al-maisan/launchpad/partner-expiry-535030/+merge/20990 ?
[09:30] <adeuring> and this involves creating shortlists of collection fields
[09:30] <jtv> al-maisan: okay; I'm not too well though so be prepared for me dropping out at some point
[09:30] <adeuring> and if these collections are not short enough, the request fails.
[09:30] <jtv> adeuring: ok, I'll try to work with that
[09:33] <jtv> adeuring: do I understand this correctly?  Snapshots are made of these lists on a bug, and that process runs into the hardlimit.  So you stop snapshots from being made, and to test this, you set a tighter hardlimit for snapshotting and prove that you're not running into it?
[09:33] <adeuring> jtv: exactly
[09:34] <jtv> adeuring: that sounds a bit like you're second-guessing doNotSnapshot
[09:34] <adeuring> jtv: but the limit is reduced for tests only ;)
[09:34] <jtv> yes, I got that :-)
[09:35] <adeuring> jtv: and yes, that's the core idea of the test.
[09:35] <adeuring> jtv: it is a kind of simulation of the situation we have currently when you try to subscribe to bug 1
[09:36] <mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress> <ubuntu-e
[09:36] <jtv> adeuring: let's say I were to have a lot of faith in my fellow developers and reviewers in lazr-lifecycle.  Then I'd sort of expect a very similar test to have happened in their code already.
[09:36] <jtv> yes thank you mup, we hadn't forgotten that one
[09:37] <adeuring> jtv: well, perhaps. But what would this mean for the changes in my branch?
[09:37] <jtv> adeuring: that I think you're doing too much work
[09:38] <adeuring> maybe...
[09:38] <jtv> adeuring: I haven't read the full diff yet, but how about just testing that these fields are marked as doNotSnapshot, and saying why they have to be?
[09:39] <adeuring> jtv: let's assume that the necessity arises that we must include  one of the collections again in the snapshot.
[09:39] <jtv> adeuring: and frankly I'm much more interested in the functional consequences of not snapshotting these things... what differences will it make to users besides not exploding?
[09:40] <jtv> adeuring: that's a very good assumption; but if your test can just show _that_ the fields are doNotSnapshot, then your test will trip this up.
[09:40] <adeuring> jtv: I haven't noticed any. Discussed this with other people in the bugs team -- and all we am eup with: "try possibly relevant tests"
[09:40] <jtv> heh
[09:40] <adeuring> and none of those I tried did fail
[09:42] <adeuring> jtv: well, if we simply check a doNotSnapshot "decoration", we do not check if POSTs succeed or fail
[09:42] <bigjools> stub, gmb: thanks for reviewing my branch to change the update-pkg-cache dbuser, however the diff that LP generated is total garbage!
[09:42] <gmb> bigjools: Really?
[09:42] <bigjools> I think a db-devel/devel mismatch
[09:42] <jtv> bigjools: branched off devel, mp'ed for db-devel?
[09:42] <gmb> bigjools: Hah.
[09:43] <gmb> Oh, jow.
[09:43] <bigjools> jtv: other way around
[09:43] <gmb> Joy, even.
[09:43] <jtv> bigjools: then you're an idiot
[09:43] <jtv> :-P
[09:43] <bigjools> jtv: naturellement
[09:44] <bigjools> not sure how I managed it since I targeted the MP quite deliberately :/
[09:44] <gmb> bigjools: Well, send
[09:44] <jtv> adeuring: then again, you're dealing with a very specific failure in snapshotting, not one with posts per se
[09:44] <gmb> er
[09:44] <gmb> bigjools: ... me the actual diff and I'll take a look in a little bit.
[09:44] <jtv> adeuring: support for POSTs in general should be integration-tested, but I assume it is.
[09:45] <bigjools> jtv: no you were right t he first time
[09:45] <bigjools> gmb: http://pastebin.ubuntu.com/392395/
[09:45] <adeuring> jtv: fine, but I don't get your point...
[09:46] <gmb> Hah.
[09:46] <gmb> bigjools: Yeah, I think you can land that :)
[09:46] <jtv> adeuring: we know that POSTs normally succeed.  You're dealing with one very specific failure in that process.  I'm saying you could test for the fix to that specific failure, rather than test the full integration chain.
[09:46] <adeuring> jtv: OK, so, what sort of test would you suggest?
[09:47] <adeuring> just that these properties are not included in the snapshot?
[09:47] <bigjools> gmb: ta :)
[09:47] <adeuring> I think that's not a good idea
[09:47] <jtv> adeuring: a check that the necessary lists are doNotSnapshot, with a comment saying why this is needed so that people don't mindlessly change the test when it breaks.
[09:47] <adeuring> jtv: well, ok...
[09:48] <jtv> adeuring: separately, it could be nice to have the snapshotting mechanism improved for this sort of situation: don't snapshot if the lists get too long, or something.
[09:48] <adeuring> jtv: perhaps
[09:48] <jtv> The shortlist is presumably there as a way of detecting that the mechanism doesn't scale up to the things it's being used for, and that this sort of change may be needed.
[09:49] <jtv> adeuring: if/when the mechanism changes, you'd probably find that you lost your ability to reproduce the failure, and there'd be no test failure to indicate this.
[09:49] <allenap> Morning jtv :)
[09:49] <adeuring> jtv: good point
[09:49] <jtv> hi allenap!
[09:52] <adeuring> jtv: triggering the failure in the test is easy.
[09:52] <adeuring> jtv: ah, no...
[09:53] <jtv> adeuring: it would also be nice AFAICS if you could test for a realistic limit, so e.g. adding 1K subscribers; then once the snapshots are fixed, you could perhaps remove the doNotSnapshot and still have a test that proved that you didn't break things.  But you don't need to repeat that for all those fields AFAICS
[09:54] <jtv> (And if you're going to create persons in the factory, be sure to use makePersonNoCommit :)
[09:54] <adeuring> jtv: hrmm... I thoughy you suggested to only test for the "doNotSnapshot" decoration?
[09:54] <adeuring> s/thoughy/tought/
[09:55] <jtv> adeuring: I'm trying to meet you halfway here. :)
[09:57] <jtv> adeuring: actually, I'm just agreeing with you that it does make sense to try and show that the posts will now succeed.  But I'm also saying it makes sense to keep two parts of that separate: (1) doNotSnapshot fixes the problem, and (2) doNotSnapshot is applied in all the necessary places.
[09:58] <jtv> That way the testing problem goes from (test for cause of problem) × (test places where problem can happen) to (test for cause of problem) + (test places where problem can happen)
[09:59] <jtv> And if (test for cause of problem) involves a hard-limit of 1,000 objects....  :-)
[09:59] <adeuring> jtv: OK. But I not sure if creating 1000 persons without a commit works here. Doesn't the logout() calls imply a commit?
[10:00] <jtv> adeuring: I think it does, yes, but that's just once—I'm saying avoid committing a thousand times inside the loop.  Also, don't do this in the setUp since only one test will be needing it.  If you're lucky you can get away with these persons being flushed to the db but never committed.
[10:01] <adeuring> jtv: right
[10:01] <jtv> factory.makePerson secretly commits
[10:01] <jtv> ...after calling factory.makePersonNoCommit.
[10:01] <jtv> The commits are usually only needed afaik if you're planning to log in as the new person.
[10:26] <jtv> al-maisan: before I (or allenap) gets around to an actual review...  you're changing and adding some %s to big queries.  Maybe it's getting to the point where it's better use a dict there instead.  "%(x)s + %(y)s = %(z)s" % {'x': 1, 'y': 2, 'z': 3}
[10:27] <al-maisan> jtv: good point .. can do that.
[10:27] <jtv> Helps avoid annoying breakage while editing :)
[10:27] <al-maisan> yup
[10:36] <jtv> allenap: couldn't help myself, got drawn into muharem's branch :)
[10:38] <jtv> al-maisan: s/\<but refer\>/but referring/g
[10:38] <al-maisan> jtv, thanks, will correct that.
[10:38] <jtv> al-maisan: but is it really useful to enumerate what you're about to test?
[10:39] <allenap> jtv: That's okay :) I'm still getting my stuff together here.
[10:41] <adeuring> jtv: I pushed a new version of my branch to LP
[10:41] <jtv> al-maisan: I think it'd be more useful to explain for each of the test classes that you derive from the common-tests class what is specific to them.
[10:41] <jtv> adeuring: kuhl, danks
[10:42] <al-maisan> jtv: I see .. let me do that then :)
[10:43] <jtv> al-maisan: also, I don't know how runScript goes about its job, but it may be worth checking that it's not forking off a subprocess each time.  Otherwise you spend an eternity re-reading ZCML, and recovering the db afterwards.
[10:43] <al-maisan> jtv: I'll have a look.
[10:44] <jtv> thanks
[10:46] <jtv> al-maisan: I see you're running into complications loading the tests.  I think you can avoid those by not deriving ArchiveExpiryCommonTests from ArchiveExpiryTestBase; instead the specific test classes can multiply-inherit from both of those two.  That way the test loader doesn't come under the impression that ArchiveExpiryCommonTests is a test case.
[10:47] <jtv> adeuring: oooh, so much tighter!
[10:47] <al-maisan> jtv: will try that as well, thanks :)
[10:48] <jtv> adeuring: in test_no_snapshots_for_large_collections, can you add a note saying why there should be no snapshots (i.e. that the lists can get large enough to break the snapshot)?
[10:49] <jtv> I like the bug references in the test BTW.
[10:49] <adeuring> jtv: I can do that, but I thinks the the doc sting of the test class already has this note
[10:50] <jtv> adeuring: ah yes... that's cramming a lot of information into one sentence though.
[10:50] <adeuring> yeah, I have some bad habits ;)
[10:50] <jtv> (English is a relatively impatient language :)
[10:51] <jtv> adeuring: an American once wondered out loud what his country would have looked like if German had become the official language (as it almost did).  I told him people would be more polite in conversation, since you won't know what somebody's really saying until they've finished the last verb at the very end of the sentence.  :)
[10:52] <adeuring> jtv: could that be Mark Twain? He wrote some really hilarious comments about German
[10:53] <jtv> adeuring: unfortunately I have never been in the position to make smart-alec remarks to Mark Twain.  The scathing comebacks could have provided some jolly good fun at my expense.
[10:53] <jtv> This was an American who is alive today.  Or at least, was yesterday.
[10:54] <jtv> adeuring: "salgado-change-anything"..?
[10:54] <adeuring> jtv: ???
[10:54] <jtv> adeuring: hey, it's from _your_ test :)
[10:55] <adeuring> jtv: Ah, right... That's simple copy&pasted...
[10:55] <adeuring> jtv:  some modern comments about German and Germany: http://www.amazon.de/die-was-Ein-Amerikaner-Sprachlabyrinth/dp/3499622505/ref=sr_1_1?ie=UTF8&s=books&qid=1268218456&sr=8-1 A really nice read
[10:55] <jtv> adeuring: ah.  :)  Also in that test, could you turn the range(5) into range(snapshot.HARD_LIMIT_FOR_SNAPSHOT + 1)?
[10:55] <adeuring> jtv: sure
[10:56] <jtv> Labyrinth is feminine in German?
[10:56] <jtv> ah no, evidently not
[10:56] <jtv> The URL suggests that, but the page title makes clear that it isn't.
[10:58] <jtv> "Das Amerikan in das sprach labyrinth"
[10:59] <adeuring> yes. Really odd stories. He noticed a sign "durchgehend geöffnet" at a aupermarket and assumed he could buy stuff in the night...
[10:59] <jtv> Frankly I wouldn't have known better...
[10:59] <adeuring> jtv: sure,
[11:00] <adeuring> that requires strange "context knowledge"
[11:00] <adeuring> "durchgehend" means "not closed during lunch" ;)
[11:00] <jtv> ah!
[11:01] <jtv> adeuring: I think your branch is nearly there...  the setting and resetting of the snapshot limit is a bit ugly.  How about a "with"?
[11:02] <jtv> Not particularly urgent, but practicing it now may pay off in the future.  :)
[11:02] <adeuring> jtv: yes, I thought about that. But this fidding with a constant is done just here, so I did not see the point to use "iwth"
[11:03] <jtv> adeuring: sure, no worries.  If you're updating the range(5), r=me
[11:03] <adeuring> jtv: thanks!
[11:03] <jtv> I'll go do the paperwork.
[11:10] <al-maisan> jtv: BTW runScript() does not for off sub-processes..
[11:10] <jtv> al-maisan: good to know, thanks for checking it out.
[11:27] <al-maisan> jtv: the enhancements you suggested: http://pastebin.ubuntu.com/392443/
[11:28] <jtv> al-maisan: looking...
[11:45] <jtv> al-maisan: sorry, got sidetracked for a moment (figuring out why my job wasn't selected as a candidate).  Looking at your pastebin, too much indentation (or use of tabs) in param_names & param_values
[11:46] <al-maisan> jtv: right, will fix the indentation.
[11:46] <jtv> al-maisan: why not just create a dict directly?  Less fragile as the code continues to evolve
[11:46] <al-maisan> jtv: fine.
[11:47] <jtv> al-maisan: I'm not sure if sqlvalues will work on a dict, but it would be nice if it did.
[11:47] <jtv> al-maisan: but apart from that, I approve of the branch.
[11:47] <al-maisan> jtv: I don't think so .. that's why I used the dict(zip()) approach
[11:47] <jtv> al-maisan: you may want to use quote() on a single value instead of sqlvalues() on a bunch
[11:49] <al-maisan> jtv: hmmm .. that works for simple params .. in the code in question I have query params that are tuples ('archive_types')  .. would quote work for them as well?
[11:49] <jtv> al-maisan: I think you need sqlvalues for those
[11:50] <al-maisan> jtv: in which case I am stuck with dict(zip()) ..
[11:51] <jtv> al-maisan: or just doing { 'key': quote(value), ...}
[11:51] <jtv> (Which doesn't look all _that_ bad to me)
[11:52] <al-maisan> jtv: IIRC there's also an sqlvalue() function .. let me check.
[11:52] <jtv> al-maisan: sqlvalues will also work on one value though
[11:53] <al-maisan> jtv: ok .. I can use it like that then.
[11:54] <jtv> al-maisan: another question... where in the code was the candidate selection query again?
[11:55] <jtv> allenap: I'm bowing out in a minute
[11:55] <al-maisan> jtv: let me look
[11:55] <allenap> jtv: Okay, have a good day :)
[11:55] <jtv> thanks, you too
[11:56] <al-maisan> jtv: lib/lp/buildmaster/model/builder.py, line 475
[11:57] <al-maisan> .. and the lines preceding it
[11:57] <jtv> al-maisan: thanks... it's not selecting my arch-independent job because the Builder's virtualized seems to be set to False.
[12:03] <al-maisan> jtv: actually sqlvalues() does support named parameters and returns a dict in that case.
[12:03] <al-maisan> that's smart
[12:06] <al-maisan> jtv: so, here we go: http://pastebin.ubuntu.com/392467/
[12:10] <jtv> al-maisan: sheer beauty.  I've already approved the MP.
[12:14] <al-maisan> jtv: thanks :)
[12:15] <jtv> np
[12:16]  * jtv rushes off
[12:36] <adiroiban> danilos, henninge hi, can we schedule a preimplementation chat for bug 201749?
[12:36] <mup> Bug #201749: Impossible to mark as needing review strings already translated or with suggestions <story-translations-review> <ui> <Launchpad Translations:Triaged by adiroiban> <https://launchpad.net/bugs/201749>
[13:13] <danilos> adiroiban, sure, we can do it now if you want
[13:17] <adiroiban> ok. now, if you submit an empty translation, it will add a new translation and link it to the msgset (for a language)
[13:17] <adiroiban> is this correct?
[13:36] <adiroiban> and I was thinking that in the translationmessage, insead of adding a reference to an empty string, it should change the "is_current" to false
[13:36] <adiroiban> so that all msgstr linked with the current msgset are false
[14:25] <salgado> allenap, care to review https://code.launchpad.net/~salgado/launchpad/edge-redirect-bugs/+merge/21054 for me?
[14:26] <allenap> salgado: Sure!
[15:01] <adeuring> allenap: could you please review this mp: https://code.edge.launchpad.net/~adeuring/launchpad/bug-528569-api-bug-search-for-linked-branches/+merge/21058 ?
[15:10] <allenap> adeuring: Sure!
[15:11] <adeuring> allenap: thanks!
[15:28] <rockstar> allenap, can I jump on your queue?
[15:29] <allenap> rockstar: Go for it :)
[15:29] <rockstar> allenap, https://code.edge.launchpad.net/~rockstar/launchpad/bug-520446/+merge/21025
[16:23] <rockstar> allenap, can I add another branch to your queue?
[16:27] <sinzui> EdwinGrubbs: https://code.edge.launchpad.net/~sinzui/launchpad/api-bug-tracker-0/+merge/21061
[16:29] <danilos> adiroiban, hi
[16:29] <adiroiban> ok
[16:29] <adiroiban> I have also added a check in the browser layer
[16:29] <adiroiban> to check for „forged” needs_review or diverge form fields
[16:29] <danilos> adiroiban, so, what bug was that? (it seems you named the wrong one on #u-t
[16:30] <adiroiban> bug 201749
[16:30] <mup> Bug #201749: Impossible to mark as needing review strings already translated or with suggestions <story-translations-review> <ui> <Launchpad Translations:Triaged by adiroiban> <https://launchpad.net/bugs/201749>
[16:30] <danilos> adiroiban, or maybe not, not sure why it said it was private on #u-t
[16:30] <adiroiban> ... well.... a bug?
[16:31] <allenap> rockstar: A combination of a mammoth pre-implementation call with gmb, a car in need of repair, two cinema tickets and some pesky kids means I almost certainly won't get to your review today. I am very sorry, but I am happy to do it first thing in the morning if that's of interest to you.
[16:32] <rockstar> allenap, I can find someone else.  Thanks.
[16:32] <danilos> adiroiban, yeah, it was ubotu there, and it's mup here, ubotu might be broken :)
[16:33] <rockstar> allenap, I know how the EOD reviewer day goes.  :)
[16:33] <gmb> rockstar: Since since it was my fault that allenap was away for a while, I'll take your review.
[16:34] <danilos> adiroiban, first off, all comments should be full sentences that end with punctuation, so don't remove a period in one of those: and doing that when discussing things makes the diff larger and harder to read :)
[16:34] <gmb> rockstar: https://code.edge.launchpad.net/~rockstar/launchpad/bug-520446/+merge/21025 ?
[16:34] <rockstar> gmb, aye.  Thanks a lot.
[16:35] <danilos> adiroiban, ok, so what you are trying to do will cause a lot of trouble
[16:35] <danilos> adiroiban, it won't necessarily have the effect you want it to have
[16:36] <danilos> adiroiban, for instance, if current translation is diverged, and there is a shared one, this will make the shared one current, and the diverged one might show as a suggestion only accidentally (i.e. if it has a date_created newer than the shared one)
[16:36] <adiroiban> when I tick the „needs review” box, I do it because I think that the current translation is wrong
[16:36] <gmb> rockstar: Looks good. r=me.
[16:37] <rockstar> gmb, ta
[16:37] <danilos> adiroiban, right, but there is also that 'needs review' side of things that might not really work as desired
[16:38] <danilos> adiroiban, I agree unsetting it as current is an improvement over existing behaviour, but you can't do that as simply as unsetting a flag either; if it's diverged and there's an existing identical suggestion, one of those needs to be removed
[16:39] <danilos> adiroiban, finding all that out is pretty expensive, so I think a proper solution would be to introduce a new column on translationmessage table called something like is_reviewed
[16:39] <adiroiban> danilos: OK. Right now, I have no idea how diverged translations should be handled
[16:40] <danilos> adiroiban, it's all very, very complex, and there are some intricate bugs as well; doing it this way would just introduce more intricate bugs
[16:41] <danilos> adiroiban, in short, there's no simple solution to this
[16:41] <rockstar> gmb, do you think you could do another quick one?  Mostly just mechanical changes for javascript adhere to the style guide.
[16:42] <gmb> rockstar: Sure.
[16:42] <danilos> adiroiban, the solution would probably be to create a 'unsetTranslationMessage' on POTMsgSet that takes a template, language, variant as parameters
[16:42] <adiroiban> danilos: I'm trying to construct a test scenario for the use case described by you above
[16:42] <danilos> adiroiban, and then we can call that when we figure out that's what a user wants, and it'd be isolated from the rest of the updateTranslation (which is a mess, and should not be extended in any way)
[16:44] <danilos> adiroiban, look at lib/lp/translations/tests/test_potmsgset.py test_updateTranslation tests and how complex they are
[16:45] <danilos> adiroiban, making them even more complex is out of the question :) separate method which encapsulates the concrete meaning of the action is the way to go if you want to tackle this
[16:45] <adiroiban> ok
[16:45] <adiroiban> danilos: so I will move this logic in a new method
[16:46] <danilos> adiroiban, then you can worry about all the peculiarities of sharing and divergence for your specific use case in that particular method, because they'll be different
[16:47] <adiroiban> danilos: unfortunately, I don't know what should I do for divergent and sharing messages
[16:47] <danilos> adiroiban, right, and then you will have to come up with a good story for divergence and sharing; the biggest complication with all that is that diverged messages might be duplicated so once they are not used anymore, they should be aggregated
[16:47] <adiroiban> but if those cases have tests
[16:47] <adiroiban> I guess I can run the tests
[16:47] <danilos> adiroiban, well, for one, once you unset is_current, you should unset TM.potemplate as well
[16:47] <adiroiban> and improve the implementation
[16:48] <danilos> adiroiban, yeah, I'd be happy to help explain as much as possible
[16:48] <danilos> adiroiban, there are a lot of tests, and they are still not complete
[16:48] <adiroiban> danilos: translationmessage.potemplate ?
[16:48] <adiroiban> looking the in DB
[16:49] <adiroiban> that field is not set for all translations
[16:49] <danilos> adiroiban, yes, that indicates that that message is a divergence for a particular template (i.e. one coming from jaunty, where the shared version is used in karmic, lucid,...)
[16:49] <danilos> adiroiban, if potemplate IS NULL, you are looking either at a shared current/imported message, or at a suggestion
[16:50] <adiroiban> I see
[16:50] <adiroiban> ok
[16:50] <adiroiban> alse
[16:50] <adiroiban> else
[16:50] <adiroiban> is the ID of the specific potemplate
[16:50] <danilos> adiroiban, ideally, that would have been pofile, and we'd lose (potemplate, language, variant) on TM, but since we did incremental development, it was impossible to re-use pofile
[16:50] <danilos> adiroiban, that's right
[16:51] <adiroiban> ok
[16:51] <danilos> adiroiban, TM.pofile is basically an old field that's not up-to-date or correct anymore
[16:51] <adiroiban> I will take care of the TM.potemplate
[16:51] <adiroiban> ony other exception
[16:51] <adiroiban> ?
[16:51] <adiroiban> any other exceptions? :)
[16:51] <danilos> adiroiban, well, a bunch of corner cases that will pop up, I am sure
[16:52] <danilos> adiroiban, so, I'd have to ask you to get that branch past a Translations reviewer as well (nobody else would be intimate enough with the code), and we'll have to talk some more
[16:52] <danilos> adiroiban, I'd also have to carefully think about all of the exceptions and problems
[16:53] <danilos> adiroiban, basically, a TM is unreviewed suggestion if it has a date_created newer than the current translation; it means that the simplistic approach will just show all old (even those reviewed long ago) suggestions, which would be bad
[16:54] <danilos> adiroiban, because unsetting a currrent translation will remove the date_reviewed info, and then all suggestions would end up being unreviewed
[16:54] <danilos> adiroiban, so, that's another case to worry about; and when you introduce message sharing/divergence into it, it gets even "nicer" :)
[16:58] <adiroiban> danilos: why  is bad if you see all suggetions ?
[16:59] <danilos> adiroiban, because some have already been reviewed
[16:59] <danilos> adiroiban, and rejected
[16:59] <adiroiban> danilos: yes
[16:59] <adiroiban> but some were rejected by mistake
[16:59] <danilos> adiroiban, that's a different bug ;)
[16:59] <adiroiban> or were rejected based on some translation rules
[16:59] <adiroiban> that was now changed
[16:59] <danilos> adiroiban, well, different problem
[17:00] <danilos> adiroiban, we don't want them all to show up on a regular +translate page
[17:00] <adiroiban> danilos: but we can not tell which suggestion was already reviewed
[17:00] <danilos> adiroiban, yes we can
[17:00] <danilos> adiroiban, as I said, there's currently a clear concept of what a reviewed message is
[17:00] <danilos> adiroiban, anyway, I've got a call now, ttyl
[17:00] <adiroiban> ok
[17:00] <adiroiban> I will move the code in a separate logic
[17:01] <adiroiban> and will consider the cases we discussed here
[17:01] <adiroiban> and then we can have a new review
[17:02] <gmb> rockstar: Sorry... is it https://code.edge.launchpad.net/~rockstar/launchpad/code-js-reorg/+merge/20170 you want me to look at?
[17:03] <rockstar> gmb, yes
[17:03] <gmb> rockstar: Cool. Looking now.
[17:13] <gmb> rockstar: Looks good. r=me.
[17:33] <rockstar> gmb, so, the first branch that you reviewed - abentley_ and I just talked about it, and he suggested using a decorator to do the try/catch instead of doing it inside the method.
[17:33] <rockstar> (because what I was doing was crackful)
[18:03] <danilos> adiroiban, I am about to call it a day, is there anything I can do to help out while I am still here? :)
[18:03] <adiroiban> yes
[18:03] <adiroiban> can you please explain
[18:04] <adiroiban> in simple words
[18:04] <adiroiban> what should „needs review” do
[18:04] <adiroiban> from the point of view of users
[18:04] <adiroiban> it should just set the translation to empty
[18:04] <adiroiban> and mark the current translation as needs reviewn ?
[18:04] <adiroiban> review?
[18:05] <adiroiban> danilos: ^ :)
[18:05] <adiroiban> or it should dismiss the current translation?
[18:06] <adiroiban> and just leave the message untranslated
[18:06] <danilos> adiroiban, well
[18:06] <danilos> adiroiban, I think it should do that and leave all the other unreviewed suggestions as unreviewed suggestions
[18:07] <danilos> adiroiban, the message should end up untranslated, but with the previous active translation as another suggestion added to the existing set of suggestions
[18:07] <adiroiban> ok
[18:08] <adiroiban> and then, listing ALL suggestions should be another bug and should be displayed only in the zoom in view
[18:08] <danilos> adiroiban, btw, look at dismissAllSuggestions for a few ideas
[18:08] <danilos> adiroiban, that's right, and there's already that "another" bug filed :)
[18:09] <adiroiban> danilos: yes. I think I am assigned to that bug
[18:09] <danilos> adiroiban, bug 339507
[18:09] <mup> Bug #339507: translation page should show old translations <ui> <Launchpad Translations:Triaged by adiroiban> <https://launchpad.net/bugs/339507>
[18:09] <danilos> adiroiban, right
[18:10] <adiroiban> but I was thinking we can force showing all suggestions
[18:10] <danilos> adiroiban, and do take care of the TranslationConflict in a similar way (when someone changes translations after you have loaded the page)
[18:10] <adiroiban> by ticking the needs review
[18:10] <danilos> adiroiban, we shouldn't
[18:10] <adiroiban> danilos: ok :)
[18:10] <danilos> adiroiban, we'll get a very confusing behaviour of 'needs review'
[18:11] <adiroiban> danilos: ok. Many thanks!
[18:11] <danilos> adiroiban, now, you can perhaps say "it would make the implementation much easier, so I'd do that as a first step/branch", and then I'd agree :)
[18:11] <salgado> allenap, did you see my reply to that review you did for me?
[18:11] <danilos> adiroiban, you are welcome
[18:11] <adiroiban> danilos: :)
[18:11] <adiroiban> I will try to see how I will manage the implementation
[18:12] <adiroiban> and if I needs to split this job
[18:12] <danilos> adiroiban, sure, email whenever or we can talk some more tomorrow :) cheers
[18:12] <adiroiban> by
[18:12] <adiroiban> have a nice evening
[18:12] <danilos> adiroiban, thanks, so do you
[18:59] <rockstar> abentley, check out this (much better) diff.  We get the real exception now.  :)
[19:00] <rockstar> https://code.edge.launchpad.net/~rockstar/launchpad/bug-520446/+merge/21025
[19:30] <leonardr> gary, do you hvae a minute to review https://code.edge.launchpad.net/~leonardr/lazr.restful/version-descriptions/+merge/21075 ? it shouldn't take long
[19:42] <gary_poster> leonardr: yes
[19:46] <rockstar> Where have all our OCRs been the last two days?
[19:46] <gary_poster> leonardr: "[x for x in contents['service_doc']]" -> "list(contents['service_doc']]" ?
[19:47] <gary_poster> leonardr: lines 189 and 191 of diff
[19:47] <leonardr> gary: sure
[19:47] <gary_poster> cool
[19:48] <gary_poster> leonardr: do you intend to keep pdb around?  line 286
[19:48] <leonardr> gary, no, that's in by mistake
[19:48] <gary_poster> cool
[19:49] <gary_poster> leonardr: otherwise, r=gary.  Will mark as such.
[19:49] <leonardr> gary: also the mssing = object() needs to go
[19:49] <gary_poster> ah, ok.  Should have investigated more carefully then.
[20:09]  * kfogel is away: bbiab
[21:29] <rockstar> mwhudson, could you do a small review for me, mostly mechanical changes?
[21:30] <rockstar> (it's javascript)
[21:31] <mwhudson> rockstar: i can try!
[21:42] <rockstar> mwhudson, https://code.edge.launchpad.net/~rockstar/launchpad/code-js-file-reorg/+merge/21085
[21:43] <rockstar> mwhudson, sorry it's so boring.  :(
[22:13] <rockstar> mwhudson, as a matter of fact, the next branch is the branch that moves the javascript into lib/lp/code/javascript
[22:13] <mwhudson> rockstar: :)
[22:19] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/new-import-link-move/+merge/21088 for someone
[22:19] <thumper> diff should be along shortly
[22:21] <thumper> diff is up
[22:21] <rockstar> thumper, looking now.
[22:22] <thumper> rockstar: ta
[22:22] <rockstar> thumper, r=rockstar
[22:22]  * rockstar runs all the Windmill tests again.


[00:54] <erkules> Is there a way to manage lxc containers on different hosts? afaik local in environments.yaml is on one machine only
[03:02] <peterklipfel> who
[09:08] <mwalton> Hi, I'm new to juju, I've managed to deploy juju-gui, but I'm having trouble because I need to obtain charms via a proxy. Does anyone know now to set the proxy for juju-gui?
[09:11] <frankban> mwalton: what problems are you encountering?
[09:14] <mwalton> when I try to add a charm via the gui I get a name resolution error (the proxy I've set for juju is an IP) which means it's not using the proxy to access the charm store
[09:15] <mwalton> yet I can browse the charms
[09:15] <mwalton> search works
[09:15] <mwalton> The deployment errored: [Errno socket error] [Errno -3] Temporary failure in name resolution
[11:33] <adeuring> fwereade: could you have another look at https://codereview.appspot.com/68000045/ ?
[11:34] <fwereade> adeuring, sure
[12:05] <jamespage> marcoceppi_, hey - I just pushed some commits to my percona-cluster charm branch which use a new method for distributing passwords across a cluster
[12:05] <jamespage> all in mysql.py
[12:17] <mgz> jam: eg, http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-updates/cloud-tools/main/binary-amd64/Packages
[13:13] <prathamesh> Hi
[13:13] <prathamesh> i am writing a client/server zabbix charm
[13:13] <prathamesh> i wrote the zabbix server charm and it works fine
[13:14] <prathamesh> now i need to add a zabbix-client charm
[13:14] <prathamesh> so when i do juju add-relation zabbix-server zabbix-client
[13:14] <prathamesh> the client can upload entries into the server
[13:15] <prathamesh> mysql is integrated in zabbix-server
[13:15] <prathamesh> so i just need a relation between the zabbix server and client
[13:15] <prathamesh> can someone tell me how to write the relation-joined hook
[13:15] <prathamesh> or relation-changed
[13:47] <mwalton> has anyone had much success using juju in an environment that requires a proxy for internet access?
[13:49] <mwalton> I've managed to use set-env http-proxy to configure the proxy, but found that on an install hook of keystone, it tries to access localhost, and tries to go through the proxy for that
[14:23] <lazyPower> mwalton: did you have a look at this post? http://askubuntu.com/questions/11274/setting-up-proxy-to-ignore-all-local-addresses
[14:24] <lazyPower> im not real familiar with how juju forwards the proxy information around, but i assume that you can set this type of configuration on the proxy server so it auto-configures the hosts.
[14:24] <lazyPower> and more implicitly - http://askubuntu.com/a/42271/6807 that response.
[14:32] <jam> sinzui: ping about bug #1289376
[14:32] <_mup_> Bug #1289376: Cannot build r2379 on amd64+precise <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1289376>
[14:32] <jam> that looks like your build host suddenly changed what version of "go" it is using
[14:32] <jam> the one that is in the Precise archive can't build juju-core today
[14:33] <jam> you have to use the ppa:juju-core/golang one
[14:34] <jam> oops, should be in the other channel
[14:34] <sinzui> jam, I thought I was.
[14:34] <jam> *I* should have been
[15:07] <marcoceppi_> Can we agree just not to use camelCase in bundle names?
[15:08] <mbruzek> WhatIsWrongWithCamelCaseMarco?
[15:08] <marcoceppi_> we hardly use camelCase at all anywhere else in juju, why it's envExport and not env-export or envexport or export is beyond me
[15:08] <marcoceppi_> nothing, it's just, we're tip-toeing down the path of php where we don't have a really well defined convention and it's going to make a lot of sad pandas
[15:11] <mbruzek> I am all for having a recommended convention.  What do you suggest?
[15:11] <lazyPower> I +1 the notion of consistency, whether that be camelCase or _underscore usage, just be consistent.
[15:11] <marcoceppi_> the precendence seems to be mostly "-", with second most being _
[15:11] <marcoceppi_> and I don't think I've come across a camelCase example except for what the GUI exports
[15:12] <lazyPower> i smell a bug # in marco's future
[15:12] <marcoceppi_> I'm composing one atm
[15:13] <mbruzek> Just to be clear the charm and bundle authors can write in camelCase right?
[15:13] <mbruzek> marcoceppi_, is just talking about the juju tools not using camelCase
[15:13] <mbruzek> Right?
[15:14] <marcoceppi_> right, there's no limiting you to what you can use, I just thing we should /strongly/ recommend people follow a convention
[15:14] <marcoceppi_> and then promote consisteny inside that charm/bundle
[15:14] <marcoceppi_> so if a charmer /really/ //really// wants to use camelCase in config options, they can, but all config options should be in camelCase at that point
[15:14] <mbruzek> OK.
[15:15] <mbruzek> But required fields that the juju tools read in should not be in camelCase.
[15:16] <marcoceppi_> mbruzek: expand
[15:16] <nessita> hello everyone! quick question: I have juju installed from ppa:juju/devel, and I was wondering if I can have amulet from somewhere (devel ppa does not provide it)
[15:17] <marcoceppi_> nessita: add the stable ppa
[15:17] <mbruzek> I don't like imposing rules on creative people.  Let them write in camelCase if they want.  But we can make guidelines that the required fields or words that are in the config.yaml, metadata.yaml and other things that Juju looks for are not camel case.
[15:17] <marcoceppi_> nessita: all tools, and stable relesases of juju are in ppa:juju/stable; dev releases of juju are in ppa:juju/devel
[15:18] <nessita> marcoceppi_, ok, so the 2 ppas will not "conflict"?
[15:19] <marcoceppi_> nessita: correct, juju stable releases are versioned as 1.EVEN and development releases are 1.ODD; so if you add the stable and devel ppa you'll always get the latest (wether it's dev or stable, depending on the release cycle)
[15:19] <marcoceppi_> so, current stable is 1.16.6 and devel is 1.17.4; in dpkg 1.17.4 > 1.16.6 so you'll get that. when 1.18 (next stable) lands you'll just be upgraded to that automatically
[15:20] <nessita> marcoceppi_, it sounds great. Thanks a lot!
[15:20] <marcoceppi_> lazyPower: did you confirm that d.sentry.wait is actually problematic on your deployments outside of the jenkins stuff?
[15:21] <mbruzek> marcoceppi_, I think it is fine that Juju has consistency on the keywords that it expects to see in the files (as not being camel case).  But some programming language guidelines recommend camel case for variables and Juju should accept those as valid.
[15:22] <marcoceppi_> mbruzek: I'm not talking about in hooks, just in general, charms should be consistent within themselves.  Same with a config.yaml file. It shouldn't have a mix of camEl/_/- delimited config keys
[15:22] <marcoceppi_> It should use one method and stick to it
[15:22] <marcoceppi_> and we should recommend X for users who don't know what to use
[15:22] <mbruzek> Yeah that looks logical.
[15:22] <jcastro> marcoceppi_, I can agree to no camelCase.
[15:23] <jcastro> marcoceppi_, my opinions on the entire bundle URL structure are well documented. :)
[15:24] <mbruzek> marcoceppi_, The first thing I would check is that there are no camelCase keywords in Juju or Amulet, or Charm-tools, etc so that we are consistent before recommending others do the same.
[15:24] <marcoceppi_> right, just saying envExport is misleading and I'm going to file a bug
[15:24] <marcoceppi_> mbruzek: I know for a fact that amulet and charm-tools have no camelcase options
[15:24] <jcastro> marcoceppi_, hey, while you file
[15:24] <mbruzek> I don't know what envExport you are referring to.
[15:24] <marcoceppi_> and I'm like 99% that all configuraiton optoins are also not camelCase'd in juju
[15:24] <jcastro> it's silly that the export tool exports something that is not immediately redeployable
[15:24] <marcoceppi_> mbruzek: export a bundle from teh gui
[15:24] <marcoceppi_> jcastro: basically,  yes, it is
[15:24] <jcastro> maybe have it generate something?
[15:25] <marcoceppi_> jcastro: as I understand it, the gui team has a task to prompt for a name
[15:25] <marcoceppi_> jcastro: at least, that was my impression for roadmap stuff
[15:25] <jcastro> perfect
[15:25] <marcoceppi_> may want to double check that
[15:25] <jcastro> roadmap as in handwavy roadmap from rick_h_ or have you seen a real bug report?
[15:26] <marcoceppi_> jcastro: hand wavy, but can't remember who waved their jedi-like hands at me
[15:26] <jcastro> that's because they were tricking you
[15:26] <marcoceppi_> which is why I recommend dbl chking
[15:26]  * jcastro nods
[15:26] <jcastro> I'll file my bundle UI nitnoids now too
[15:28] <marcoceppi_> lazyPower: what charms did you write already, papertrail and...?
[15:36] <nessita> marcoceppi_, when you can, would you please give me a hand with amulet usage? every command I've tried is failing, even --help as per https://pastebin.canonical.com/106147/
[15:37] <nessita> marcoceppi_, even involkin $ amulet with no params fails
[15:37] <marcoceppi_> nessita: sorry, that's a bit of a misnomer that's being removed in the next release, amulet the command line option doesn't do anything. Currently it's only available as a python module
[15:37] <marcoceppi_> nessita: https://juju.ubuntu.com/docs/tools-amulet.html
[15:37] <nessita> marcoceppi_, thanks
[15:37] <marcoceppi_> the Programmable api section of the docs are forthcoming, but not currently available and a few releases ago broke what little functionality there was
[15:47] <lazyPower> marcoceppi_: just papertrail is all that's been accepted to the store. i have a WIP for Errbit, GitLab-CI, GitLab, and i'm rewriting PHPMyAdmin in ansible
[15:49] <lazyPower> marcoceppi_: d.sentry.wait() isn't misbehaving outside of the CI stuff. Its working fine when invoked via the juju test runner.
[16:07] <marcoceppi_> ta
[16:07] <marcoceppi_> lazyPower: then it's something in the CI that's being weird
[16:07] <marcoceppi_> sinzui: is there anyway I can get access to the instance that's running the charm testing stuff?
[16:07] <sinzui> marcoceppi_, I think you have.
[16:07] <marcoceppi_> via ssh?
[16:07] <marcoceppi_> huh, let me try
[16:07] <marcoceppi_> lazyPower: is there a bug for the amulet post deployment commands not working?
[16:07] <lazyPower> there was you closed it
[16:07] <lazyPower> let me see
[16:07] <lazyPower> OH
[16:08] <lazyPower> you mean what i found on wednesday, nope. Let me file one real quick
[16:15] <marcoceppi_> lazyPower: thanks
[16:16] <marcoceppi_> lazyPower: just file bugs and how you got the bug when you see them, I tend to forget when they're just reported in IRC
[16:16] <marcoceppi_> lazyPower: it's easier to close a bug as not a bug than remember all the little errors I've codified into these projecs
[16:19] <lazyPower> ack. i'm running the test on jenkins now with a config change
[16:19] <lazyPower> to get you a strace
[16:19] <marcoceppi_> lazyPower: won't it take, like 45mins to error out because it's hitting timeout?
[16:20] <lazyPower> marcoceppi_: no because the d.configure() statement turned into chunky salsa
[16:21] <lazyPower> http://paste.ubuntu.com/7039200/ -- which is goign in the bug report
[16:23] <lazyPower> and now i'm getting the forever timeout on d.sentry.wait() - thats so strange that I wasn't hitting it yesterday
[16:23] <lazyPower> this is very inconsistent
[16:23] <lazyPower> ah, disregard, it was hung up on haproxy doing its thing.
[16:24] <marcoceppi_> lazyPower: we're talking about two different bugs I think
[16:24] <marcoceppi_> there's d.sentry.wait not working in jenkins, but elsewhere
[16:24] <marcoceppi_> and then there's post deployment commands failing
[16:25] <lazyPower> marcoceppi_: i'm talking about post deployment commands failing
[16:25] <lazyPower> because d.sentry.wait() works locally, but not in jenkins.
[16:25] <marcoceppi_> lazyPower: right, I'm investigating the jenkins thing in abit
[16:26] <lazyPower> and i don't have any information there. the only thing i can figure is its using an older release of amulet - that doesn't have that rework of d.sentry.wait() applied. Did we validate that its running 1.3.3?
[16:26] <marcoceppi_> lazyPower: it installs it in a fresh LXC for every run
[16:26]  * marcoceppi_ will investigate later
[16:27] <lazyPower> i'll spin up a precise VM and run via juju test runner to validate its not coming from that config, and isolated to being run through the substrate dispatcher in jenkins.
[16:35] <lazyPower> running now, here goes nothing
[16:53] <bloodearnest> rick_h_: random question: any plans to make the gui code browsers understand symlinks to a hooks.py? I guess that's a Hard Problem.
[16:53] <bloodearnest> unless they parse @hooks.hook(name)
[16:53] <rick_h_> bloodearnest: so no current plans. I thought we duped the file contents in charmworld. Which charm?
[16:53] <rick_h_> oh, no we don't do any of that
[16:54] <bloodearnest> rick_h_: mongodb
[16:54] <bloodearnest> rick_h_: yeah, it's tru=icky, but it makes the code browser difficult to use in such cases
[16:54] <bloodearnest> true and icky - truicky
[16:54] <rick_h_> yea, don't think it's on the radar at the moment
[16:55] <bloodearnest> rick_h_: fair enough
[19:14] <zchander> Hi all. I am trying to get Maas and Juju working together as a test for our school network. Does anyone have any documentation about how to set up the network so we can access  deployed charms when the nodes don't have any access to the school network. (maas region/cluster controller combo is gateway for nodes)?
[20:26] <manjiri> hello all. What guidelines do I need to follow for including the 'charmhelpers' in my charm that I would like to push to my launchpad account?
[20:44] <kliieef> which one?
[20:45] <kliieef> 1. sudo apt-get install juju-core
[20:45] <kliieef> 2. sudo apt-get install juju juju-local charm-tools
[20:45] <kliieef> ?
[20:46] <kliieef> juju / juju-core?
[20:53] <marcoceppi> kliieef: juju is juju-core
[20:53] <marcoceppi> manjiri: you need to embed them directly from lp:charm-helpers
[21:35] <zchander> What would be the best solution to reach my deployed/exposed juju-gui when the node is in a private (cluster)network with MAAS? Do i need to set up some reverse proxy, or....?
[21:57] <marcoceppi_> zchander: either a reverse proxy, or a VPN to that network
[21:58] <zchander> OK, is there some how to available on the net? I tried to do a reverse proxy (using apache 2 on the MAAS controller), but somehow I don't succeed.
[22:13] <manjiri> marcoceppi: Can you elaborate on what "embed directly" means?


[11:26] <greyback> hi folks, Mir on my desktop is failing with this: inkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
[11:27] <greyback> alf_: ^^ isn't that an android driver?
[11:35] <greyback> never mind, had libhybris installed
[12:03]  * ogra_ wonders what an inkerlinker is ... and which color the ink actually has :)
[12:12] <greyback> alf_: ping
[12:14] <greyback> alf_: unping
[12:16] <tvoss> lol
[13:29] <greyback> tvoss: just fyi, have figured out the crash I was having. I was trying to fetch display information (calling the_display) before I'd started the mir server. That caused the_display to be called twice, which set up a context twice
[13:30] <tvoss> greyback, ack
[13:50] <alan_g> tvoss: Does this look right to you? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/fix-local-build/+merge/195063
[13:51] <tvoss> alan_g, approved
[13:52] <alan_g> you didn't even test it.!
[13:55] <tvoss> alan_g, kinda obvious that it is correct
[13:56] <davmor2> tvoss: doesn't mean it works though :P
[13:56] <tvoss> davmor2, agreed, but this is really obviously a correct fix :)


[05:39] <Kilos> ha
[05:47] <CraigZim> ha ha
[05:48] <Kilos> hi CraigZim
[05:48] <Kilos> helloooo africa
[08:11] <Kilos> hi Na3iL
[08:30] <Na3iL> Hello Kilos hello Africa
[09:45] <elacheche> hello
[09:45] <elacheche> !
[09:46] <Kilos> hi elacheche
[09:56] <elacheche> Did you got my private message?
[09:56] <elacheche> yesterday
[09:57] <Kilos> yes ty about the email?
[09:57] <elacheche> yep
[09:57] <Kilos> i answered in the pm as well i think
[09:57] <Kilos>  mage


[02:10] <imgbot> [03:55] <imgbot> [03:55] <imgbot> [04:36] <rsalveti> nice, many great fixes
[04:36] <rsalveti> we should promote 171 as well
[08:48] <pete-woods> trainguards: I fixed my not approved silo (#27), if someone could push the publish button again :)
[08:52] <Mirv> pete-woods: ok!
[09:07] <pete-woods> Mirv: thanks!
[09:09] <Mirv> np
[10:52] <Laney> cihelp - hi, looks like syncing of autopkgtest results to the public jenkins instance is broken - e.g. okteta has up to job #94 internal but only shows #85 on jenkins.qa.u.c
[13:06] <rvr> rsalveti: ping
[13:08] <rvr> rsalveti: I'm about to approve silo 9 (network-manager, reconnect). In the spreadsheet it says "Additionally it also needs to be validated with Modem Manager (Ubuntu Desktop, using an external modem dongle)."
[13:09] <rvr> rsalveti: We are not doing any desktop related testing right now.
[13:09] <rvr> rsalveti: Is that already validated by your team?
[13:09] <rsalveti> nops, and unfortunately we don't have a usb dongle in hands to test
[13:09] <rsalveti> we need to test the desktop side in order to land this though
[13:32] <rsalveti> rvr: davmor2: do you guys know if someone from QA has an external modem dongle to validate that silo?
[13:32] <rsalveti> this is host side validation for modem manager
[13:34] <davmor2> rsalveti: how do you mean an external modem dongle?   I have 2-3 usb dongles
[13:35] <davmor2> rsalveti: are we talking just wifi for desktop though?
[13:36] <rsalveti> davmor2: desktop, yeah, a usb modem dongle
[13:36] <rvr> davmor2: I think it is for 3G dongles
[13:36] <rsalveti> yup, 3g dongles
[13:36] <rsalveti> need to find someone that has one at least
[13:37] <rsalveti> one that is known to work with modem manager
[13:38] <rvr> rsalveti: I have a USB 3G dongle that in the past has worked with Ubuntu
[13:39] <rvr> rsalveti: But I'm not happy having to test desktop silos, we are not doing that.
[13:39] <rvr> rsalveti: So, I can do it *exceptionally*
[13:39] <rsalveti> rvr: well, it's the only way to land this
[13:39] <rsalveti> rvr: in order to avoid regressions on the desktop
[13:39] <rsalveti> we don't have only ubuntu touch here
[13:40] <rsalveti> and some components might affect the desktop
[13:40] <rsalveti> so doing some sanity testing with the desktop, sometimes, are expected
[13:40] <rvr> That's exactly the signal I don't want to emit
[13:42] <rvr> QA team are not the testing guys with lots of free time to check everything, we are gating phone silos to prevent regressions in the devices because that's the priority. Don't expect otherwise.
[13:43] <rsalveti> sure, but the goal is having a better phone product, right?
[13:43] <rsalveti> and we can't necessarily land without validating the desktop, in this case
[13:43] <rsalveti> we'd do the validation ourself, if we had the hardware in hands
[13:44] <rvr> That's why, exceptionally, I'll help you validating that it works in the desktop
[13:45] <rsalveti> rvr: great, this is not a rule for sure, it's just that we don't have the hardware
[13:45] <rsalveti> rvr: thanks
[13:46]  * rvr downloads the latest Vivid image
[13:52] <davmor2> rvr: rsalveti I have a 3g dongle that works I just have no credit on it and I'm on vivid
[13:52] <rsalveti> davmor2: can't you use the same sim card you use on arale/krillin?
[13:52] <rvr> davmor2: The silo is for Vivid
[13:54] <davmor2> rsalveti: I don't think they are on the same network let me check
[14:01] <rvr> Ok, mine is recognized in Utopic
[14:05] <robru> lool: got you silo 5
[14:07] <robru> ted: silo 14 for your vivid+1 refund work
[14:08] <ted> robru, Oh, sweet, thanks!
[14:08] <robru> ted: you're welcome!
[14:08] <davmor2> rsalveti: hang on do I need to go to a specific site I have a feeling this will let me connect to 3 for top up let me test that
[14:11] <davmor2> rsalveti: meh no
[14:12] <rsalveti> davmor2: doesn't work or just not compatible with your sim?
[14:12] <davmor2> rsalveti: only works with 3 so doesn't work with the giffgaff sims I have and maybe too old too :(
[14:13] <rsalveti> davmor2: got it, no worries
[14:13] <davmor2> rsalveti: I have a mifi too but that takes care of the modem part so that is no use I guess
[14:20] <om26er_> salem_, Hi!
[14:20] <salem_> om26er_, hello
[14:21] <om26er_> salem_, silo 29 failed. It does not fix the bug :/
[14:21] <om26er_> see my comment here: https://trello.com/c/yGde8ScD/1388-ubuntu-landing-029-messaging-app-boiko
[14:23] <psivaa> Laney: The jenkins publishing queue is quite long, public one being very slow, okteta #96 is on the way
[14:23] <Laney> psivaa: is it going to catch up and stay caught up?
[14:23] <psivaa> Laney: that's the intention
[14:24] <salem_> om26er_, ok, I will have a look. thanks
[14:25] <boiko> om26er_: so, you send messages from one SIM to another, right?
[14:32] <om26er_> boiko, I send the message to myself
[14:32] <om26er_> from the same sim to the same thing, but that should not be different.
[14:34] <boiko> om26er_: ok, just curious, because I tried this multiple times and it works on every try :/
[14:40] <boiko> om26er_: nevermind, just reproduced the case you mentioned
[14:51] <sil2100> jibel: I suppose let's join the RTM meeting each of us on his own PC, no need to share a screen
[14:51] <jibel> sil2100, agreed, it's even more difficult to share a headset :)
[14:52] <sil2100> I'm a bit worried about the internet quality here
[14:53] <rvr> sil2100: Are you also in Austin?
[14:53] <jibel> sil2100, I just had another HO and it's ... painful
[14:53] <sil2100> rvr: yes
[14:53] <rvr> Nice
[14:53] <rvr> rsalveti: Ok, USB with Vivid booted on my laptop, now I'll install the citrain tools and the silo
[14:54] <rsalveti> rvr: great, thanks
[14:59] <lool> dpkg-source: error: syntax error in /var/lib/jenkins/silos/ubuntu/landing-005/ubuntu-location-provider-here_0.1+15.04.20150127~rtm-0ubuntu1.dsc at line 1: line with unknown format (not field-colon-value)
[14:59] <lool> interesting
[15:00] <lool> it works for me here
[15:00] <lool> robru: I think I'm going to require some help fixing this ^
[15:00] <lool> is it because it's running an older dpkg-source maybe?
[15:01] <rvr> davmor2: Is there a way to log into unity 7 in Vivid ISO?
[15:01] <rvr> davmor2: Unity Next is presented instead
[15:02] <davmor2> rvr: did you get the daily iso or the ubuntu-next iso
[15:02] <rvr> vivid-desktop-amd64.iso
[15:03] <davmor2> rvr: yeah but from where
[15:03] <rvr> davmor2: http://cdimage.ubuntu.com/daily-live/20150414/
[15:04] <davmor2> http://cdimages.ubuntu.com/daily-live/current/
[15:07] <jibel> rvr, download from pending instead of current
[15:08] <rvr> Ok
[15:27] <om26er_> seb128, Hi!
[15:27] <seb128> om26er_, hey
[15:28] <om26er_> seb128, re: silo 06, it looks like the fix for bug 1438049 could have some autopilot tests
[15:29] <om26er_> and the battery fix needs to be added to the TestPlan.
[15:29] <seb128> om26er_, I guess it could, I've no slot for that this week and I'm travelling/to a sprint next
[15:30] <seb128> om26er_, so either we delay by that and forget about those fixes for vivid or you ack it like that
[15:31] <om26er_> seb128, Theses fixes don't look very critical so I guess we can delay this landing.
[15:32] <seb128> om26er_, shrug
[15:33] <seb128> om26er_, there is a segfault fix, one usability issue coming from our user testing and a quite visible bug (discharge graph being wrong when waking up the device)
[15:34] <seb128> om26er_, but oh well, if you want to throw the work again please do
[15:34] <om26er_> seb128, yes, we are asked to not land silos without test so I'd prefer not go around that. Unless someone from mgmt approves that.
[15:35] <om26er_> it might make sense to re-upload the silo with the focus fix removed.
[15:35] <seb128> pmcgowan, kenvandine, jgdx, ^ fyi, the fixes in silo 006 (trivial ones) are blocked by qa, I've no slot for writting test in the next week, should we just discard the work and let segfaults & co in vivid?
[15:36] <robru> lool: checking
[15:36] <jgdx> seb128, I don't know what segfaults & co is
[15:36] <seb128> jgdx, segfault is the null check in the bluetooth panel
[15:37] <seb128> I hit that segfault a few time on my bq
[15:37] <seb128> the co are the focus fix, and the one to refresh the discharge graph on wakeup/focus
[15:37] <robru> lool: https://ci-train.ubuntu.com/job/cyphermox-test/893/console indeed that's a funny looking DSC, I never saw one in xml before ;-)
[15:38] <cyphermox> robru: and I thought you were pinging me :)
[15:38] <robru> cyphermox: do you want me to rename the job so we stop pinging you? ;-)
[15:39] <cyphermox> as you wish, it's just funny :)
[15:39] <robru> lool: https://ci-train.ubuntu.com/job/ubuntu-landing-005-1-build/133/console indeed it is just a transient network issue, restarted the build and it looks ok now
[15:39] <jgdx> seb128, okay dokay
[15:53] <pmcgowan> jgdx, so is creating tests for those something you can do
[16:02] <rvr> jibel: davmor2: I downloaded the correct image, and only suggests to try Ubuntu Next
[16:03] <rvr> Hmm
[16:03] <rvr> Let me check whether I overwrote the wrong image
[16:04] <rvr> md5sum -c MD5SUMS vivid-desktop-amd64.iso: OK
[16:06] <lool> robru: thanks
[16:06] <robru> lool: you're welcome
[16:22] <davmor2> rvr: is it a saying what next try ubuntu install ubuntu
[16:23] <davmor2> and has been mis-translated?
[16:23] <rvr> davmor2: I'm only offered to try Unity 8 or to install it, not to launch Unity 7
[16:23] <davmor2> rvr: that image is only unity 7
[16:24] <davmor2> rvr: let me grab it
[16:24] <rvr> davmor2: Well...
[16:24] <rvr> davmor2: md5sum tells me it is the right image in http://cdimages.ubuntu.com/daily-live/pending/
[16:24] <rvr> davmor2: I downloaded http://cdimages.ubuntu.com/daily-live/pending/vivid-desktop-amd64.iso
[16:31] <rpadovani> sil2100, does this fix the AP issue with calculator? In the first moment I created the project with app/tests because thatś what the QML App with Simlpe UI (cmake) does in the sdk
[16:31] <rpadovani> https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/fixApDirectory/+merge/256175
[16:38] <seb128> sil2100, hey, is there a known issue with vivid update giving a non working calculator?
[16:38] <seb128> the icon is missing in the dash and it doesn't start, aa-exec complains about the missing apparmor profile
[16:40] <sil2100> seb128: hm, I didn't know anything, it worked fine for ubuntu-rtm - we had a reboot landed recently, maybe vivid doesn't have the right apparmor profiles for it yet
[16:40] <sil2100> cwayne: ^ did you have to update something in the custom tarball for 14.09 when the new calculator app landed?
[16:40] <cwayne> sil2100, noep
[16:42] <sil2100> rpadovani: hey! Let me take a look :)
[16:43] <rpadovani> sil2100, sorry, had to fix CMake, now shoulb de ok :-)
[16:43] <sil2100> rpadovani: hah, yeah, just commented on that ;)
[16:44] <sil2100> rpadovani: will the unit tests still work now?
[16:44] <sil2100> I suppose there are no paths that need to be changes in the AP tests themselves, right?
[16:45] <rpadovani> sil2100, afaik unit tests are the ones created by the sdk template
[16:45] <rpadovani> sil2100, no idea, autopilot and I aren't good friends :P
[16:46] <sil2100> bzoltan: hey, I was wondering, since it seems the SDK template creates the test directory in app/tests - is that a standard now?
[16:46] <sil2100> bzoltan: is that also the directory for AP tests?
[16:46] <sil2100> Since if that's the new standard, we'll have to modify phablet-click-test-setup
[16:52] <bzoltan> sil2100:  rpadovani: there is no such standard writen anywhere. It is more like a best practice
[16:53] <sil2100> bzoltan: is that also the best practice directory for AP tests?
[16:53] <sil2100> Since if more people use this directory this way, the AP-test tools need to be accomodated
[16:53] <sil2100> As now they only look for tests in tests/
[16:55] <bzoltan> sil2100:  tests can be anywhere as far as  I know.
[16:55] <sil2100> bzoltan: not for phablet-click-test-setup
[16:59] <jibel> sil2100, that's a bug in phablet-click-test-setup, it shouldn't explode if it doesn't find the tests where it expects them to be
[17:00] <jibel> tests can be anywhere, the tool should be smarter in its discovery
[17:03] <bzoltan> sil2100:  well.. that is the problem of the phablet-click-test-setup :) it should be smarter
[17:08] <om26er_> cihelp Hi! whats happening with smoke testing results, seem last appears on 10th April: http://ci.ubuntu.com/smokeng/vivid/touch/
[17:11] <sil2100> bzoltan, jibel: yeah, in theory, but making it smarter would mean it would have to scan the whole directory tree for tests which in theory can have various forms and format
[17:11] <sil2100> *formats
[17:11] <sil2100> Making it smart would mean writing a lot of guessing code
[17:12] <sil2100> Sure, could be smarter, but best following certain pre-defined standards for that to avoid problems
[17:12] <jibel> sil2100, use adt in CI instead, problem solved
[17:13] <jibel> sil2100, and again if p-c-t-s doesnt' find tests it shouldn't explode
[17:13] <jibel> just ignore it
[17:14] <jibel> cihelp; ^ is anyone on this, there is no result on the dashboard for the last 5 days
[17:15] <psivaa> jibel: om26er_: looking into it, the network being slow does not help
[17:20] <boiko> om26er_: salem_: so, the fix is correct, it is just not working because of a regression I introduced on a previous change, I will add an MR to the silo to get it fully working
[17:21] <boiko> om26er_: salem_: luckily it is just a one-line change
[17:22] <om26er_> boiko, one line fixes are the best ones :)
[17:26] <boiko> om26er_: that's a pitty they are so rare
[17:27] <boiko> om26er_: so, I will add the extra MR to the silo, and re-test it
[17:29] <boiko> trainguards: can I get vivid silo 29 reconfigured? I added a new component there (telephony-service)
[17:30] <sil2100> boiko: on it
[17:31] <rpadovani> sil2100, Jenkins is now happy with https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/fixApDirectory/+merge/256175
[17:31] <rpadovani> afaics, it's all we need
[17:31] <sil2100> rpadovani:
[17:31] <sil2100> rpadovani: \o/
[17:31] <sil2100> rpadovani: I'll check that after lunch and approve if anything
[17:31] <sil2100> rpadovani: thanks :)
[17:32] <sil2100> boiko: reconfigured
[17:32]  * sil2100 lunch, suspending
[17:32] <boiko> sil2100: great! thanks! enjoy your lunch :)
[17:33] <rpadovani> sil2100, thanks, enjoy :-)
[17:34] <bzoltan> sil2100: you are right. It is a double edged sword you know... I could come up with a strict app structure back 2 years ago to serve these types of automatization, discoverability and many other things... believe me there are other areas where a strict app structure policy would be beneficial. For example API control is easier. But community folks and app developers together with hyperfree hipsters woluld have  stond me if I tell them that they need to
[17:34] <bzoltan> follow a policy :D
[17:42] <rpadovani> bzoltan, I think 90% of developers follow sdk templates :-)
[17:43] <bzoltan> rpadovani:  I hope so :)
[17:54] <jgdx> pmcgowan, I think so, if all there is to it is: making a AP test for the highlight in security/privacy, and a section in the testplan for the battery fix.
[17:54] <jgdx> bfiller, ping
[18:21] <boiko> om26er_: silo 29 updated, no more changes required on messaging-app itself, just the extra MR on telephony-service itself
[19:08] <bfiller> jgdx: pong
[22:00] <robru> lol, no
[22:01] <sil2100> huh?
[22:10] <robru> sil2100: silo 15 is mine, i don't want to publish it. clicked that by mistake
[23:01] <sil2100> o/