[06:41] <bkerensa> hello gepr
[06:41] <bkerensa> :D
[20:47] <c_smith> bkerensa, are you available to show me what is to be done with the Ubuntu Dev News?
[21:13] <bkerensa> Surely
[21:13] <bkerensa> c_smith: PM me
[21:14] <c_smith> bkerensa, on IRC, right?
[23:59]  * kees waves "hi" to wolfmanjake


[05:06] <Mirv> morning, train
[12:17] <Mirv> would there be a core-dev available for acking bumping of version dep plus adding of symbols https://ci-train.ubuntu.com/job/ubuntu-landing-054-2-publish/10/artifact/libqtdbusmock_packaging_changes.diff ? publish job to run with packaging ACK selected at https://ci-train.ubuntu.com/job/ubuntu-landing-054-2-publish/ - a dual silo going into the overlay PPA
[13:20] <jdstrand> pmcgowan, bfiller: hi! I noticed over the weekend I updated my rc-proposed mako and the calendar alarm sound changed to something very shrill. I don't see how to change it either. was this intended? is it known?
[13:21] <pmcgowan> jdstrand, yes known and being corrected
[13:21] <jdstrand> I had to disable all the calendars in the app to get it to stop
[13:21] <pmcgowan> unfortunate side effect of a new alarm sound
[13:21] <jdstrand> ok, thanks
[13:21] <pmcgowan> jdstrand, I was running around my house trying to find out what it was
[13:21] <jdstrand> hehe
[13:21] <pmcgowan> seb128, thought it was a fire alarm
[13:21] <bfiller> jdstrand: yeah, it's known
[13:22] <jdstrand> it is a pretty in your face alarm :)
[13:22] <pmcgowan> we will have a second sound for alerts
[13:22] <seb128> pmcgowan, are we going to fix it before rolling ota7 out?
[13:22] <pmcgowan> charles, we should patch that soon as we can
[13:23] <pmcgowan> seb128, I think its worth a hotfix
[13:23] <pmcgowan> jibel, ^
[13:23] <pmcgowan> maybe if we need to crack the image for something
[13:28] <jhodapp> Mirv, I need to double check with you that the qtmultimedia and -gles packages are looking good for landing from silo 55 - just with respect to the special handling -gles needs
[13:30] <jibel> pmcgowan, when will we have the second sound? cannot it land in this ota?
[13:31] <pmcgowan> jibel, we picked one the other day alecu or charles will know
[13:31] <pmcgowan> let me find that bug
[13:31] <Mirv> jhodapp: the -gles build lacks https://launchpadlibrarian.net/220435995/qtmultimedia-opensource-src_5.4.1-1ubuntu12_5.4.1-1ubuntu13.diff.gz
[13:31] <Mirv> ie your latest changes to non-gles
[13:32] <jhodapp> Mirv, so I'm not sure what to do, I only knew there was something special to do for -gles. And then there is the -gles handling that robru was working on for the ci-train
[13:33] <Mirv> jhodapp: I can upload a newer one. the -gles just needs the changes always copied. robru is working for -gles improvement regarding qtmir/qtubuntu/ubuntu-ui-toolkit, these Qt packages are manual.
[13:34] <jhodapp> Mirv, ah ok, I thought it applied to every package with a -gles
[13:35] <jhodapp> Mirv, thanks for doing that. Just so I have an idea of what you're doing, are you simply branching a -gles branch of qtmultimedia and bringing in the same patch and updating the debian changelog?
[13:35] <Mirv> jhodapp: no, the Qt ones need actual changes to be kept so they can't use the exact same source / packaging as our components
[13:35] <alecu> jibel: pmcgowan: I'll make sure we work on changing the calendar sound ASAP. btw, I cannot find that bug, it should be here, right? https://bugs.launchpad.net/ubuntu/+source/indicator-datetime
[13:35] <pmcgowan> alecu, I am filing one, must have forgotten to
[13:35] <Mirv> jhodapp: yes, in essence that's the only thing I do. its packaging is a fork, but mostly one just syncs over whatever changed in debian/.
[13:36] <alecu> pmcgowan: thanks
[13:36] <pmcgowan> https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1505688
[13:36] <ubot5`> Ubuntu bug 1505688 in indicator-datetime (Ubuntu) "Alerts like for calendar events should use a default sound different from alarms" [Critical,Confirmed]
[13:36] <pmcgowan> alecu, ^^
[13:36] <Mirv> jhodapp: so now I'm just applying the diff I linked to on top of the ubuntu12 -gles package I already had locally
[13:36] <jhodapp> Mirv, is there a specific -gles branch that's different from the straight qtmultimedia package?
[13:37] <jibel> alecu, pmcgowan it should probably land in this OTA, there'll be a respin for apport anyway.
[13:38] <alecu> jibel: ack
[13:38] <Mirv> jhodapp: no, no code branch, just what lives in archive. what I do myself is I dget the latest source and use it locally with bzr tools. it's easier that way (to me at least) than having 6 different repos of the various versions (5.5.0, 5.4.2, 5.4.1 and the -gles variants of those)
[13:38] <Mirv> ...for each of the modules
[13:39] <jhodapp> Mirv, ah ok
[13:39] <jhodapp> Mirv, btw, this latest change is just about upstream to Qt
[13:39] <jhodapp> Mirv, so they'll have all of our code that we did for background playlists
[13:40] <Mirv> jhodapp: ok the ubuntu13 -gles is now building in the PPA. and, excellent!
[13:41] <jhodapp> Mirv, awesome thanks
[13:41] <Mirv> jhodapp: you may have noted that I ported qtubuntu-media and qtubuntu-camera to the new audio role API, the MP:s would use review at some point to be able to ship them with Qt 5.5.
[13:42] <jhodapp> Mirv, I did see that...I'll review those later today
[13:42] <Mirv> thanks
[13:44] <Mirv> jhodapp: oh, and qtvideo-node to the new 5.5's qsgvideonode to fix video playback
[13:44] <jhodapp> Mirv, ok, so qtubuntu-media, qtubuntu-camera and qtvideo-node
[13:44] <Mirv> jhodapp: right
[13:44] <jhodapp> got it, thanks
[13:45] <pmcgowan> jibel, good news bad news
[13:48] <jibel> pmcgowan, I cannot bear the suspense, don't keep me waiting :)
[13:48] <jibel> what are the bad and good news?
[13:49] <pmcgowan> jibel, you said it, bad news is we are respinning, good news we can fix that crazy alert sound
[13:49] <jibel> pmcgowan, ah I thought there were more
[13:58] <charles> pmcgowan, on it now, I'll use the sound that mpt chose when we discussed this with him
[14:00] <pmcgowan> charles, ack, added to the bug
[14:00] <charles> Marimbach for calendar and reminder, the screeching alarm clock for clock alarms...
[14:00] <charles> pmcgowan, thanks
[14:02] <sil2100> pmcgowan: we will fix the crazy alert sound for OTA-7? ;)
[14:02] <pmcgowan> sil2100, yes
[14:02] <pmcgowan> since we need apport fixed anyway
[14:02] <pmcgowan> had to turn my mako off
[14:03] <sil2100> Yeah, I know, but good we'll fix the alert thing as well
[14:03] <sil2100> Just tell me what to copy to the snapshot and I'll spin an image
[14:04] <sil2100> (still waiting for the apport fix tho)
[14:52] <pete-woods> trainguards: hey guys. are any of you folks also core-devs? (https://requests.ci-train.ubuntu.com/#/ticket/498) (https://ci-train.ubuntu.com/job/ubuntu-landing-054-2-publish/10/artifact/libqtdbusmock_packaging_changes.diff)
[14:52] <pete-woods> was kinda hoping on a packaging ack
[14:53] <jhodapp> jibel, just to clarify, do you plan to go over silo 55 again or are you satisfied that the merge xavigarcia did is minor enough to not need another round of testing?
[14:53] <pete-woods> I don't seem to have an effective technique for luring core-devs into my web of review yet
[14:55] <jibel> jhodapp, we plan to go over it again, then change xavi added was not in the silo when with verified it
[14:56] <jhodapp> jibel, ok great, that's what I thought...thanks
[15:05] <sil2100> pete-woods: sadly we're not yet core-devs, but I'm trying hard now to become one :)
[15:19] <pete-woods> sil2100: good to know :)
[15:49] <jgdx> are silos to be dual these days? Or vivid+overlay (which is the main target)?
[15:52] <jgdx> trainguards: ^ halp
[15:56] <sil2100> jgdx: yeah, you can dual land and both vivid and wily landings go to the overlay then :)
[16:10] <popey> cihelp: Hi, who is dealing with https://bugs.launchpad.net/qa-dashboard bugs? I just filed https://bugs.launchpad.net/qa-dashboard/+bug/1505736
[16:10] <ubot5`> Ubuntu bug 1505736 in Ubuntu CI Dashboard "All the stats are out of date / not working" [Undecided,New]
[16:13] <ev> ^ Ursinha interesting data point
[16:14]  * Ursinha reads
[16:21] <fginther> popey, that's most likely a question for ev and Ursinha. As Colin commented, most of the tests on the dashboard are no longer being executed.
[16:40] <jgdx> sil2100, great, thanks :)
[17:36] <oSoMoN> ubuntu-qa: silo 14 should be ready for QA validation
[17:37] <charles> trainguards, can ubuntu/landing-046 be landed?
[17:38] <charles> it should be easier to dual land the calendar event sound change after ubuntu/landing-046 straightens out the indicator 15.10 branch version...
[17:50] <robru> charles: I don't have publish power anymore, you need to find s core dev
[17:50] <dobey> oh a coredev has to do that?
[17:51] <dobey> hmm
[17:51] <robru> dobey: well or motu depending. Whoever has upload rights
[17:52] <dobey> oh, oops :)
[17:53] <robru> dobey: thanks
[17:54] <dobey> thanks?
[17:56] <dobey> oh, so it's in UNAPPROVED queue now
[17:56] <dobey> neat
[17:56] <dobey> i guess a coredev has to approve it though
[17:56] <charles> yeah
[17:56] <pat__> 0 ERROR This error was not anticipated by robru. You should definitely let him know immediately.
[17:58] <robru> pmcgowan: what were you doing that got that?
[17:59] <pmcgowan> robru, the train page was open in the browser
[17:59] <pmcgowan> thats it afaik
[17:59] <robru> pmcgowan: does it fix itself if you reload?
[17:59] <pmcgowan> refresh fixes it
[18:00] <robru> pmcgowan: the 0 should be an http error code, that's quite strange
[18:00] <pmcgowan> maybe flaky net connection
[18:00] <robru> pmcgowan: could be. Thanks for letting me know
[18:02] <robru> charles: are you sure you need that in wily and not just in overlay ppa? You can skip unapproved queue if you publish instead to wily+overlay
[18:04] <robru> charles: actually reading the description is this landing even needed at all? You can just bump the version number in trunk, you don't need to make a release to do that. Then next landing will pick up the change automatically
[18:05] <charles> robru, I'm open to ideas on the best way to do it. here's the thing:
[18:06] <charles> robru, the next thing in datetime is to fix the bug pmcgowan reported about changing the default calendar sound. And that issue is everywhere so it seems dual would make sense for that
[18:07] <charles> robru, so I wanted to do this first, imagining that chaos would reign if I try a dual landing where 15.04's version > 15.10's version
[18:07] <charles> robru, but in the end what's needed is (a) landing the sound fix and (b) fixing 15.10's version, so if there's an easier path to that, wonderful
[18:08] <robru> charles: but you can just bump the version when you do the dual landing? There's no rule that says dual landings have to use whatever version
[18:08] <robru> charles: https://ci-train.ubuntu.com/job/ubuntu-landing-046-2-publish/22/artifact/indicator-datetime_content.diff look at your diff for this silo
[18:09] <robru> Is that what you intended to do? Looks like the sound change is in there
[18:09] <charles> robru, no that's not intended. :P
[18:11] <robru> charles: I think you should abort this landing, merge the MP to trunk manually, then start over with a dual silo
[18:11] <charles> robru, so you're suggesting I drop 046 (which would need fixing anyway as per above) and manually bump the version in the debian/changelog in the dual landing?
[18:11] <dobey> weird
[18:11] <dobey> dual landing?
[18:12] <robru> charles: yeah that would work too, just make sure you use UNRELEASED instead of wily in your changelog
[18:12] <dobey> i thought datetime can't do dual landing because of evolution
[18:12] <robru> I dunno about that
[18:13] <dobey> where the heck did it pull that sound change from?
[18:14] <robru> dobey: must be in trunk already
[18:15] <charles> it is in trunk already. That was how the shear got started; last week I clicked the wrong button and landed the initial change in W only
[18:15] <dobey> oh
[18:15] <robru> dobey: it's here: https://code.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.15.10
[18:15] <dobey> it got landed in the overlay ppa for wily, rather than in wily itself
[18:15] <robru> charles: you mean in vivid only
[18:15] <robru> ?
[18:16] <dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5481874/+listing-archive-extra
[18:16] <dobey> it went to the wrong place
[18:16] <fginther> greyback__, Have you been able to make any progress on the dbus test issue with qtmir?
[18:16] <dobey> hmm
[18:17] <robru> dobey: charles do you know for sure that you need this change in wily proper? Because the policy is for dual silos to go entirely into overlay during wily freeze
[18:18] <pmcgowan> sil2100, did you upload the change for the new framework?
[18:18] <dobey> i have no idea about "need" but i know datetime can't do "dual" landing because the e-d-s API is different in wily and vivid
[18:18] <charles> robru, I think overlay would work for this.
[18:19] <robru> dobey: charles: like, if your goal is "get this to customers" you don't need to land it in wily, just wily overlay.
[18:19] <dobey> robru: well, really the goal with this specific branch is "get it in trunk" so i don't think we care too much about archive vs overlay
[18:19] <charles> right, it may need to be two separate branches due to EDS but both can go in overlay IMO
[18:20] <dobey> so what, just change the silo to be overlay, then rebuild, retest, and then publish?
[18:20] <robru> charles: so if this change is already in wily overlay then it should all be fine, just merge the version bump to trunk without a silo
[18:20] <dobey> the version bump isn't in the overlay
[18:20] <dobey> the sound change is
[18:20] <robru> dobey: just abandon the silo because there's nothing to test, it's done already
[18:20] <charles> silo is already abandoned
[18:21] <robru> dobey: the version bump isn't worth doinga release for, it can just be in trunk for next time
[18:21] <robru> charles: thanks
[18:26] <greyback__> fginther: with a new MP, it solved itself. Have no idea why tbh
[18:50] <fginther> greyback_, ack
[19:01] <Saviq> robru, something weird happened with https://requests.ci-train.ubuntu.com/#/ticket/445
[19:02] <Saviq> robru, ERROR qtmir 0.4.6+15.10.20150930.1-0ubuntu1 not found in Silo PPA, when 0.4.6+15.10.20151013-0ubuntu1 is happily built
[19:02] <Saviq> no idea where it took the 0930.1 version
[19:02] <robru> Saviq: hm lemme look
[19:02] <Saviq> +from
[19:05] <robru> Saviq: that version is the latest version at the top of your qtmir debian/changelog: https://ci-train.ubuntu.com/job/cyphermox-test/1185/console
[19:06] <Saviq> robru, well, shouldn't train rewrite it?
[19:06] <robru> Saviq: yes it should, that's quite strange
[19:06] <robru> Saviq: especially considering a different version got uploaded
[19:06] <Saviq> robru, a clue might be that the previous build job was a conflicted qtmir attempt
[19:07] <Saviq> robru, so the qtmir that is there in the silo was built earlier today
[19:07] <Saviq> robru, then I tried to build qtmir and qtubuntu, that failed due to a conflict in qtmir, then I built qtubuntu alone and that's what failed with the missing qtmir version
[19:08] <robru> Saviq: yes, when you try to rebuild something, the first thing the train does is deletes whatever local state it has
[19:08] <robru> Saviq: so you'll need to rebuilt qtmir then
[19:10] <robru> Saviq: https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/189/consoleFull yep, this woulda done it. you turfed the local files that correspond to the package that's in the silo.
[19:11] <Saviq> robru, ack, so what changed recently is the auto-filled source package names
[19:12] <Saviq> robru, so any build job would look for those, not only those listed in the packages to build?
[19:12] <Saviq> and since the previous qtmir build failed, this happened
[19:13] <Saviq> robru, wanna hear a feature request?
[19:14] <robru> Saviq: yeah, a few weeks ago I changed the build job so that the "watch" phase (where it polls the PPA for build status) watches all packages regardless of what you put in PACKAGES_TO_REBUILD. This was done on purpose precisely because of situations like this, because there were cases where a package was busted but some other package was built, so the silo
[19:14] <robru> said "packages built" and people tried to publish this in a bad state.
[19:14] <robru> Saviq: sure
[19:15] <Saviq> robru, right, only problem then is the error is somewhat confusing
[19:16] <robru> Saviq: yeah, I'm not sure how that could be any different. you'll need to just know that the error doesn't reference the packages you wanted to build, then those packages built ok.
[19:16] <Saviq> robru, it'd be nice to have requests depending on other requests, so that code is the topmost one is built on top of code from the lower ones, PPAs are added as dependencies in the topmost silo etc.
[19:16] <robru> Saviq: wat
[19:17] <Saviq> robru, so, situation we have today: qtmir and unity8 are ready for qa in two separate silos
[19:17] <Saviq> robru, and we have another request with both qtmir and unity8 that's gonna land after those
[19:18] <Saviq> robru, I'd love to be able to have my "big" silo to be based on top of the other two
[19:18] <robru> Saviq: the fact that you have two separate silos ready for QA at the same time is horrible, one will be invalidated and require rebuild as soon as the other lands
[19:18] <Saviq> robru, I don't
[19:18] <robru> Saviq: well you can already do that by including all the same MPs
[19:18] <Saviq> robru, there's no conflict between QA-ready silos
[19:19] <Saviq> robru, but I have one more that still needs testing ont op of those QA-ready ones
[19:19] <Saviq> *on top
[19:19] <robru> Saviq: oh you mean you have one silo for qtmir that's ready and one for unity8 that's ready? it sounded like you said "two silos each with unity8 and qtmir that are ready"
[19:19] <Saviq> robru, the former
[19:19] <robru> ok
[19:19] <Saviq> robru, on top of those two, I have one with unity8 and qtmir
[19:19] <Saviq> robru, but that's in-progress
[19:20] <Saviq> robru, because it's waiting for the other two
[19:20] <Saviq> if I could say in my request that requests foo and bar are prerequisites to this last request
[19:20] <robru> Saviq: for now the best you can do is duplicate all the MPs in the next silo.
[19:20] <robru> Saviq: that's a really huge undertaking to implement something like that, I don't think it's going to happen
[19:20] <Saviq> robru, remember when I said it's a feature request? :)
[19:21] <Saviq> and you did want to hear it :D
[19:21] <robru> Saviq: I thought you would suggest a better wording for the error message or something :-P
[19:21] <Saviq> robru, basically, what's happening is that everyone and their mother is releasing unity8 these days ;P
[19:21] <robru> Saviq: tell them to stop it :-P
[19:21] <Saviq> and conflicts are awfully quiet these days
[19:21] <robru> or coordinate better into bigger silos
[19:22] <Saviq> robru, well, I could do that, but QA generally likes smaller silos better
[19:23] <robru> Saviq: train is really not designed to manage tons of conflicts, it's much better if one person makes one silo that includes a number of changes.
[19:24] <Saviq> robru, I'm not saying it's easy, but there's really only two things that would need to happen unless I'm missing something big - take branches from prerequisite silos instead of trunks and add PPA dependencies (well, and update the citrain tool, but that's not really working well today anyway)
[19:24] <robru> Saviq: and QA is confused, they should want to test one silo once rather than 8 silos that all have the same package in it
[19:24] <robru> Saviq: what's wrong with citrain tool?
[19:25] <Saviq> robru, it upgrades all packages from overlay
[19:25] <robru> oh right
[19:25] <Saviq> robru, and it doesn't allow installing deps from archive
[19:25] <Saviq> robru, I somewhat agree (re: QA confusion), but then a failure is obviously more difficult to pinpoint
[19:25] <robru> Saviq: how do you have deps in archive that aren't already in the image?
[19:26] <Saviq> robru, new ones
[19:26] <Saviq> robru, if you introduce a new dep, it's not gonna get pulled in from archive (it will from overlay today, but that's... the bug above)
[19:26] <Saviq> that is, if it's there in overlay
[19:26] <robru> Saviq: when I originally wrote citrain tool, the goal was to prevent updates from coming in from the archive entirely. that was a design goal
[19:27] <Saviq> robru, sure, updates, but if deps are broken otherwise... that should be allowed
[19:27] <robru> qa specifically requested the archive not be included
[19:27] <robru> Saviq: well you'll have to manually install the dep before using citrain tool I guess
[19:27] <Saviq> robru, yeah, but that leaves the device broken, because ubuntu-touch often gets removed if you don't pay attention
[19:28] <Saviq> robru, bug #1378245 mentions a way to eat the cake and have it too, at least it worked for me before overlay
[19:28] <ubot5`> bug 1378245 in phablet-tools (Ubuntu) "citrain could use a more accurate way to upgrade from silos" [High,In progress] https://launchpad.net/bugs/1378245
[19:29] <Saviq> robru, basically, when I have to tell everyone who wants to test to do this, that, and that, that feels like the process is broken
[19:29] <Saviq> sure I could put it in the description, but who reads that ;P
[19:34] <Saviq> robru, in any case, feature request provided, ETA? >:]
[19:35] <robru> Saviq: that'll happen after we get ephemeral PPAs, and after bileto absorbs all of jenkins into itself.
[19:35] <robru> Saviq: basically, 3-5 years
[19:36] <Saviq> robru, /me puts a calendar reminder in
[19:36] <Saviq> nice goals BTW!
[19:36] <robru> Saviq: yeah those ones are actually doable :-P
[19:38] <robru> Saviq: also higher priority: making train builds atomic so if you break a rebuild it doesn't throw away the previous good state.
[19:48] <Saviq> robru, ;)
[20:11] <jibel> charles, any news on the fire alarm fix?
[20:12] <charles> jibel, yes, should be in silo in ~15m
[20:12] <jibel> charles, good, thanks
[20:34] <bfiller> sil2100, jibel: do you know why rc-proposed images are still using the stable-snapshot ppa? shouldn't they be using the overaly-ppa again?
[20:48] <charles> hmm. working on phone, working on laptop, failing in jenkins...
[20:49] <charles> late changes are always a joy
[20:51] <charles> ah
[22:06] <robru> Saviq: do you have an active silo currently that is affected by https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1378245 ? can you give me detailed logs of what you need to happen vs. what is actually happening?
[22:06] <ubot5`> Ubuntu bug 1378245 in phablet-tools (Ubuntu) "citrain could use a more accurate way to upgrade from silos" [High,Confirmed]