=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== Saviq_ is now known as Saviq
[08:33] <jin_> dpm: ping
[08:33] <dpm> hi jin_, please, feel free to ask directly, no need to ping first
[08:34] <jin_> dpm: thanks for your comment in the MP I raised
[08:34] <jin_> I left some comments there and need you to take a look ;)
[08:34] <jin_> sending you the link:
[08:34] <jin_> dpm: https://code.launchpad.net/~libqtelegram-team/telegram-app/remove-po-files-from-version-control/+merge/288883
[08:35] <jin_> dpm: any comments from you will be welcomed, thanks!
[08:36] <dpm> jin_, oh, why do you want to remove the po files from bzr?
[08:36] <jin_> dpm: I just removed those .po files from only "bzr record"
[08:36] <jin_> no effects to the real *.po files we have in the branch/trunk
[08:37] <dpm> jin_, what's bzr record?
[08:37] <jin_> so that leave all *.po files updated by Launchpad itself
[08:37] <jin_> = bzr version control
[08:38] <jin_> since main trunk already tracked (means record these .po files in bzr)
[08:39] <jin_> so if we wanna untrack .po files, we can use this way to unmark them in bzr
[08:40] <robru> jin_: i don't think that's how it works... the mp looks pretty clearly like you are removing all .po from trunk.
[08:40] <dpm> yeah
[08:40] <dpm> jin_, what's the trunk branch you are talking about?
[08:40] <jin_> dpm: lp:telegram-app
[08:40] <jin_> this one
[08:41] <dpm> jin_, the way I read the MP, you're effectively a) ignoring all *.po files in bzr, then b) removing them from revision control and c) hoping that LP will regardless auto-commit translations there
[08:41] <robru> jin_: yea I don't know why you want to "untrack" .po files, we want those tracked so that launchpad can update them.
[08:41] <dpm> I'm not quite sure c) works
[08:41] <robru> dpm: even if c) worked it'd just undo what this branch is doing.
[08:41] <dpm> agreed
[08:42] <dpm> jin_, all that was needed was to revert the po file changes on that other branch that you guys were trying to merge
[08:42] <jin_> dpm: yeah.... I get it now..
[08:43] <dpm> or even then, you could actually merge the .po changes if you want to keep things easy, and LP will overwrite the .po files on the next translations auto-commit. But I think it'd make more sense to just leave the .po files alone alltogether
[08:43] <jin_> dmp: okay, thanks, so the only thing need to be added at the moment I think will be the .bzrignore
[08:43] <jin_> dmp: yes, yes
[08:43] <jin_> dpm: okay, I will modify the MP ;)
[08:44] <dpm> I'm not sure I'd do that either, as LP is using bzr and is not ignoring the .po files
[08:44] <jin_> (sorry for typo)
[08:44] <dpm> no worries
[08:44] <dpm> I mean LP auto-commits to the translations branch, using bzr
[08:44] <jin_> dpm: yeah I see what you mean
[08:45] <dpm> I think all I'd do would be to revert all .po file changes on that branch: https://code.launchpad.net/~libqtelegram-team/telegram-app/converged/+merge/286861
[08:45] <jin_> dpm: good idea, and that makes sense to me,
[08:46] <jin_> dpm: I will add a patch to the merge you mentioned
[08:46] <dpm> jin_, no worries: and actually, unrelated, but while we're on that subject...
[08:46] <jin_> dpm: thanks ;)
[08:46] <dpm> -#: /home/karni/src/telegram/telegram-app/v2/telegram/app/qml/components/DelegateUtils.qml:41
[08:46] <dpm> 2122	+#: /home/jin/Works/Applications/Telegram/converged/telegram/app/qml/components/DelegateUtils.qml:41
[08:47] <dpm> these are the changes that were made to the .po files ^^
[08:47] <dpm> I'd recommend not to hardcode your home directory paths there
[08:47] <dpm> and make the paths in the .po files relatives
[08:47] <jin_> dpm: make sense
[08:48] <dpm> that'd help you: a) keep privacy of your personal filesystem layout :) and b) not have to modify all files when a new developer comes along
[08:49] <jin_> dpm: okay, will do!
[08:49] <jin_> ;)
[08:49] <dpm> jin_, have a look at http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/po/CMakeLists.txt - that is how the core apps do it (clock, in this example)
[08:50] <jin_> dpm: hmmmm from #23
[08:51] <jin_> dpm: checking
[08:51] <dpm> jin_, I think it's rather in the first command, starting at L8
[08:52] <jin_> dpm: right.. good reference, Telegram will follow
[08:53] <dpm> I can't remember exactly which part takes care of it, perhaps L13 or L14. But I see telegram uses .pro files and qmake instead of CMakeLists.txt and cmake, so you will need to adapt to it. We used to have an example of doing this in qmake, but then we migrated to cmake.
[08:53] <dpm> but if it turns out not to be trivial, I can see if I can find that example
[08:54] <dpm> it should be in old revisions of the clock tree, or in any other core app's old history
[08:54] <alextu> hi~ there , I just created a ci-train request there, https://requests.ci-train.ubuntu.com/#/ticket/1108 , but can not see my ticket on trello : https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
[08:55] <alextu> I used to change the status to "read for QA", but it seems can not be set now .
[08:55] <jin_> dpm: sure! I will search that and look a look deeper (make Telegram adaptive on this way), will ask you to be the reviewer after done,
[08:55] <alextu> Does someone know how can I let my ticket present in trello list ?
[08:56] <alextu> davmor2, ^
[08:56] <jin_> dpm: at the moment I think I will drop the merge proposal I just mentioned, is that okay to you?
[08:56] <dpm> sure, thanks jin_!
[08:56] <dpm> yes to both :)
[08:56] <jin_> dpm: thanks mate! we will do that!
[08:56] <dpm> cook
[08:56] <jin_> dpm: nice! super
[08:56] <dpm> *cool :)
[09:23] <michi> robru: ping
[09:27] <robru> michi: Heya
[09:28] <michi> Hey. Why did you reject your MR?
[09:28] <michi> I suspect it will have merged already
[09:28] <Mirv> jibel: davmor2: lukasz is away, do you have any topics for the hangout?
[09:28] <jibel> Mirv, nothing from me
[09:29] <michi> robru: Yes, it has merged already.
[09:29] <michi> To remove it, we’ll have to do another MR with a reverse diff, or hack devel by hand.
[09:29] <robru> michi: oh you merged it already? I hadn't seen that. Didn't you see my comment about the extra commits?
[09:29] <michi> Currently, it is still the most recent revision, so it’s easy to revert
[09:30] <michi> Sure.
[09:30] <Mirv> jibel: davmor2: ok let's skip it then. I can't even complain about GPS anymore since it's working great now.. landings seem ~normal at the moment.
[09:30] <michi> That was just because you based it on trunk.
[09:30] <michi> We do all the work on devel and merge periodially in bulk to trunk.
[09:30] <michi> Via the silo
[09:30] <robru> michi: yeah but that means there were trunk commits not in devel
[09:30] <michi> So, rejecting this has done nothing.
[09:30] <michi> I don’t believe there were any.
[09:31] <michi> There shouldn’t be.
[09:31] <michi> Not normally
[09:31] <michi> pstolowski: ^
[09:31] <davmor2> Mirv: alextu might need a hand with his silo for the device tarball https://requests.ci-train.ubuntu.com/#/ticket/1108 he can't set it manually to qa ready
[09:31] <robru> michi: i know rejecting it doesn't revert it, i just didn't notice it had been merged already, had a stale tab open i didn't refresh
[09:31] <michi> pstolowski: This is the MR: https://code.launchpad.net/~robru/unity-scopes-api/vivid-tweaks/+merge/288865
[09:31] <michi> robru: No problem.
[09:31] <michi> So, I tested this yesterday and was happy with it, so I approved.
[09:32] <michi> If you are happy with it too, it’s all good.
[09:33] <robru> michi: yeah I'm happy with the work i did, i was just worried the extra commits would cause a problem. If there's no problem for you then it's fine i guess
[09:33] <michi> No, no problem. Can you top-approve again please?
[09:33] <michi> Otherwise, it’ll look weird later.
[09:34] <robru> michi: yep, done. Reviewed the diff, looks good, I'm not sure what those extra commits were but i don't see them in the diff
[09:34] <michi> Trunk was behind devel.
[09:34] <robru> michi: no trunk was ahead of devel
[09:35] <michi> So, when you rebased against devel, you probably didn’t do a pull first?
[09:35] <Mirv> davmor2: alextu: ok the 1108 is now set to Ready (for QA)
[09:35] <michi> robru: Not sure whether trunk was behind. Let me check...
[09:36] <robru> michi: i started with trunk, did my commits, then just merged devel
[09:36] <davmor2> Mirv: thanks dude
[09:36] <michi> Sorry, “ahead”, I meant.
[09:36] <robru> michi: so extra trunk commits were in my branch
[09:36] <michi> That’s trunk: 359: CI Train Bot 2016-02-09 {1.0.3+16.04.20160209-0ubuntu1} Releasing 1.0.3+16.04.20160209-0ubuntu1
[09:37] <michi> There were changes to devel since, but not the other way around.
[09:37] <michi> Maybe your devel was out of date or something?
[09:37] <robru> michi: the changelog of the silo is generated by running "bzr missing" against the branch before merging it, so the fact that names other than mine were in the changelog could only happen if there were commits on the branch not by me, and not in devel
[09:37] <michi> Anyway, when I tested and pulled your MR, it all looked good.
[09:37] <alextu> Mirv, thanks a lot, but I still can not see it on trello, so should I track it until it present on trello ? https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
[09:38] <michi> robru: I honestly have no idea what happened there.
[09:38] <robru> michi: OK well if it looked good to you i guess i won't worry too much, but the diff i made in the staging silo looked weird so I was worried
[09:38] <michi> But devel is where the action is for us, and devel is healthy.
[09:38] <michi> What I saw there were lots of changes we’d made to devel in the past few weeks.
[09:39] <robru> michi: OK great
[09:39] <michi> Like the logging changes, which was the bulk of the diff.
[09:39] <michi> No more boost::log, finally!
[09:39] <robru> Yay!
[09:43] <pstolowski> michi, robru is this critical for ota10?
[09:44] <michi> I don’t know. robru ?
[09:44] <Mirv> alextu: there's just a few minutes' delay there, it's now there already
[09:45] <pstolowski> i know it's not a feature etc. the question is if it's worth disrupting the existing big unity8/filters silo with it?
[09:45] <robru> pstolowski: michi nope nope, it doesn't affect anything at all, totally not noticeable change, just prepping for train changes that are still a month or more away
[09:45] <michi> pstolowski: No need to get it into the silo then.
[09:45] <robru> Yep
[09:47] <alextu> Mirv, cool! thanks for help
[09:48] <Mirv> no problem!
[09:49] <pstolowski> michi, robru ok, we will land it on the next occasion then
[09:52] <robru> pstolowski: yep, no rush, thanks
=== essembe is now known as sbeattie
[11:25] <morphis> Mirv: you know what is with sil2100 today?
[11:25] <Mirv> morphis: he's away, back tomorrow
[11:26] <morphis> Mirv: ah ok, can you publish https://requests.ci-train.ubuntu.com/#/ticket/1081 instead?
[11:27] <morphis> Mirv: or should I better wait for sil2100 to be back?
[11:28] <Mirv> morphis: looks ok, approved by QA, but what's up with those unresolved emulator dependencies mentioned by britney?
[11:30] <Mirv> I see there's no actual related packaging change, but just interested
[11:30] <morphis> Mirv: sil2100 said that is due to some missing things for britney, afaik he just published it last time for this landing
[11:32] <Mirv> morphis: ok, that's good enough for me. maybe something multi-arch related, the emulator is a bit special.
[11:33] <morphis> Mirv: good
[11:36] <Mirv> morphis: seems to be at correct places now, let's see if xenial release pocket migration is of any problem because of that same thing
[11:36] <morphis> Mirv: yeah
=== chihchun is now known as chihchun_afk
=== kyrofa_ is now known as kyrofa
=== alan_g is now known as alan_g|lunch
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== koza|away is now known as koza
=== alan_g|lunch is now known as alan_g
[14:11] <boiko> robru: could you please rebuild dialer-app on xenial ppc64el on silo 78?
[14:20] <rvr> renatu: ping
[14:23] <renatu> rvr, hi
[14:28] <rvr> renatu: Hey
[14:29] <rvr> renatu: I'm testing silo 22. I found a problem creating a yearly event.
[14:29] <rvr> renatu: It won't let me go back.
[14:29] <renatu> rvr, what do you mean?
[14:30] <rvr> renatu: In the Repeat screen, selecting the "Yearly" frequency, I can't go back to the Create event screen.
[14:30] <rvr> renatu: file:///opt/click.ubuntu.com/com.ubuntu.calendar/0.5.775/EventRepetition.qml:120: TypeError: Cannot call method 'getMonth' of null
[14:31] <rvr> Hmm... I can in the store version.
[14:31] <renatu> yeah this is a know bug it is fixed on a new branch
[14:32] <rvr> renatu: Does it only happens with version 0.5.775?
[14:32] <renatu> no its happen before
[14:34] <rvr> renatu: Ah, just tried with the version in the store and couldn't reproduce it
[14:36] <rvr> https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1438910
[14:36] <ubot5> Launchpad bug 1438910 in qtorganizer5-eds (Ubuntu) "unable to set event as yearly or monthly" [Undecided,In progress]
[14:39] <renatu> rvr, this is the branch to fix that: https://code.launchpad.net/~renatofilho/ubuntu-calendar-app/fix-edit-ocurrence
[14:39] <renatu> will be the next MR on the list
[14:40] <renatu> rvr, if you want I can merge it now and send a new package
[14:41] <renatu> rvr, but in any cases recurrence is buggy on the calendar app, and we are preparing a new set of MR to fix that
[14:42] <rvr> renatu: I was worried it was a regression introduced by the package in the silo, but as it is not, the fix can wait to another silo.
[14:43] <renatu> rvr, thanks
[14:48] <Mirv> ubuntu-qa: can you confirm that oxide silo https://requests.ci-train.ubuntu.com/#/ticket/1085 wouldn't need QA signoff?
[14:49] <davmor2> oxide would need qa sign off
[14:49] <rvr> Mirv: ??
[14:49] <rvr> Mirv: Of course it needs QA :)
[14:50] <Mirv> rvr: yes, that's why I pointed you to it
[14:50] <rvr> Mirv: It says "N/A" :-/
[14:50] <Mirv> rvr: so I'm taking dbarth meant it's ready for QA instead of "N/A", and putting into your queue
[14:50] <rvr> Mirv: Ahh, thanks
[14:51] <Mirv> except that it resets back to N/A :(
[14:51] <Mirv> weird
[14:51] <rvr> Mirv: That blue color, usually is set when the silo is ok to publish :-/
[14:52] <Mirv> rvr: yes, and that is true if QA wouldn't be needed ("N/A"), which is incorrect
[14:52] <jibel> Mirv, it's one a the feature we're waiting for this ota
[14:52] <Mirv> rvr: for now, I'm adding a DO NOT PUBLISH comment there
[14:52] <Mirv> jibel: can you put it into the queue manually since train is not accepting my commands?
[14:52] <rvr> Mirv: Great, thanks
[14:53] <rvr> I'll do
[14:53] <Mirv> robru: is there a particular reason why https://requests.ci-train.ubuntu.com/#/ticket/1085 does not allow changing "N/A" to Required or Ready? it keeps on resetting back.
[14:53] <jibel> interesting bug in bileto
[14:53] <Mirv> rvr: ok, thanks!
[14:53] <jibel> Mirv, forced to 'ready for qa'
[14:54] <Mirv> jibel: oh, why the train respects you more than me!
[14:54] <rvr> lol
[14:54] <davmor2> Mirv: we're in QA we have bigger hammers
[14:54] <Mirv> :(
[14:54] <jibel> Mirv, you didn't whisper the sweet words it expected
[14:54] <Mirv> meanwhile I'm recreating the diff since the silo was also not targeted to overlay
[14:55] <davmor2> Mirv: the secrets are "Work or I'll rip you hard drive out"
=== chihchun_afk is now known as chihchun
[15:06] <boiko> trainguards: can someone please rebuild dialer-app on xenial ppc64el on silo 78?
[15:18] <mzanetti> trainguards, the silo bumps unity8 version to 8.13 here even though no branch does that. We did have a branch in there which did it but it was removed.
[15:19] <mzanetti> could it be that it doesn't ever decrease the version again unless we'd clear the unity8 package out of the silo and do a clean build?
[15:57] <cjwatson> boiko: done
[16:14] <Mirv> boiko: seems done now
[16:14] <Mirv> mzanetti: yes it's possible it works like that.
[16:15] <Mirv> mzanetti: but we could try deleting both the superseded and current package and then try again in 30mins or so
[16:16] <Mirv> mzanetti: since you apparently don't want 8.13 anyway, I'm trying that
[16:16] <mzanetti> Mirv, let me just ask back with the team... might be they rely on the 8.13 fact already. will let you know in a bit
[16:16] <Mirv> mzanetti: oh, ok
[16:21] <popey> davmor2: have you seen any notifications on latest rc-proposed? on my krillin I'm seeing grey on grey, unreadable notifications
[16:21] <popey> didn't get a screenshot in time
[16:21] <kenvandine> popey, i'm seeing the same thing on arale
[16:21] <davmor2> popey: there is a bug in unity8 for it
[16:21] <popey> thanks kenvandine
[16:21] <popey> ok
[16:21] <jibel> popey, it's a known bug
[16:21] <popey> \o/
[16:21]  * popey goes back to sleep
[16:22] <jibel> popey, bug 1554616
[16:22] <ubot5> bug 1554616 in unity8 (Ubuntu) "Shell and dash visual issues with new UITK and palette" [Critical,In progress] https://launchpad.net/bugs/1554616
[16:22] <jibel> popey, if you find anything unity8 related not in the list please add it
[16:22] <popey> kk
[16:23] <popey> comment 17 covers my issue
=== tyhicks` is now known as tyhicks
[16:36] <boiko> cjwatson: Mirv: thanks
=== koza is now known as koza|away
=== pstolowski is now known as pstolowski|bbl
[17:30] <rvr> renatu: ping
[17:34] <renatu> rvr, hi
[17:35] <rvr> renatu: Something weird happened with a reminder (-5 minutes). It wasn't triggered. But then I re-edited the event, and cannot reproduce.
[17:35] <rvr> renatu: Anyway, there is this test case "Change the guests by adding and removing (swipe right)"
[17:36] <rvr> renatu: I cannot swipe right an event, because the calendar view moves.
[17:37] <renatu> let me check the test plan, you should not swipe right the event. I think the test plans want you to swipe right the guest
[17:37] <rvr> renatu: You may be right
[17:37] <rvr> renatu: Event modification "Change the guests by adding and removing (swipe right), save the event, re-open and make sure the changes were properly saved"
[17:38] <renatu> rvr, yes, open the event editor and swipe right a guest, save it and open again to check if the changes was commit
[17:38] <rvr> renatu:  Right.
[17:38] <rvr> Done
[17:39] <rvr> renatu: Final question. Will this calendar app version be published on the store?
[17:39] <renatu> rvr, no. it will be land on OTA 10
[17:39] <renatu> rvr, but still some fixes to land
[17:39] <rvr> renatu: Ah, cool
[17:40] <rvr> renatu: I'm approving the silo, then
[17:40] <renatu> rvr, thanks man[
[17:41] <renatu> rvr, sorry for the confusion with test plan It was wrote a log time ago. I started to work on calendar app some weeks ago
[17:41] <rvr> renatu: np :)
[17:44] <robru> mzanetti: yes, PPAs will never accept an upload with a lower version than what was in there before, so the train always picks the highest possible version when generating version numbers. If you want to go back down, you need to abandon & reassign to get a fresh ppa
[17:44] <mzanetti> I don't think it's that critical. we'd want to bump it anyways, and as this silo is already a FFE I don't feel like it's worth delaying it any further for skipping one version number tbh
[17:45] <mzanetti> but thanks for explaining, yes
[17:51] <robru> Mirv: bileto enforces na/required/ready states based on series & dest, so it wouldn't let you because it wasn't targeting overlay i think, the trick is that there's an exception for tickets with manual download URLs set, so jibel set "http://" there and then you can set any qa status
[17:51] <robru> Mirv: sooner or later I'll need to fix up the qa field to behave more predictably but I've just had other priorities, sorry
[17:52] <mzanetti> robru, fwiw, Mirv dropped just the unity8 package from the silo, I've rebuilt it now and it seems to be back to 8.12 (as opposed to the wrong 8.13 from before)
[17:52] <mzanetti> so seems a complete silo clean is not required
[17:53] <robru> mzanetti: oh interesting, thanks, i was under the impression that PPAs always remembered the versions even if you deleted the packages
[17:53] <mzanetti> robru, doesn't a "clear silo" just delete all the pacakges from a ppa too?
[17:54] <mzanetti> apart from the other train magic, but from a ppa point of view it seems to be just like deleting all the packages
[17:54] <robru> mzanetti: yes, but then when you re assign, you get a different one
[17:54] <robru> mzanetti: they're assigned in random order
[17:54] <mzanetti> robru, well, but if that wouldn't be enough, we would frequently get silos with wrogn versions because someone tested something in that silo before
[17:55] <robru> mzanetti: oh do you guys bump the version number a lot? I assumed that was rare
[17:55] <mzanetti> not *a lot* but well... whenever we change something in unity-api
[17:55] <robru> Fair enough
[17:55] <mzanetti> which does happen every 1.5 landings I'd say
=== jhodapp is now known as jhodapp|errand
=== joc_ is now known as joc|away
=== pstolowski|bbl is now known as pstolowski
=== jhodapp|errand is now known as jhodapp
=== boiko_ is now known as boiko