=== jamesh_ is now known as jamesh
=== robru is now known as robru__
=== robru_ is now known as robru
[03:50] <robru> ugh
[03:52] <robru> jamesh: I'm here, let me dig into this
[03:53] <jamesh> robru: if it helps, the previous build in the silo I hadn't added anything to debian/changelog
[03:53] <jamesh> with this rebuild, I did (I had added some API, so wanted to bump the version number)
[03:53] <robru> jamesh: I made some train changes recently that probably broke it, just investigating
=== chihchun_afk is now known as chihchun
[03:55] <jamesh> it looks like it has uploaded the Xenial source package to the silo, but not the Vivid one
[03:56] <robru> jamesh: yeah the vivid half of dual silos is being a bit weird the last couple days
[03:56] <robru> jamesh: it also didn't build anything for vivid
[03:59] <jamesh> robru: thanks for looking into this so quickly
[03:59] <robru> jamesh: you're welcome!
[04:00] <robru> jamesh: huh well that's strange, I just retried it with debug logging on and it looks like it's working now (it didn't create the vivid copy before but it did now... let's see if it builds)
[04:10] <robru> jamesh: huh well it totally worked.
[04:18] <jamesh> yep.  Looks like each package has successfully finished building on some architectures.
[06:11] <robru> please ping me if anything explodes, i should be around for a few more hours
[07:03] <robru> tvoss: you don't need to assign after changing mps anymore
[07:03] <tvoss> robru, ah, cool
=== michihenning is now known as michi
=== davmor2_ is now known as davmor2
=== karni is now known as karni-brb
[09:36] <popey> davmor2, setting that task to qa failed and will leave it for a bit, and then flip it back a bit later
=== karni-brb is now known as karni
[09:57] <robru> tvoss: sorry about that, train bug. trying again: https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/76/console
[09:57] <robru> Mirv: sil2100 ^^ hmm it's happening again
[09:58] <robru> second try seems to work. very strange
[10:05] <Mirv> hmm
[10:07] <morphis> sil2100, Mirv, robru: any time to merge https://requests.ci-train.ubuntu.com/#/ticket/522 ?
[10:08] <robru> morphis: needs a core dev to publish
[10:08] <morphis> ah, right
[10:08] <morphis> let me ping one
[10:11] <morphis> robru: btw. if I get upload rights for a single package to the archive can I then upload to a silo for that package too?
[10:16] <robru> morphis: eh, no, only ci-train-ppa-service (aka trainguards) and core dev can upload to silos.
[10:17] <morphis> ok
[10:17] <robru> morphis: "upload to silos" is unfortunately a feature of launchpad rather than a feature of the train so not much I can do about that
[10:17] <morphis> robru: before I file a bug about that, basically I had a active discussion with cyphermox about this on friday
[10:18] <morphis> the outcome was: is it possible that we do MP based landings with citrain/silos which doesn't touch the changelog but take it as it is in the MP?
[10:18] <robru> morphis: if you write your own debian/changelog the train will not touch it
[10:19] <morphis> robru: ah, so that already works, interesting
[10:19] <morphis> robru: it will also not modify the version number?
[10:19] <robru> morphis: or at least that was once the case, it's possible that regressed, I don't think that bit of code is well tested.
[10:19] <robru> morphis: no it will always mangle the version number even if you write your own changelog entry.
[10:19] <robru> morphis: there's a different way to stop it mangling the version number
[10:20] <morphis> which one?
=== marcustomlinson is now known as marcustomlinson|
=== marcustomlinson| is now known as marcustomlinson
[10:20] <sil2100> There was a flag in debian/control in the past that made the train not mangle the version
[10:20] <sil2100> robru: is it still supported?
[10:21] <robru> morphis: in debian/control you have to do 'X-Auto-Uploader: no-rewrite-version'
[10:21] <robru> morphis: but I don't really recommend using that, it's more hassle than it's worth. if you let the train generate the number you can rebuild more easily. using that means you have to push a new commit for every rebuild you want to do
[10:21] <sil2100> Ok, so it's still supported, yey
[10:22] <morphis> robru: the background for this is that I really would like to do MP based landings for bluez
[10:22] <morphis> but cyphermox (and other core devs) don't want the mangled version numbers in the archvie
[10:22] <morphis> which makes sense
[10:22] <robru> morphis: MPs typically only work for projects that we are the upstream for.
[10:22] <morphis> as bluez isn't our upstream
[10:23] <morphis> robru: I know, but what if we take the idea a bit further as this is really something which improves our quality and makes reviewing a lot easier
[10:23] <robru> morphis: "a bit further"? what else do you need? train does support not mangling the version
[10:24] <morphis> robru: yes, I just meant taking it a bit further than only using it to land canonical upstream through MPs
[10:24] <robru> morphis: to do an MP based merge you need to have the packaging inlined in the branch
[10:24] <robru> morphis: could be a bit tricky as currently some security-sensitive code makes the assumption that MPs=canonical so that would need to be tweaked if we started doing MPs for third party stuff
[10:25] <morphis> robru: generally landing through MPs for bluez works fine
[10:25] <robru> morphis: also train is really sensitive to the packaging being just so, easy when we're upstream, harder for rando packages
[10:25] <morphis> we did the last landing this way
[10:25] <morphis> robru: I wouldn't recommend this for all packages or the general way of doing landings
[10:26] <robru> morphis: right well I'm open to it, feel free to file a bug if you have specific problems
[10:26] <morphis> in my particular case I want a quality process which enables us to do dual-landings for bluez where all sides (desktop, touch, ..) can comment/review the landing and say yes or no
[10:26] <morphis> robru: let me try the field in debian/control
[10:29] <robru> morphis: yeah MPs are obviously way more transparent than manual source uploads.
[10:29] <morphis> robru: exactly
[10:37] <robru> alright, nearing 3AM, night folks ;-)
=== vrruiz_ is now known as rvr
[10:56] <tvoss> robru, sil2100 mind having a look here: https://launchpadlibrarian.net/227352402/buildlog_ubuntu-xenial-ppc64el.trust-store_2.0.0%2B16.04.20151123.1-0ubuntu1_BUILDING.txt.gz
[10:56] <tvoss> ?
[10:56] <sil2100> tvoss: looking
[10:58] <sil2100> tvoss: hmm... looks like some issue with mesa-common-dev in ppc64el
[10:58] <tvoss> sil2100, yup
[10:59] <sil2100> dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt
[10:59] <sil2100> WTH
[10:59] <sil2100> Let me check if it's corrupt here as well
[11:01] <sil2100> tvoss: archive looks fine here, let's try re-building, maybe it was just some random corruption on the machine
[11:01] <sil2100> tvoss: where was that build from?
[11:01] <tvoss> sil2100, silo 21
[11:01] <tvoss> sil2100, kicked rebuild
[11:02] <sil2100> I see it built successfully, as I see no failure now
=== _salem is now known as salem_
[11:53] <morphis> robru: seems like that worked perfectly: https://ci-train.ubuntu.com/job/ubuntu-landing-054-1-build/37/console
[11:58] <sil2100> jhodapp: hey! I just checked the seeds and from what I see no seed changes will be needed for the new media-hub
[11:59] <sil2100> jhodapp: the seeds only depend on the media-hub package which pulls in the other deps, so it should simply pull in the new 4 libaries by default after publishing since the deps have been modified
[12:19] <boiko> rvr: hi, need any help with silo 25 testing? or is it under control?
[12:21] <rvr> boiko: Currently under control. If I have any doubt, I'll ping you, thanks :)
[12:21] <boiko> rvr: cool, thanks :)
[12:23] <popey> jibel, my music-app card is still in trello under 'failed' - can it be moved pls?
[12:23] <popey> I worry nobody will look at it again
=== karni is now known as karni-lunch
[12:24] <popey> oooh! it's in both!
=== karni-lunch is now known as karni
[12:24] <popey> jibel, /ignore popey
[12:26]  * sil2100 lunch
=== chihchun is now known as chihchun_afk
[12:28] <Mirv> :)
[12:32] <morphis> robru: ping
=== alan_g is now known as alan_g|lunch
=== xavigarcia is now known as xavigarcia_lunch
=== zsombi_ is now known as zsombi
[13:23] <jhodapp> sil2100, awesome thanks for looking into that
[13:27] <rvr> boiko: ping
[13:29] <boiko> rvr: pong
[13:29] <rvr> boiko: I have a Bluetooth speaker paired. When I do a call to the device, the ring tone is played on the phone and not on the speaker.
[13:29] <boiko> salem_: ^
[13:30] <boiko> salem_: can't remember if that's expected or not
[13:30] <salem_> rvr, I believe that's expected
[13:30] <rvr> salem_: "Ringing should go by default only to wired headset if connected"
[13:30] <boiko> rvr: I think we only play in both outputs when using wired headsets
[13:31] <boiko> rvr: yes, wired, not bluetooth
[13:31] <rvr> Ah, wired
[13:31] <boiko> rvr: :)
[13:31] <rvr> The call then uses the speaker
[13:31] <boiko> rvr: for wired headset it should ring on both the headphone and the speaker
[13:32] <rvr> and when I do a call using the device, the speaker is also used
[13:32] <rvr> The only thing that doesn't use the speaker is the ring tone when receiving a call
[13:33] <boiko> rvr: you mean in the bluetooth case?
[13:33] <rvr> boiko: Right
[13:33] <rvr> I don't have a wired headset
[13:34] <boiko> rvr: I think some regular wired headphones should work too (or they used to the last time I tried)
[13:52] <xavigarcia_lunch> jibel: ping
=== xavigarcia_lunch is now known as xavigarcia
[13:53] <xavigarcia> davmor2: hey there! Just to double check you received my previous message (sometimes my IRC does weird things)
[13:54] <davmor2> xavigarcia: possibly not
[13:54] <davmor2> xavigarcia: I saw your message on the trello card though
[13:54] <xavigarcia> davmor2: oh, ok... it was just about that
[13:54] <jibel> xavigarcia, pong
[13:55] <xavigarcia> jibel: hey! I've updated the indicator sound silo, to avoid those ugly notifications on phone calls
=== alan_g|lunch is now known as alan_g
[13:55] <davmor2> xavigarcia: I'll get back to you when I have some time
[13:57] <xavigarcia> davmor2: ok... thanks!
[13:58] <boiko> rvr: just flashed a krillin with silo 25 here and confirmed that with a wired headset it plays the ringtone on both the speaker and the headphones
[13:58] <rvr> boiko: Great, thanks
[13:59] <rvr> boiko: But it doesn't happen with my Bluetooth speaker
[13:59] <rvr> boiko: With OTA8, something is played on the speaker
[14:00] <boiko> salem_: do you have a bluetooth speaker to try it there?
[14:01] <boiko> rvr: we didn't change any of that in the code, so, if it is broken now, it might be because of some other landing, maybe the recent bluez changes?
[14:02] <boiko> rvr: can you just clarify what behavior you are expecting (and that you had in OTA8 on your device)?
[14:02] <rvr> boiko: According to davmor2, it should make a sound on both devices
[14:03] <rvr> He tested bluez5
[14:03] <boiko> rvr:/me checks the code, but I don't think that was implemented in our side.... let me see
[14:03] <boiko> salem_: ^
[14:04] <salem_> rvr, your bluetooth speaker has no hfp support probably
[14:04] <sil2100> kenvandine, cyphermox: hey guys!
[14:04] <cyphermox> sil2100: hey
[14:04] <sil2100> kenvandine, cyphermox: or actually, let me move this to #ubuntu-devel
[14:04] <salem_> rvr, I suppose you only hear the ringtone if your bluetooth device has hfp
[14:04] <rvr> I checked OTA8, and some kind of wait sound is played in the speaker
[14:06] <salem_> rvr, then it must be something related to the bluez change. morphis can probably comment on that.
[14:06] <rvr> salem_: I see
[14:06] <salem_> rvr, if that's the case, you can try with an older image, and if it works, we have to file a bug against bluez I think
[14:07] <boiko> rvr: in any casem the behavior you see with silo 25 should be the same as the one you see using latest packages from vivid overlay
[14:07] <salem_> rvr, yep, we haven't changed the ringtone behavior in any of the MR's in that silo.
[14:08] <davmor2> rvr, boiko: morphis can confirm but in my testing the phone always rang and then the headset made whatever tone it defaults to, Some ring like a phone others just beep
[14:13] <morphis> rvr, salem_, boiko: lets clarify one thing first:
[14:14] <morphis> if we're connected on the HFP profile we just send the indication and whatever ringtone the handsfree-device has is played, we don't stream any ringtone audio to the BT device
[14:14] <morphis> if we're to A2DP only device audio is forwarded to the BT device
[14:14] <morphis> which includes also the ringtone
[14:18] <salem_> morphis, thanks for the clarification.
[14:19] <morphis> salem_: so what are you seeing on your side?
[14:21] <salem_> morphis, I haven't tested yet. but rvr reported he is not hearing the ringtone in the bluetooth speaker, which according to your explanation it should be played.
[14:22] <morphis> salem_: make sure the speaker supports only A2DP
[14:22] <morphis> if it supports both HFP and A2DP you will only hear whatever the speaker wants to play on an incoming call
=== barry` is now known as barry_
=== barry_ is now known as barry
[14:26] <salem_> morphis, yes, from what I understood his device is A2DP only, and nothing is being played.
=== mhall119|fossetc is now known as mhall119
[14:27] <morphis> rvr: can you follow the steps under "Generating log files with debugging information" on https://wiki.ubuntu.com/DebuggingBluetooth and share /var/log/syslog after a reboot and reproducing this?
[14:27] <rvr> morphis: Ok
[14:29] <morphis> rvr: thanks!
[14:39] <rvr> morphis: There is no /etc/init/bluetooth.override
[14:39] <rvr> NOTE: If /etc/init/bluetooth.override doesn't exist use the following command instead
[14:41] <davmor2> rvr: so use the other command ;)
[14:41] <morphis> rvr: :)
[14:41] <rvr> I read that later, sorry :)
[14:41] <morphis> rvr, davmor2: once ota9 is released the .override line will go away :)
[14:47] <bfiller> sil2100: can you force merge silo 24 please (camera-app) - stuck in xenial proposed
[14:47] <rvr> morphis: <morphis> rvr: :)
[14:47] <rvr> Ups
[14:47] <rvr> morphis: http://paste.ubuntu.com/13477057/
[14:48] <sil2100> bfiller: on it, let me look at teh reason quickly
[14:48] <bfiller> sil2100: thanks
[14:49] <sil2100> bfiller: hmmm
[14:50] <sil2100> bfiller: give me a few mins, the excuses page didn't get updated yet so I don't see why it's stuck
[14:50] <bfiller> sil2100: sure, thanks
[14:50] <seb128> bfiller, why do you think it's stucked?
[14:50] <sil2100> But I see the package's been there for just 20 minutes
[14:50] <seb128> bfiller, it has been uploaded 15 minutes ago
[14:50] <sil2100> So maybe it's just migrating
[14:55] <bfiller> seb128, sil2100: yeah maybe, but figured it was stuck or blocked as it migrated immediately into vivid+overlay
[14:56] <bfiller> I'm just impatient I guess
[14:56] <bfiller> as I want to release a click bult from trunk
[14:57] <sil2100> It should be quick I suppose, I see it's a valid candidate and output doesn't say anything bad as well
[14:57] <sil2100> Should migrate with the next tick possibly
[14:58] <seb128> bfiller, the mps got merged so I guess it migrated
[14:58] <seb128> just got emails about one of my fix changing to merged
[14:59] <alex-abreu> trainguards having issues w/ silo 45 https://ci-train.ubuntu.com/job/ubuntu-landing-045-1-build/107/console
[15:04] <rvr> morphis: boiko: I created a bug here https://bugs.launchpad.net/canonical-devices-system-image/+bug/1519007
[15:04] <ubot5> Ubuntu bug 1519007 in bluez (Ubuntu) "Ringtone not played on the speaker" [Undecided,New]
[15:05] <boiko> rvr: thanks
[15:06] <seb128> rvr, morphis, boiko, is that a variant from https://code.launchpad.net/~tiagosh/telepathy-ofono/play_ringtone_speakers/+merge/276312 ? the bug linked to that mp is still open
[15:07] <Saviq> robru, hey ho, did anything change in the train recently that could cause https://ci-train.ubuntu.com/job/ubuntu-landing-005-1-build/219/console when using your -gles packaging approach? why would the qtmir tarball be missing?
[15:08] <boiko> seb128: nops, that's for wired headset, that's fixed already
[15:08] <seb128> k
[15:09] <morphis> rvr: thanks
=== salem_ is now known as _salem
[16:36] <Saviq> trainguards, I can't build https://requests.ci-train.ubuntu.com/#/ticket/690, it forces the -gles packages for qtmir and qtubuntu, but something must've changed and robru's trick for building those out of the same source doesn't work, qtmir tarball is not found when -gles is building :/
[16:36] <popey> congratulations sil2100
[16:49] <sil2100> popey: thanks! :)
[16:49] <sil2100> Saviq: hmm
[16:52] <popey> sil2100, I am told that the rc proposed bq aquaris image is putting the old terminal (grey, with header) and old file manager (wrong icon) in the image, mhall119 just told me his recent flash did this
[16:53] <popey> sil2100, is there some thing you need to poke to make it pull the right ones in
[16:54] <davmor2> popey: what channel
[16:56] <sil2100> popey: yeah, so that's still untouched - the good news is that I have already created the job that would create the proper tarball, but didn't have the time to hook that up yet
[16:56] <sil2100> popey: (that's only for mako bq-aquaris.en)
[16:56] <popey> davmor2, not sure, getting this from mhall119
[16:56] <popey> ok, thanks sil2100
[16:56] <sil2100> davmor2: it's ubuntu-touch/rc-proposed/bq-aquaris.en
[16:56] <davmor2> mhall119: I assume is using the bq one for location then pretty sure that is the one he was using
[16:56] <sil2100> It's the old unmaintained channel that I wish to put life into and then migrate to a proper name
[16:57] <davmor2> sil2100: yeap just going for clarification
[17:06] <alex-abreu> robru, ping
[17:12] <mhall119> davmor2: yes, I used the rc-proposed/bq-aquaris.en channel for mako images
[17:12] <mhall119> other core apps might be old in that image too, but terminal and file manager were the ones I noticed
[17:13] <davmor2> mhall119: all of them are old :)
[17:14] <mhall119> davmor2: I can relate :)
[17:15] <davmor2> mhall119: meh you're not old, you have to get to my age to be old
[17:15] <mhall119> davmor2: I'm working on it
[17:16] <rvr> boiko: Approving silo 25
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== _salem is now known as salem_
[17:51] <robru> morphis: except for the part where it created a second changelog entry with the same version repeated: https://ci-train.ubuntu.com/job/ubuntu-landing-054-1-build/lastSuccessfulBuild/artifact/bluez_vivid_packaging_changes.diff/*view*/
[18:02] <robru> Saviq: crap, yes
=== alan_g is now known as alan_g|EOD
[18:10] <robru> Saviq: you around? just emailed you with a fix
[18:11] <morphis> robru: yes, is that something we can fix?
[18:12] <robru> morphis: hmmm
[18:13] <robru> morphis: try rebuilding with changelog "bluez (5.36-0ubuntu1) UNRELEASED; urgency=medium"
[18:14] <robru> morphis: I think when you say "vivid" in there the train thinks that's just an old entry and it tries to make a new one
[18:17] <morphis> robru: without bumping 0ubuntu1?
[18:18] <robru> morphis: well no you'll need to bump it now otherwise the ppa won't accept the upload
[18:18] <morphis> ok, as I thought
[18:22] <Saviq> robru, here
[18:23] <Saviq> robru, applying
[18:26] <Saviq> robru, just looking at that, is SILONAME an env var exported by the train? are there others we could rely on in debian/rules clean if we wanted to do some things there?
[18:27] <robru> Saviq: yes, the train sets that. there are a few others. if you run the build job with $DEBUG = true you'll see a nearly-full list
[18:27] <Saviq> robru, ok, /me will look into the .pot update in debian/rules clean
[18:28] <robru> Saviq: other than what you see with $DEBUG, train will also add $DIST='xenial' (or whatever series) just before the build.
[18:34] <bfiller_> popey: when get a chance there is a new camera-app in store ready for review
[18:40] <boiko> robru: hi, so there were some launchpad translations update on dialer and messaging on trunk, but QA has validated the silo already
[18:40] <boiko> robru: is it just a matter of rebuilding them and publishing?
[18:41] <popey> bfiller_, done
[18:42] <robru> boiko: I fixed the train so that it doesn't invalidate the silo over just translation updates, so you should be good to publish
[18:42] <boiko> robru: great! thanks!
[18:44] <robru> boiko: oh wait, just looking at this log, seems a bug. the publish job is blocking but the status says 'successfully built'
[18:44] <salem_> robru, I just published
[18:45] <salem_> robru, ah ok, it failed again
[18:45] <boiko> salem_: robru: yeah. same error
[18:45] <robru> boiko: salem_ sorry about that guys, will push a fix
[18:46] <boiko> robru: that's ok, just let us know when it is fixed
[18:48] <robru> fix is in trunk, will roll that out asap
[18:48] <dbarth_> hey robru, we've got a merge request for a new package; see https://requests.ci-train.ubuntu.com/#/ticket/695
[18:52] <robru> dbarth_: seems mostly reasonable but it looks like somebody copied an old example. standards version should be (i think) 3.9.6 and the vcs-bzr field can just be "lp:signon-plugin-sasl"
[18:54] <robru> boiko: ok try now
[18:54] <boiko> robru: thanks
[18:54] <robru> boiko: you're welcome!
=== robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Train Jenkins will be going offline for maintenance at UTC 22:30
=== salem_ is now known as _salem
[21:43] <bfiller> fginther: trying to build gallery in jenkins and having some problems: http://s-jenkins.ubuntu-ci:8080/view/click/job/gallery-app-click/304/
[21:43] <bfiller> fginther: any ideas what's going on?
[21:43] <fginther> bfiller, looking
[21:45] <fginther> bfiller, I don't see a problem. It claim "Successfully built package in './com.ubuntu.gallery_2.9.1.1250_armhf.click'." and I see the artifact was saved. What am I missing?
[21:46] <bfiller> fginther: seeing "Publishing status: Error during build publishing " with a stack trace, thought that was a problem
[21:47] <fginther> bfiller, ah. those messages are related to the sending of the results and artifacts to the external jenkins. We're investigating but it all appears to be working. https://jenkins.qa.ubuntu.com/job/gallery-app-click/304/ exists as expected
[21:47] <bfiller> fginther: ok cool, thakns
[21:47] <fginther> bfiller, sorry about that. For now it appears to be an annoyance, but not a real problem
[21:48] <bfiller> fginther: no worries
=== _salem is now known as salem_
=== salem_ is now known as _salem