#ubuntu-ci-eng 2013-09-30
<fginther> thomi, pong?
<fginther> thomi, I'll should be back in 60-90 minutes
<fginther> thomi, are you there?
<thomi> fginther: am now - you?
<fginther> thomi, yo
<fginther> thomi, sorry about me email short on details. I'm trying to determine if there is a general pattern for what the ubuntu-ui-toolkit is doing.
<fginther> thomi, I know that the retry code I used is not the way to go.
<thomi> fginther: hey
<fginther> thomi, good evening
<thomi> fginther: I looked at your branch, but it wasn't clear to me exactly what the problem was you were trying to solve
<thomi> fginther: so maybe we ought to have a hangout about this tomorrow first thing?
<fginther> thomi, sorry about that, was a little rushed trying to send you something before I had to leave the house
<fginther> thomi, hangout tomorrow would be good
<thomi> fginther: yeah no worries
<thomi> fginther: it'll have to be first thing tomorrow though, since I have an appt in town afterwards
<thomi> fginther: I'll create a calendar event, so we both know when we're free
<fginther> thomi, that works for me, please schedule what works for you
<thomi> fginther: scheduled.
<thomi> fginther: our clocks have changed, which means NZ + US now have more overlap
<fginther> thomi, \o/
<thomi> presumably the US clocks will change soon as well, which should make it even easier :)
<fginther> thanks for offering to help, hopefully I'll understand the problem a little better tomorrow as well
<fginther> have a good night
<thomi> no worries
<lool> heya
<lool> didrocks: hangout?
<didrocks> lool: still answering emails, ok in ~20 minutes?
<lool> sure
<lool> didrocks: I'm on
<didrocks> lool: coffee and I'll be there
<lool> https://code.launchpad.net/~bfiller/mediaplayer-app/remove-no-display/+merge/188092
<lool> didrocks: LP #1232588
<ubot5> Launchpad bug 1232588 in upstart-app-launch (Ubuntu) "--desktop_file_hint still seems required for Mir" [High,New] https://launchpad.net/bugs/1232588
<didrocks> vila: https://plus.google.com/hangouts/_/b31c28f31fcf9e093dc094c78119b1080db93ff7
<vila> didrocks: sry, can't right now,
<didrocks> no worry ;)
<vila> didrocks, lool: some notes about the issue you mentioned during the week end: http://paste.ubuntu.com/6174698/
<vila> didrocks, lool: i.e. I looked, it could be fixed, do we want to or is it overkill ?
<vila> didrocks: no news about dns migration, will check later
<ogra_> damn, my daily DLS reconnect seems to now fall exactly into the meeting :(
<ogra_> *DSL
<lool> vila-afk-biab: There was some news about DNS migation somewhere
<lool> I heard we were switching DNS/DHCP in some lab since last friday, but can't remember where
<lool> vila-afk-biab: fixing the changelog: up to you, I just thought I'd pass it on since you had recently fixed the "-" handling
<lool> vila-afk-biab: There are certainly more urgent things to do though  ;-)
<lool> ogra_: lol
<lool> ogra_: perhaps you can reboot it in the morning?
<ogra_> well, or late at night
<lool> some folks here have a cron to reboot their cable connection in the middle of the night to have a stable IP during the day
<ogra_> yeah, my reconnect used to be around 4 or 5am ... not sure why it moved
<lool> it's tired of waking up so early, like me?
<ogra_> i guess i'll set up a cronjob
<ogra_> heh, likely
<lool> didrocks: Ah there was landing 51 for some click updater stuff already and I was pinned on it, probably when I got pinged by ralsina last week
<didrocks> lool: yeah, I wondered if it's the same
<didrocks> lool: please feel free to remove my duplicate if it's the same ;)
<lool> didrocks: I think yours covers slightly more, so will keep both
<didrocks> ok
<didrocks> sil2100: while I'm busy doing other things, do you mind landing friends?
<didrocks> sil2100: no need for testing, it's just a Standards-Version bump
<didrocks> (juts to clean the page)
<sil2100> didrocks: any testing needed? ACK
<sil2100> didrocks: done!
<sil2100> AFK for a quick momen
<sil2100> t
<didrocks> Mirv: I added request #58, can you look and test that with psivaa?
<didrocks> Mirv: divide the work as you wish, I think someone should take desktop, the other phone
<didrocks> (the changelog sounds good)
<Mirv> didrocks: ok!
<psivaa> didrocks: Mirv: let me know either way
<Mirv> didrocks: there's a blocker bug though since libusermetrics doesn't build, I filed a bug today
<didrocks> Mirv: ok, please ping upstream as well so that they know of it
<Mirv> but if excluding libusermetrics, then ok
<didrocks> Mirv: and we can publish without that one
<didrocks> yep ;)
<Mirv> didrocks: I'm planning to, ted is not line yet
<didrocks> ok ;)
<Mirv> psivaa: can you the the phone, upgrade the indicators stack and run tests there? the desktop - Unity7 tests - is a bit tricky but so I'm thinking I could run it because I know the pitfalls there and how to interpret the results because we've been releasing unity7 for a long time...
<Mirv> my sentences suck today
<psivaa> Mirv: ack will test the phone :)
<Mirv> psivaa: thanks!
<psivaa> yw :)
<didrocks> sil2100: Mirv: lool: ok, found out why the customization project wasn't listed. (configuration branch was not refreshed). Should be fine now
<didrocks> sil2100: please work on landing the customization one as well as discussed
<didrocks> Mirv: ok, so I just branch qtsystems and review?
<didrocks> Mirv: ah, we'll need a DEP5 format (so that we know if it's reported upstream) please
<didrocks> ping me once done
<lool> didrocks: why don't we just bzr pull the config regularly from jk?
<didrocks> lool: jibel convinced me to not do it, but TBH, I don't see anything block it (on that side at least)
<didrocks> lool: the whitelist still need to be manual (on snakefruit), but on magners, I think we could
<jibel> lool, didrocks IIRC the problem is that if you reconfigure jobs while they are running, jenkins aborts them (if that's what your referring to)
<jibel> you're
<didrocks> jibel: this is just about bzr pull on magners I guess
<didrocks> not deploying the config I guess
<jibel> if it is just a pull that's fine
<didrocks> let's cronify that then
<jibel> but at some point we talked about reconfiguring automatically
<didrocks> (done)
<didrocks> yeah
<didrocks> for that we need to pull out of jenkins a bunch of stuff
<didrocks> but I think this plan is now deadâ¦
<didrocks> sil2100: back?
<lool> why don't we do that as part of starting the tasks or something?
<lool> or just change the jobs to read from the config
<lool> e.g. instead of a "complex" job definition, you just make a thin wrapper around config/$job-name
<didrocks> lool: at first, we didn't want to rely on the config files, but yeah, it happens it's what needed now
<didrocks> lool: but TBH, this is not something we can tackle on anymore before V1, we are pulled in a lot of other directions ;)
<vila> didrocks: what's V1 here ?
<vila> cu2d V1 ?
<didrocks> vila: phone version 1?
<vila> oh, bah, silly me
<didrocks> :)
<vila> didrocks, lool: I know fginther takes care of having no jobs in flight while reconfiguring for upstream-merger. That's certainly something the CI engine should do transparently in any case, I for one will push for it, as well as leaving as little control to jenkins as possible for scheduling (been there, suffered from that, don't want to try again ;)
<didrocks> sil2100: how was friends published? Did you check? I see everything in red on that stack
<Mirv> didrocks: DEP5 added to qtsystems.
 * vila catches up backlog
 * cjwatson adds landing ask 123 for click 0.4.9
<vila> lool: yeah retoaded said he will attempt to further test the dns migration during the week end but I got no feedback so I'll re-check later and will relay the feedback here
<didrocks> cjwatson: I guess this is backward compatible and tested against all the other click packages, even if some were not yet landed? (http://people.canonical.com/~platform/cu2d/results)
<didrocks> Mirv: sponsored, thanks!
<Mirv> thanks!
<cjwatson> didrocks: Should be entirely backward-compatible, though I'm reflashing now to run tests
<didrocks> cjwatson: ok, feel free to upload once the tests are done (filing landing ID 60)
<cjwatson> didrocks: Are the .click files for the unlanded packages available anywhere?  (Though TBH I think it would be fine to test against the ones in http://people.canonical.com/~ubuntu-archive/click_packages/ - AFAIK they're constructed the same way)
<didrocks> cjwatson: ah, I only know about the .debs that are waiting (see the *-click-* packages in http://people.canonical.com/~platform/cu2d/results), not sure about the .click one TBH
<didrocks> Mirv: yw ;)
<cjwatson> didrocks: Oh, it won't affect that at all, but I'll run what tests I can find
<didrocks> thanks ;)
<didrocks> sil2100: also, have you disabled autopilot the other day for real? I see still some builds in the ppa
<didrocks> seb128: mind merging back your changes to indicator-keyboard trunk please? ;)
<seb128> didrocks, waiting for somebody to approve https://code.launchpad.net/~seb128/indicator-keyboard/saucy-manual-upload/+merge/188065 since friday...
<seb128> didrocks, not sure why the CI didn't kick in again after I pushed the new revision though
<didrocks> seb128: ah, you proposed that back, thanks! seems upstream isn't responsive then.
<seb128> didrocks, well, I think they were waiting for CI
<didrocks> seb128: what about kick in? it doesn't find the latest revision in the archive
<didrocks> ah
<didrocks> upstream merger
<seb128> right
<seb128> let's just approve it
<didrocks> yeah
<seb128> can you do that?
<seb128> thanks ;-)
<didrocks> done ;)
<didrocks> thanks to you!
<didrocks> sil2100: I'll go soon exercising, I hope you will be back once I'm back so that you can process friends +  ubuntu-touch-customization-hooks updates (also see my other questions)
<didrocks> sil2100: also, it will be nice if you can evaluate the settings stack at the same time
<sil2100> ACK
<sil2100> didrocks: I published the friends stack, as when I was publishing the stack it was still waitonstacks
<didrocks> sil2100: maybe try rerunning it?
<didrocks> or restoring the .bak
<sil2100> hmmm
<sil2100> I wonder what happened
<sil2100> cp: cannot stat `/var/lib/jenkins/cu2d/work/saucy/friends/*_friends-app.xml': No such file or directory
<didrocks> sil2100: interesting, maybe you just got unlucky and published just after the stack was unlock?
<didrocks> unlocked*
<sil2100> didrocks: should I re-run the whole stack normally or just do a force publish again?
<didrocks> sil2100: I think restore the previous .bak
<didrocks> and then try publishing
<didrocks> sil2100: better?
<sil2100> didrocks: tried restoring the .bak, but it seems I don't have some perms like: cp: cannot open `friends.bak/libfriends_0.1.2+13.10.20130929.1-0ubuntu1_source.changes' for reading: Permission denied
<sil2100> didrocks: is it ok without those?
<didrocks> sil2100: should be
<didrocks> as long as you have the .project
<sil2100> hmmm
<sil2100> http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Friends/job/cu2d-friends-saucy-3.0publish/42/console
<sil2100> I wonder whatsapp
<didrocks> sil2100: bzr: ERROR: Cannot lock LockDir(file:///var/lib/jenkins/cu2d/work/saucy/friends/libfriends/.bzr/branch/lock): Permission denied: "/var/lib/jenkins/cu2d/work/saucy/friends/libfriends/.bzr/branch/lock/yyzntm7kvu.tmp": [Errno 13] Permission denied: '/var/lib/jenkins/cu2d/work/saucy/friends/libfriends/.bzr/branch/lock/yyzntm7kvu.tmp'
<sil2100> Permissions look ok,
<didrocks> sil2100: are you connected to mangers? I can't apparently
<sil2100> didrocks: it takes around 1 minute to connect ;/
<sil2100> So you need patience
<sil2100> drwxrwxr-x+ 2 desktop-team jenkins 4096 Sep 29 21:23 lock
<didrocks> oh
<didrocks> you did cp
<didrocks> why not mv?
<didrocks> (or even cp -p :p)
<sil2100> I did a mv of the old one, and then cp -a ;)
<sil2100> Ok, so I'll do a mv then!
<didrocks> weird, if you cp -a, desktop-team shouldn't be the owner
<didrocks> so yeah, rm -r friends
<didrocks> mv friends.bak friends
<sil2100> cp -a friends.bak/ friends
<sil2100> k ;)
<didrocks> sil2100: so, we're good now?
<sil2100> didrocks: with friends, yes! Waiting for misc to finish
<didrocks> sil2100: ok, did you read about AP which seems to still be in the ppa and building?
<didrocks> sil2100: did you forgot to deploy the backout on Friday?
<didrocks> (I think we should remove it again and remove it)
<didrocks> sil2100: while you are waiting on misc stack, maybe you can start the settings one? (running AP tests for ubuntu-system-settings-online-accounts + some dogfooding for system-settings?)
<sil2100> Aye aye! I was almost sure I was deploying *something*, but I guess I didn't!
<sil2100> heh
<sil2100> Maybe I redeployed the wrong branch
<didrocks> maybeâ¦
<didrocks> Mirv: psivaa: how are the indicators tests looking?
<Mirv> didrocks: argh! I just figured out you said 'changelog' looked fine, not the 'changes' (packaging changes) regarding indicators!
<Mirv> didrocks: so published, a moment ago, but..
<didrocks> oh?
<didrocks> ok, let me look at the FS
<Mirv> didrocks: so this's because the cu2d was read, and it didn't show the packaging changes under the publish stack
<Mirv> s/read/red/
<didrocks> Mirv: yeah, there is a trick for that
<didrocks> (foo + AUTO_PUBLICATION)
<didrocks> Mirv: it was red because of the tests?
<Mirv> it's http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-bluetooth_0.0.6+13.10.20130927-0ubuntu1.diff + http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-datetime_13.10.0+13.10.20130927-0ubuntu1.diff + http://10.97.0.1:8080/view/cu2d/view/Saucy/vi
<didrocks> ok, let me look :)
<Mirv> didrocks: red because of libusermetrics build failure. I did autopilot locally and so did psivaa
<didrocks> ah ok ;)
<didrocks> Mirv: ok, it seems to be the same thing everytime, so yeah, looking good
<Mirv> yeah it looked good to me too, but sad still to me. I'm writing a note about special case handling with foo + AUTO_PUBLICATION.
<lool> ralsina: around?
<didrocks> Mirv: yeah, this one is really tricky ;)
<Mirv> didrocks: "do no use manually" says the hint for that :)
<didrocks> Mirv: when you run it, ensure that the stack is not running at all
<didrocks> there is no safety net
<didrocks> hence this "do not use manually" :p
<ralsina> lool: here, good morning!
<lool> ralsina: good morning!
<lool> ralsina: we would like to land click-package stack, that is everything listed in the first section of http://people.canonical.com/~platform/cu2d/results
<Mirv> right. I tend to not to ever do anything if stack is running anyhow (or stop it before).
<lool> ralsina: a) are you aware of any issue  b) do you miss anything there before it may land  c) any suggested tests we should focus on?
<lool> my plan was to update to these, test installing + running + removing a click, and checking for click updates, albeit I always get "No updates found"
<ralsina> lool: the main thing bugging me there is that testing click-updater gave us conflicting results. But since it was totally broken, even the worst case is an improvement
<ralsina> lool: well, to test for updates, we are installing some old clicks via pkcon then checking
<lool> can I download old clicks from somewhere?
<ralsina> lool: we have a few, let me get you the URLs
<lool> thanks
<lool> one is enough I guess
<lool> small  :-)
<ralsina> lool: there is a copy of old hello world somewhere, gatox is loking for it
<gatox> lool, hi, ralsina asked me to give you this old clicks: http://ubuntuone.com/0mHE7D9wQLkd2DXBJROxTi - http://ubuntuone.com/3KnGeEQjvt9nXul0JLLDew
<lool> gatox: ty
<mandel> lool, ralsina can I propose landing a critical fix first in the ubuntu-download-manager (that was there for a long time but had no reviews?)
<mandel> lool, ralsina ideally, files should not cleaned after they have been downloaded, yet in case they are not I added => https://code.launchpad.net/~mandel/ubuntu-download-manager/throw-error-exists/+merge/187527
<sil2100> didrocks: eh, it seems cordova-doc build is hanged ;/
<sil2100> didrocks: "Started 6 hours ago"
<sil2100> didrocks: and it doesn't move at all
<sil2100> I'll abort it maybe?
<sil2100> Ok, no, wait, it moves
<sil2100> But why 6 hours?
<Laney> Can someone make the CI re-run on https://code.launchpad.net/~laney/ubuntu-system-settings/measure-size-critical-fix/+merge/188020 ?
<lool> mandel: looking
<mandel> lool, take into account that in the case where the file is not removed by the client we are appending to it, and that is a terrible idea. It is also the possible cause to see those 200% progress results
<lool> Laney: done
<Laney> merci
<ralsina> lool: let's land that as well, but it has no correlation with the click stack, it can go in any order (if that helps)
<cjwatson> sil2100: (if this didn't get resolved while my connection was bouncing)  Have you checked that the logtail isn't progressing?
<lool> mandel: hmm looking at the diff, I'm not too convinced with the file handling stuff
<cjwatson> sil2100: In fact, it looks like the logtail *is* progressing, so it's not huge, just slow due to png compression
<cjwatson> *not hung
<mandel> lool, what worries you?
<lool> mandel: that the download service itself is running unconfined and writing to computed pathnames
<lool> like appending an id at the end of a filename to create a new one
<sil2100> cjwatson: as I mentioned: "Ok, no, wait, it moves", but I wonder why it takes 6 hours already
<lool> I'm not sure how secure and private the ids are, but it seems like this could be abused with a symlink created by a malicious app to write outside of its app dir
<sil2100> cjwatson: since damn, it's i386, 6 hours for one package is a LOT
<cjwatson> sil2100: png compression can be enormously slow on systems with lots of pngs
<cjwatson> unfortunately
<cjwatson> s/systems/packages/
<mandel> lool, the downloader is, when running as a system app, writing anywhere it wants, hence the error, the appending is just happening when we are running for a request of a confined app, in that case we are writing to XDG_DATA/APP_ID/filepath(uuid if needed)
<sil2100> cjwatson: thanks
<cjwatson> sil2100: you can make sure all pngs are already optimised in the source (or that it doesn't make enough of a difference in size to be worth it), and then export NO_PNG_PKG_MANGLE=1 while running dh_builddeb
<lool> mandel: exactly, so if I'm app==APP)ID, what happens if I create a filepath-uuid -> ~/.upstart/my-job.conf symlink and make download manager download an upstart job?
<cjwatson> e.g. override_dh_builddeb:\n\tNO_PNG_PKG_MANGLE=1 dh_builddeb
<lool> mandel: anyway, to box this I propose we land whatever you think are good fixes that pass the testsuite and aren't regressing click downloads or system-image testsuite; we can worry about the confined app use case later and get a security review
<lool> we need to ask security team about apparmor profiles anyway
<mandel> lool, so, you mean that you point me to download an upstartjob, then if you are confined I'll write it to XDG_DATA/APPID/my-job.conf
<mandel> lool, what is wrong with that?
<mandel> lool, then, I think we should land that branch
<lool> mandel: the symlink part was that it would write the download to ~/.upstart/my-job.conf for an unconfined app
<mandel> lool, we can always return an error if the file is present
<mandel> lool, and let app developers deal with it
<lool> mandel: right; you need to do the write in a secure way, race free
<mandel> lool, can you add a comment and I'll update the branch so that if present, we raise an exception
<lool> mandel: typically if(!exists(file)) {write(file)} is racy
<mandel> lool, I fear that the click scope is not cleaning the files and that will break it :-/
<lool> mandel: anyway, I dont think this relates, reading the diff just made me realize this isn't ready for prime time for the confined apps
<mandel> lool, so, I'll add that fix and we won't land it 'til I have checked that the click-scope is doing things correctly
<fginther> morning
<lool> will log a bug
<mandel> lool, thx
<lool> mandel: let's land your fix though
<mandel> lool, ok, I'll pay attention to that, we need to ask security, I'd like their input for this
<lool> mandel: it's non-trivial to get it right, e.g. that applies when creating the download directory too
<cjwatson> mandel: I believe you're right; I've noticed in the past that if I use the click scope to install a package, then manually make it look like a lower version on the filesystem, then use click-updatemanager to try to upgrade it, that the download manager creates a download file consisting of two copies of the package concatenated, and the click-updatemanager reports 200% progress and then fails to install the invalid file
<mandel> cjwatson, yeah, that is an issue, both in the downloader and the scope, that branch fixes it just changing the downloader side
<lool> mandel: https://bugs.launchpad.net/ubuntu-download-manager/+bug/1233149
<ubot5> Ubuntu bug 1233149 in ubuntu-download-manager "Must write downloads of confined apps securely" [Undecided,New]
<mandel> lool, thx
 * mandel goes to have some food
<lool> didrocks: so the above important bugfix from https://code.launchpad.net/~mandel/ubuntu-download-manager/throw-error-exists/+merge/187527 is pending merging, but is part of click-package stack; I'd like to get it in too, that way we update all packages of the click-package stack today  ;-)
<lool> my only problem is that I'm falling asleep
<lool> ralsina: gah, would you please a) top approve https://code.launchpad.net/~mandel/ubuntu-download-manager/throw-error-exists/+merge/187527  b) tell your team to top approve stuff and not just approve it or upstream merger doesn't merge  c) give me / others permissions to top approve your branches?  Thanks!  :-)
<ralsina> lool: approved, mandel forgot to do it after it was agreed to land it
<cwayne> asac: ping
<cjwatson> cwayne: He's on holiday
<cwayne> cjwatson: ah, thanks.. a  /nick asac-holiday could've been helpful :)
<cwayne> didrocks: ping
<sil2100> ogra_: hi! Do you have a moment ;)?
<ogra_> sil2100, shoot
<sil2100> ogra_: I need core-dev ACKs for: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Settings/job/cu2d-settings-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings_0.1+13.10.20130930-0ubuntu1.diff and http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Settings/job/cu2d-settings-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings-online-accounts_0.2~+13.10.20130930-0ubu
<cjwatson> sil2100: ack on the first, nack on the second
<cjwatson> sil2100: Shouldn't be "Section: debug"
<cjwatson> Hah, other packages are like that, but it's still wrong :)
<ogra_> thanks for checking cjwatson ... i seem to not be able to reach that machine
<sil2100> cjwatson: will you give a conditional ACK if I promise to prepare a merge for changing that? ;)
<cjwatson> sil2100: I'd suggest just deleting the Section: line
<cjwatson> sil2100: I'm just checking some context for the rest of it
<cjwatson> sil2100: Surely you need to handle dh_python2/dh_python3 integration too?
<cjwatson> sil2100: It's not generally OK to just dump files into /usr/lib/python*/dist-packages/ without the use of any Python helper
<sil2100> cjwatson: well, sorry, but that's what 90% of our touch -autopilot packages do right now, so even if it's not really ok, that's the standard that is currently used
<sil2100> cjwatson: ;)
<cjwatson> I'm afraid that doesn't convince me to ack it
<sil2100> cjwatson: I'm not the one doing the packaging here
<cjwatson> sil2100: I think you basically need (a) Build-Depends: python (>= 2.7); (b) dh $@ --with=python2; (c) add ${python:Depends} to Depends
<cjwatson> That still doesn't convince me to ack it :)
<cjwatson> You aren't going to convine me to ack something incorrect
<cjwatson> *convince
<sil2100> cjwatson: ok then, I'll wait for didrocks to decide on what to do with this release
<sil2100> cjwatson: then why didn't the release team reject all the other packages if they are incorrect?
<cjwatson> The above sequence should be basically all you need, simple enough
<cjwatson> sil2100: I didn't see them :-P
<sil2100> cjwatson: right
<ogra_> the wonderful world of auto-approval
<sil2100> didrocks: ping, the settings stack is blocked for now, see ^ for context
<cjwatson> Might also need "X-Python-Version: 2.7" since autopilot.pro hardcodes 2.7
<cjwatson> In which case Build-Depends: python (>= 2.6.6-3~) is actually more correct
<cjwatson> Given that this is a five-minute build, this should take about ten minutes to fix
<cjwatson> I'll go and fix overrides for the other autopilot packages in the archive; that "Section: debug" has a good chance of causing problems once ddeb support is fully implemented in Launchpad
<cjwatson> (As in, the packages will probably vanish from the primary archive)
<cjwatson> Oh good grief, all *-dbg are in debug.  I wonder if I misunderstood that section ...
<cjwatson> Looks like I did.  Hmm.
<cjwatson> sil2100: I withdraw the "Section: debug" part of my comment; I think it might perhaps be better for *-autopilot to be in some other section, but we can override it in the archive if we so choose and it isn't a blocker of any kind at the package's end
<didrocks> lool: ack
<didrocks> sil2100: cordova-doc: please abort I guess
<didrocks> sil2100: oh, no, it doesn't. Hum, the build seems very long
<didrocks> sil2100: so, let's try to release it so that we don't have it again
<sil2100> didrocks: so we should wait for it to finish? (7 hours running already)
<didrocks> sil2100: yeah, and then, we ensure it's in
<sil2100> ACK
<didrocks> sil2100: keeping a look on that?
<sil2100> didrocks: I'll keep a tab opened, hope it will finish building till the end of the day!
<didrocks> sil2100: cjwatson: we have examples in other packages how we handle building with python
<didrocks> sil2100: look at unity8 (debian/rules)
<didrocks> sil2100: so I doubt 90% of the packages are doing that, for those I looked at leastâ¦
<cjwatson> I'm preparing a patch for friends-app now by way of example
<sil2100> didrocks: well, notes-app, gallery-app, friends-app
<sil2100> didrocks: messaging-app as well
<cjwatson> And yeah, unity8 is better
<sil2100> didrocks: I would say that all *-app packages that we daily release have that
<cjwatson> So let's fix them and not get it wrong in new code
<sil2100> didrocks: so it's no wonder someone added the autopilot packaging in the same way
<cjwatson> Like I say, it's really not hard, I'm preparing a patch that people can crib from
<didrocks> sil2100: yeah, same issues than autotoolsâ¦
<didrocks> cjwatson: +1
<sil2100> didrocks: if you guys say it's invalid, well, I won't argue as yes, it's a bit strange to not use setup.py - I only wonder how we were able to push so many packages with this into the archive, I thought that it's acceptable since that happened
<didrocks> sil2100: for unity8, I've implemented a setup.py upstream for this
<cjwatson> Not using setup.py is also weird, but it wasn't what I commented on.
<cjwatson> sil2100: https://code.launchpad.net/~cjwatson/friends-app/dh-python2/+merge/188338 - shouldn't be harder than that for the others
<cjwatson> (Of course some other core dev should probably eyeball that)
<sil2100> cjwatson: is python:any valid? Just asking since somehow somewhere I remember we had a problem with using that (I might me mixing up problems though)
<seb128> sil2100, https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.0.2+dfsg1-7ubuntu5 is what you remember
<sil2100> seb128: thanks! heh, something similar was echoing in my ears and I couldn't differentiate it from the noise
<Laney> Is there a hidden point to the libfriends upload that just bumps standards-version?
<fginther> retoaded, dns resolution is failing on the qa machines (i.e. ps-saucy-server-amd64-1, ps-android-sandybridge). Is this a known issue?
<cjwatson> sil2100: Yes, it is valid.  Some details of it were only fixed up in the last few months
<sil2100> cjwatson: I get a lintian error on your branch - is that normal?
<sil2100> cjwatson: E: friends-app source: missing-build-dependency-for-dh-addon python2 => python | python-all | python-dev | python-all-dev
<retoaded> fginther, let me poke but it may be related to me changing the DHS/DHCP services for those networks.
<cjwatson> Er, by which I mean "two weeks ago"
<cjwatson> sil2100: Yes, that's Lintian being out of date and can be ignored
<cjwatson> sil2100: FWIW, while the change seb128 pointed to would have been blocked by the infrastructure bug that I fixed on 16 September, it would have been blocked anyway because the previous state was just wrong; you can only use :any dependencies if the target of the dependency is Multi-Arch: allowed
<cjwatson> sil2100: But python is Multi-Arch: allowed, and is indeed the canonical example of this kind of dependency
<cjwatson> We have quite a few of these in the archive now
<sil2100> ACK, awesome
<sil2100> cjwatson: https://code.launchpad.net/~sil2100/ubuntu-system-settings-online-accounts/dh_python2/+merge/188340 <- is the same change ok here?
<cjwatson> sil2100: Yep, looks fine
<cjwatson> sil2100: That has my ack with that merge
<sil2100> cjwatson: thanks
<cwayne> mfisch: next day or two according to pete-woods
 * cjwatson sees that security has taken over the build farm for a while
<lool> == Building click-package stack ==
<mandel> ralsina, lool I just top approve when I have two reviews, that is why that branch was not merged, let me know if you want me to change that :)
<cjwatson> Uploaded click 0.4.9
<lool> to pick up the ubuntu-download-manager rev that got merged a couple of minutes after the tick
<didrocks> great ;)
<ralsina> mandel: I top-approved it anyway
<lool> mandel: If you have a stricter policy than one review that's fine; usually folks reviewing just approve + top approve things when they are happy with it, and the upstream merger jenkins does another approve if it builds and passes the configured tests
<mandel> lool, we usually do 2 human reviews + jenkins bot, if all those 3 are ok then the person that proposes the branch does the top approve (in case the mp had comments for non blocking changes for example)
<lool> mandel: ok; nervermind then, this is special to your team, and I cant blame you guys for doing one more review than what others do
<didrocks> sil2100: apart from that, testing the settings went ok? so you can publish them both once rebuilt?
<didrocks> sil2100: also, I feel cordova-docs is *almost* merged ;)
<didrocks> built*
<didrocks> sil2100: also, the customization hooks have progressed?
<didrocks> (not sure if you followed, but I got why it didn't show up this morning)
<sil2100> didrocks: testing went fine, ran the AP tests on the device as well, but some of the tests are actually desktop-only
<sil2100> didrocks: did some dogfooding, all green
<cjwatson> Yeah, cordova-docs is built now
<didrocks> sil2100: please publish whatever you can, will be helpful before the meeting to know what's still needed for image 71
<cjwatson> I think I'll rebalance the i386/amd64 builders back to 4/4, since there's a bit of a queue
<cwayne> didrocks: the customization hooks were updated last week but haven't landed yet
<cjwatson> 10 pending amd64 builds
<didrocks> cwayne: yeah, we are working on publishing it
<cwayne> didrocks: cool, thanks. just saw customization-hooks and figured i'd give some context :)
<sil2100> didrocks: will rebuild settings once my merge gets in
<didrocks> cwayne: yeah, no worry, thanks for following! :)
<didrocks> sil2100: ok, so on customization first? or this just need publishing? not sure if your hands are free or not? (there is a new package pending)
<sil2100> didrocks: I can tackle ubuntu-touch-customization-hooks now, any additional tests that need to be ran for that?
<bfiller> fginther: we are quite blocked by otto autopilot failures on multiple MR's
<didrocks> sil2100: I don't think there is any TBH
<didrocks> sil2100: did you fix AP trunk btw?
<didrocks> sil2100: I mean, removed from the ppa and deployed the removal?
<bfiller> fginther: sounds like you and omer are discussing a plan but we need this fixed asap. have a ton of stuff to land
<sil2100> didrocks: by fix you mean, removed? Yes
<sil2100> didrocks: it's removed from the PPA and disabled in the stack
<fginther> bfiller, hey, we discusses a potential plan this morning with omer and iftikhar to disable the otto tests until the underlying problem is fixd
<didrocks> sil2100: thanks a lot man :)
<bfiller> fginther: sounds good, can we do that now?
<didrocks> fginther: what's the issue?
<sil2100> didrocks: I'll publish misc - checking what components are in ;)
<didrocks> great!
<fginther> bfiller, yes, trying to, unfortunately there is a network issue blocking everything else at the moment
<fginther> bfiller, but will update the jobs as soon as possible
<fginther> didrocks, it looks like tab switching is unreliable - https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1232857
<ubot5> Ubuntu bug 1232857 in Ubuntu UI Toolkit "Autopilot tests failing when objects disappear" [Undecided,New]
<sil2100> didrocks: juust... cordova-docs is still pending publication ;/
<bfiller> fginther: thanks
<didrocks> sil2100: yeah, do the customization stuff and you can switch on that one just after I guess
<didrocks> then 2 down!
<didrocks> fginther: which autopilot version are you using?
<fginther> didrocks, 1.3.1+13.10.20130930-0ubuntu1
<didrocks> fginther: where are you taking it?
<didrocks> fginther: it's been multiple days we have issues with AP in daily-build ppa FYI
<didrocks> so it's now removed
<didrocks> please retry before disabling (now that this version is removed)
<fginther> didrocks, yes, that's from the ppa
<fginther> didrocks, will give it a fresh try
<didrocks> fginther: please keep me posted
<lool> didrocks: I intend to push mediaplayer-app from media stack alone (by doing the rename .project dance); any objection?  this is just the NoDisplay=true removal to fix activation from scopes
<didrocks> bfiller: "fix for flaky autopilot tests", really really really? \o/
<didrocks> lool: ok, you did run the mediaplayer-app AP tests?
<didrocks> lool: not sure if it's using unity8 to test scope activation
<sil2100> didrocks: is cordova-docs preNEWed?
<didrocks> sil2100: I think I did, let me look again at it
<didrocks> (looking at the last commits)
<sil2100> didrocks: if yes, then I'll publish it along with ubuntu-touch-customization-hooks now ;)
<didrocks> sil2100: my requested change is in, so +1
<didrocks> sil2100: refreshed the whitelist as well
<bfiller> didrocks: indeed!
<didrocks> bfiller: you will get in front of the queue for image 72 I guess :p
<didrocks> bfiller: will release the ubuntu-keyboard back (we just fixed trunk with mismatch in the archive)
<lool> didrocks: I did not run AP tests; they don't pass for sure (bug filed) since the removal of SceneSelector; however the change is trivial in the .desktop and I ran with this change locally
<lool> bfiller: (did you see my bug about mediaplayer AP tests?  ;-)
<bfiller> didrocks: thanks
<didrocks> lool: I just wanted to ensure we don't regress any other tests we can have in unity8 in the way we launch apps
<bfiller> lool: we supposedly skipped the tests for scenne selector, let me check with renato
<lool> didrocks: this doesn't change the way we launch apps though, it changes just the mediaplayer-app .desktop file so that upstart-app-launch stops refusing to launch it
<didrocks> lool: ok, ack then
<lool> bfiller: Yes, some indeed seemed disabled, but at least another one seems related and fails https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1233020 and there's another failure where I can't tell whether it relates
<ubot5> Ubuntu bug 1233020 in mediaplayer-app (Ubuntu) "Autopilot tests not passing without SceneSelector" [Undecided,New]
<bfiller> lool: what environment did the tests fail on?
<lool> bfiller: upstream merger
<bfiller> lool: is that the VM based environment or running directly on device? just curious as we are seeing VM issues that fginther is reporting and wondering if this related
<lool> bfiller: I don't know, I think there's a link in the bug
<didrocks> bfiller: TBH, I think you are getting AP issues, not VM issues (but let's see if Francis confirms)
<lool> right, there's a link thre
<lool> so I wanted to play with click stack, but download-manager didn't build on amd64 yet
<cjwatson> 15:38 <cjwatson> I think I'll rebalance the i386/amd64 builders back to 4/4, since there's a bit of a queue
<cjwatson> 15:39 <cjwatson> 10 pending amd64 builds
<cjwatson> lool: ^-
<bfiller> loo, didrocks : I think this is the same problem that is preventing many of our MR's from landing on different apps
<bfiller> lool: ^^
<bfiller> lool: can you run the test on a device? I bet it will work fine
<lool> cjwatson: thanks
<lool> bfiller: not right now
<lool> bfiller: will try later, if you beat me just say so in the bug report and close it
<lool> bfiller: and poke fginther about it I guess :-)
<lool> bfiller: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4470/mediaplayer-app-autopilot/ seems to back your analysis though
 * didrocks will bet on AP trunk
<sil2100> didrocks: *sigh* my settings merge got rejected by jenkins
<sil2100> A unit test failure ;/
<lool> didrocks: so I just set FORCE_PUBLICATION, nothing else, and rebuild with renamed .project files?
<cjwatson> sil2100: As was my friends-app merge for some autopilot-related reason I can't sort out.  Don't know if it's the same as lool's failure above
<fginther> lool, bfiller, those failed tests were on the hardware env
<cjwatson> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-saucy/480/testReport/junit/friends_app.tests.test_timeline_view/TestTimelineView/test_toolbar_with_mouse_/
<didrocks> lool: FORCE_PUBLICATION, then once in, rename the .project file, and rebuild with "foo" to recreate the state
<didrocks> sil2100: argh, can you get some help upstream?
<lool> didrocks: Gah, getting this http://10.97.0.1:8080/job/autopilot-saucy-daily_release/2236/
<lool> didrocks: seems like the same issue as upstream merger
<lool> bfiller: ^
<lool> so real failures
<didrocks> cjwatson: lool: AP is the one in the archive, so different
<lool> MismatchError: After 10.0 seconds test on SceneSelector.opacity failed: 1 != dbus.Double(0.0, variant_level=1)
<lool> this is definitely one of the bogus tests I intend to ignore
<lool> ok, forcing this one through
<didrocks> (I mean, it's not AP trunk's fault like what we saw somewhere else)
<lool> pushed mediaplayer-app, rebuilding media stack with "foo"
<fginther> retoaded, any ideas what the DNS issue is? I'm getting lots of backed up jobs. If I need to I'll try to convert them to using IPs
<retoaded> fginther, all of the VMs/systems that have rebooted should be working correctly. Let me proceed through all of you running VMs to a) make sure they are getting their IPs from the new DHCP server and b) are resolving correctly.
<fginther> retoaded, do we need to reboot ps-android-sandybridge also?
<rfowler> fginther: i just rebooted it 1/2 hour ago
<didrocks> bfiller: do you mind expanding the "use qml bindings for infographics"?
<didrocks> bfiller: like, is there any bug report?
<retoaded> fginther, that was already done and it has the correct information. I believe it's problem is that psoglav is using the older DNS server so using the IP for now would be a better option which has been done.
<bfiller> didrocks: done
<fginther> retoaded, ack
<bfiller> no bug report, just apps are supposed to use new api
<bfiller> which is qml
<didrocks> bfiller: ok, sounds good, thanks ;)
<bfiller> np
<doanac> asac: is there anything i can do to help get autopilot unblocked from the landing-pipeline?
<retoaded> fginteher, later this afternoon I will switching the last network (10.97.2.0/24) over to the new DNS/DHCP servers. Once that is done I will need to reach into every system and restart networking so they all get the correct information and then update all of the servers.
<didrocks> doanac: asac is on vacations
<retoaded> It will be time consuming but will get done.
<didrocks> doanac: right now, from our tests, AP trunk regressed all apps + unity8 tests
<didrocks> doanac: if you can get a fresh image, update to AP trunk and run all AP apps + unity8 to confirm it, that will be helpful
<didrocks> (and then fixing ;))
<doanac> didrocks: interesting. i'm not sure AP had any functional code changes.
<ogra_> sergiusens, ^^^
<didrocks> doanac: it seems that it regressed one way or another (multiple confirmation by sil2100 and Saviq)
<didrocks> doanac: we don't really know more though, had to go back on prod side :/
<sergiusens> ogra_, doanac from what I know, only thing we changed was a hook file which isn't even used with autopilot directly but from the click hook system
<sergiusens> didrocks, ^^
<doanac> sergiusens: there are more changes that have queued up now
<sergiusens> doanac, that sucks, can we daily release with only our change?
<didrocks> sergiusens: doanac: quite a lot: https://code.launchpad.net/~autopilot/autopilot/1.3
<sergiusens> didrocks, doanac can we distro patch with just http://bazaar.launchpad.net/~autopilot/autopilot/1.3/revision/336 and http://bazaar.launchpad.net/~autopilot/autopilot/1.3/revision/335 ?
<didrocks> sergiusens: hum, this is getting complicated, can't we work with thomi to get the issues fixed?
<didrocks> sergiusens: because ensuring AP doesn't regress is taking 2 hours, I will rather fix the real version
<didrocks> sergiusens: when/why do you need that right now?
<didrocks> (just trying to assess)
<sergiusens> didrocks, it's blocking click package testing for two weeks now
<didrocks> sergiusens: well, I think we should try to get thomi on board to fix AP issue, maybe that's not a biggie and we can get that in tomorrow
<sergiusens> doanac, we can always side fix this and put the hook in phablet-config and make the hooks rerun with a tmpdir
<doanac> sergiusens: yeah. even with the fix, I'm still seeing something bad. I'm sending you an email now to explain how to re-create it
<sergiusens> doanac, great, I'll look into it
<Laney> can someone please retry https://code.launchpad.net/~mterry/unity8/statsWelcomeScreen/+merge/184153 too? The failures all look transient to me
<Laney> Alternatively tell me if me clicking on the rebuild link actually works
<Laney> :-)
<sergiusens> Laney, rebuild works if logged in to jenkins behind the firewalls
<Laney> oh, probably not then
<Laney> I have no account there afaik
<sergiusens> Laney, look at what's on the MR (latest comment)
<Laney> sergiusens: how timely
<sergiusens> yeah
<Laney> the CI was still busted :P
<sergiusens> doanac, saw your email, will look at it after a quick bite
 * lool waits for click 0.4.9 to be on ports
<didrocks> robru: around?
<didrocks> https://plus.google.com/hangouts/_/76bca9c02d41106488aa07d8aae1b40d8b6d09a4
<robru> didrocks, yep, just up
<fginther> Laney, looking
<Laney> fginther: mterry pushed another commit, probably will kick itself off now
<fginther> Laney, ack
<ogra_> rsalveti, will we get the last bits of the media stack over night ?
<rsalveti> ogra_: we hope so, in a few hours actually
<ogra_> ok
<rsalveti> we can dream, right?
<ogra_> haha
<ogra_> yeah
<ogra_> didrocks, ^^^
<didrocks> \o/
<fginther> sil2100, https://code.launchpad.net/~fginther/cupstream2distro-config/add-thumbnailer/+merge/188383
<fginther> sil2100, adds the thumbnailer which was just discussed
<robru> lool, ok, so it sounds like you are going to sping image 71 right now, and then wait some hours for me to land a few things, and then spin 72 after that?
<lool> robru: we're going to spin 71 and 72 immediately thereafter, then you can land stuff if you like
<lool> but need some testing before we can spin 71
<lool> and my phone is just screwed, gah, will take some time to fix
<robru> lool, hmm, didrocks has assigned me to land a few things for 72 ;-)
<didrocks> robru: yeah, try to land as much as you can for 72 (there are quite small things)
<lool> didrocks: for 73 I guess
<didrocks> robru: we can retarget for 73 if you don't finish them for 72
<lool> didrocks: where should we state the system-image .debs to test?
<robru> didrocks, ok, no worries then. I will begin landing now and if they land for 72 or not is fine
<lool> didrocks: I was thinking a block hint on it, + upload to -proposed would be in order, what do you think?
<lool> or we can do PPA
<didrocks> robru: looks good, maybe some stacks will need for rebuilding (like the apps one I guess)
<didrocks> lool: PPA maybe? It's not that long to build
<robru> didrocks, ugggggh, 79 test failures in app stack... fun
<lool> didrocks: with a ~ppa?
<lool> didrocks: slangasek can't participate in much system-image testing right now due to a power outage taking his wireless down
<didrocks> robru: yeah, please relaunch, the autopilot in the ppa was busted
<didrocks> lool: yeah, ~ppa
<didrocks> lool: argh, of course
<lool> ogra_, didrocks: Sorry will take me a while to test because I have to reflash; should be 10-15mn from now
<ogra_> lool, no hurry
<didrocks> lool: this gives time for robru ;)
<robru> didrocks, ok, i believe everything that has been asked of me is building... now we wait ;-) (err, read emails while waiting... :-)
<didrocks> robru: heh, thanks!
<didrocks> robru: do I miss anything? (I answered you by email)
<robru> didrocks, no, just miscommunication. it's fine i guess
<didrocks> robru: ah nice ;)
<robru> didrocks, oh, um, is manual publishing disabled? I ran indicator stack and it seems to have published on it's own (I just did a regular build run, it should not have published)
<robru> didrocks, http://10.97.0.1:8080/view/cu2d/view/Saucy/view/All/job/cu2d-indicators-saucy/ build 63 is green, i was expecting yellow
<lool> cjwatson: I'm getting this https://bugs.launchpad.net/ubuntu/+source/click/+bug/1233280 but perhaps there are image building fixes needed along 0.4.9?
<ubot5> Ubuntu bug 1233280 in click (Ubuntu) "Permission error while removing preinstalled click before installing any other click" [Undecided,New]
<lool> cjwatson: I mean, there is no /opt/click.u.c/.click in the image
<didrocks> robru: I guess indicator juts has nothing to build :)
<didrocks> and then publish
<didrocks> hum, no
<robru> didrocks, hummm, the latest commit from lp:indicator-keyboard did not show up in daily release ppa
<didrocks> there is this libubermetric
<cjwatson> lool: Huh, no, shouldn't be
<didrocks> robru: I think that Mirv messed with the file system maybe there is something wrong
<didrocks> let me look
<cjwatson> lool: Different traceback, I assume?
<lool> ralsina: Hmm I'm getting 404 when long-pressing on dropping-letters; I'm not sure whether it's a bug or just because we renamed it or something, would you mind passing this to the right folks (appstore or click scope I guess)?
<lool> cjwatson: yes, permission denied
<didrocks> robru: in fact the stack is running
<lool> cjwatson: can't remove it even after installing other clicks
<cjwatson> lool: Oh, sorry, that's a new bug
<didrocks> robru: however, 64 is a typo of mine
<robru> didrocks, yes, i just re-ran it now myself
<didrocks> robru: it's not indicator-keyboard, but ubuntu-keyboard
<didrocks> (fixed the spreadsheet)
<robru> didrocks, oh
<didrocks> sorry about that
<didrocks> just autotyping ;)
<didrocks> robru: it seems you are already rerunning the services stack
<robru> didrocks, i just did now that you told me to :-P
<didrocks> robru: ahah, you're fast :p
<cjwatson> lool: bah, right, <- idiot
<cjwatson> lool: can I upload a new click version that fixes just this?
<lool> cjwatson: yes please  :-)
<didrocks> ogra_: you will need to track that one before image 71 ^
<lool> didrocks ogra_: ^ I think this regresses removals, so waiting on this one for the image
<didrocks> lool: no worry!
<lool> ogra_, didrocks: Going for dinner
<didrocks> lool: enjoy
<cjwatson> lool: it'll be http://paste.ubuntu.com/6176317/
<cjwatson> after testing
<lool> cjwatson: ok
<cjwatson> (that's hard to read but it's mostly indentation changes - http://paste.ubuntu.com/6176321/ with diff -b)
<lool> it looked like it was either something like that, or another syscall ld_preload thing for removals, glad it's the former  :-)
 * ogra_ is happy to wait ... not on a race :)
<lool> wow getting an update in update manager
<cjwatson> Yep, that works
<cjwatson> lool: It's not a regression, I might note - I just didn't fix bug 1232066 hard enough in the last upload
<ubot5> bug 1232066 in click (Ubuntu) "click unregister on preinstalled app causes exception" [High,Fix released] https://launchpad.net/bugs/1232066
<cjwatson> lool: Oh, actually, you're right, it is a regression
<cjwatson> Maybe
<cjwatson> lool: Do you get the same traceback after installing other click packages?
<lool> cjwatson: can't easily tell
<lool> getting a pkcon error
<cjwatson> lool: You have a traceback in the bug though
<cjwatson> So try   pkcon remove 'com.ubuntu.sudoku;0.4.3;all;local:click'
<cjwatson> And then paste the traceback from that
<cjwatson> lool: ... any luck?  I have a fix, just would like to make sure I fully understand what's going wrong for you
<cjwatson> Oh, he said he was going for dinner.  I'll just upload then since it WFM
<cjwatson> lool: click 0.4.10 uploaded
<lool> cjwatson: just back from dinner
<cjwatson> You eat quickly
<lool> just a plate of spaghettis with bolognaisa
<lool> sorry, bolognase I guess
<lool> cjwatson: pkcon remove 'com.ubuntu.sudoku;0.4.3;all;local:click' worked
<cjwatson> OK, I don't know what the problem with "can't remove it even after installing other clicks" was then but hopefully this addresses it too
<bfiller> fginther|lunch: these are the MR's we have that are blocked by current autopilot/CI issues: https://docs.google.com/a/canonical.com/document/d/1u5rQCAshO3ZVfl61MKtw2RF_Y_BvE9AIcjMTNbGWrxA/edit#
<bfiller> fginther|lunch: please give me an update when these can be unblocked.
<lool> cjwatson: is it enough to rm -rf /opt/click.ubuntu.com/{*,.*} to get to the same state as a fresh image?
<lool> ogra_: will promote click-package stack
<lool> ogra_: Actually we can probably do better than what I had proposed for system-image
<cjwatson> lool: Might leave cruft around from hooks
<cjwatson> lool: Assuming correctly-written hooks, it should be OK if you reboot after doing that
<lool> ogra_: a) build now, b) upload system-image, c) build, d) build
<lool> test from c) to d)
<cjwatson> (Which has the effect of rerunning hooks)
<lool> ok
<cjwatson> lool: But
<lool> there is always a butt
<cjwatson> lool: Don't run the command you quoted!
<cjwatson> lool: .* expands to include ..
<lool> erf, ok, it was just for IRC
<cjwatson> rm -rf /opt/click.ubuntu.com/{*,.click}
<lool> interesting, zsh is being slightly more helpful than bash here in expanding .* to things starting with .
<lool> cjwatson: bah, unapproved
<lool> desktop seed
<lool> via pk plugin I guess
<lool> (click 0.4.10 approved by StÃ©phane)
<robru> lool, do we care about libusermetrics for today's images? i can't get it to build, don't understand the failure.
<ogra_> robru, make the committer fix it
<ogra_> and set it back to TODO
<robru> ogra_, yeah, there's already a bug
<ogra_> if it is broken it is broken ...
<lool> robru: isn't that already in the image?
<lool> robru: what's the issue?
<robru> lool, https://bugs.launchpad.net/libusermetrics/+bug/1233003
<ubot5> Ubuntu bug 1233003 in libusermetrics "Tests failing since Sep 27th" [Critical,Confirmed]
<robru> lool, there is an old one in the image. i'm  just asking if it's important to get it in
<lool> The following tests FAILED: 4 - usermetricsoutput-unit-tests (Failed)
<lool> robru: it's not particularly important
<robru> lool, ok, then i'll focus on other things ;-)
<lool> robru: it looks like the issue are that some tests trigger valgrind errors
<robru> lool, i don't know the first thing about valgrind. maybe you can work with pete-woods on resolving that? ;-)
<lool> robru: just point him at the failure log on i386
<robru> lool, well, he marked the bug as fixed even though it's not fixed, so...
<lool> cjwatson: new click is all fine, thanks
<robru> lool, ogra_: what is the best way to do a factory reset of an n7? Can phablet-flash be used to wipe the device? i want to clear all user settings and make it as "stock" and default as possible
<ogra_> phablet-flash ubuntu-system --channel saucy --no-backup
<robru> ogra_, thanks
<ogra_> (--no-backup is the "wipe" command)
<robru> ogra_, ah, it didn't show up in 'phablet-flash -h'
<ogra_> yeah, would be in phablet-flash ubuntu-system -h
<lool> you need the actual command to see all the --help options
<robru> ahhhh
<sil2100> fginther: ping!
<fginther> sil2100, hello
<sil2100> fginther: https://code.launchpad.net/~sil2100/cupstream2distro-config/onlinemusic_scope_add/+merge/188417 <- hello, could you take a look, approve and prepare the mergers for it? :)
<sil2100> fginther: thanks!
<fginther> sil2100, approved
<sil2100> fginther: awesome! *hugs*
<sil2100> See you tomorrow guys
<fginther> sil2100, later
<lool> ogra_: Ok, gtg; could you check for click 0.4.10 to be in saucy in rmadison then build an image ?
<ogra_> indeed
<lool> ogra_: ty!
<robru> lool, ogra_: hummm, ok, so one of my tasks is to release libunity and unity-scope-home. but unity stack is blocked by 43(!) failing autopilot tests (but the tests are on unity, not libunity or the scope). do you think it's safe to manually copy those two packages from the daily PPA to distro? or should we just punt on that? I reported a bug to unity already
<robru> similar situation with mediaplayer_app AP tests holding back camera-app release.
<ogra_> build 71 running
<ogra_> robru, sorry, i have not much clue about the CI infrastructure, cant give you a hint here
<robru> ogra_, ok, well then I have no choice but to not release this then. bug has been filed, will ping appropriate upstreams shortly.
<ogra_> probably lool can help later
<ogra_> he said he'd be back
<robru> ogra_, let me know when image 72 is done, i'll help test the image upgrades too
<fginther> bfiller, the otto tests are working again after reverting to an older autopilot per didrocks advice. notes, gallery, camera and webbrowser have all passed.
<fginther> bfiller, will retrigger recent failing jobs
<ogra_> robru, yeah, thats still hours away
<robru> ogra_, ok, great. I EOD in 6 hours ;-)
<robru> fginther, do you think that'll help with mediaplayer-app, as well? https://bugs.launchpad.net/mediaplayer-app/+bug/1231418
<ubot5> Ubuntu bug 1231418 in mediaplayer-app "TestPlayerWithVideo.test_time_display_behavior seems to fail consistently" [Critical,Confirmed]
<fginther> robru, nope, that test was already executed with the autopilot 1.3.1+13.10.20130918-0ubuntu1
<robru> buh. ok thx
<bfiller> fginther: please retrigger all the MR's found in that sheet
<fginther> bfiller, ack
<cjwatson> lool: new click> great
<kgunn> fginther: just one more time...thanks for moving the mir CI amd tests to the dedicated host machines, that has been a huge plus for us!!!
<kgunn> its been damn smooth ever since
<fginther> kgunn, you're welcome. I was I could have similar results for eveything else
<kgunn> ;)
<cjwatson> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-saucy-amd64/70/console is transient.  Can somebody please retry?
<cjwatson> (from https://code.launchpad.net/~cjwatson/friends-app/dh-python2/+merge/188338)
<fginther> cjwatson, on it
<cjwatson> thanks
<robru> fginther, do you have any idea why jenkins would fail with a hash sum mismatch here? https://code.launchpad.net/~cjwatson/friends-app/dh-python2/+merge/188338
<cjwatson> robru: that happens occasionally even on the primary archive build daemons due to bad timing
<cjwatson> it's a "try again" thing
<robru> cjwatson, ok, will do
<cjwatson> we cycle the archive so frequently that the odds of happening to hit it in the middle of an update aren't as small as you might hope
<robru> heh, fginther beat me to it
<fginther> cjwatson, curious, would it be safe if the job itself immediately did a retry of the apt-get operation?
<cjwatson> and even worse for PPAs
<robru> cjwatson, what do you mean by 'cycle'? are you just referring to the churn of updated packages?
<cjwatson> fginther: probably, yes, but you would want to do that only on certain types of failures and have a limit to avoid infloop
<cjwatson> robru: I mean each publisher run
<fginther> cjwatson, I would likely cap it at 3-5 retries
<robru> ah
<cjwatson> the indexes for a given archive are unfortunately spread over multiple files so it's possible to get an inconsistent view
<cjwatson> we've talked about fixing it, but time ...
<fginther> cjwatson, I see the problem several times a day now. followed by having to retrigger a job that took 2 hours to make it through CI and it becomes a bit of a headache...
<cjwatson> fginther: the PPA publisher runs every 10 minutes or so in practice if there are changes
<cjwatson> so the odds of hitting it are probably non-negligible, indeed
<bfiller> robru: ping
<bfiller> fginther: is jenkins down?
<fginther> bfiller, not the one I'm looking at
<renato> fginther, could you take a look on this MR: https://code.launchpad.net/~renatofilho/mediaplayer-app/fix-1231418/+merge/188433
<fginther> bfiller, upstream merger and public jenkins are responding for me
<bfiller> fginther: waiting on this MR too: https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-1213046/+merge/186223
<fginther> renato, your MP is at the front of the build queue
<renato> fginther, thanks
<bfiller> fginther: many of the MR's in the sheet are still not working
<bfiller> fginther: in fact don't see any that passed yet
<bfiller> fginther: this one approved but never merged: https://code.launchpad.net/~ted/gallery-app/single-instance/+merge/186611
<bfiller> all the browser ones still failing tests
<lool> heya
<fginther> bfiller, one moment
<robru> bfiller, pong.
<bfiller> robru: please see my email re: ubuntu-keyboard
<bfiller> robru: it needs a new release as the one you guys did today has issues
<robru> bfiller, ah, ok. sure thing.
<robru> bfiller, hummm, some miscommunication it seems. this very morning didier told me that i needed to get a release of ubuntu-keyboard out the door ;-)
<bfiller> robru: I know, not sure why exactly. I never requested one. I think it's because he reverted one last week
<robru> bfiller, yeah. the asks page just says that he's reverting the revert.
<bfiller> robru: I think that's right, but in the meantime we've added new things and unfortunately something was broken.. but my MR should fix it
<robru> bfiller, ok, no worries. as soon as jenkins lands it in trunk, I will kick off a new release build.
<bfiller> robru: thank you
<robru> bfiller, you're welcome. I just subscribed to the MP so I should get notified as soon as it's ready
<fginther> bfiller, do you have time for a hangout?
<bfiller> fginther: yes
<plars> camera, address-book, and clock seem to be crashing: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4494/
<plars> on mako, just camera crashed
<plars> ah, it's url-dispatcher and camera actually
<plars> lool, bfiller: ^ any idea on camera? I don't see an update to camera-app in 71, nor to url-dispatcher (but the url-dispatcher one doesn't seem to always happen)
<lool> plars: can you reproduce the camera crash?
<lool> plars: I'd try downgrading qtvideo-node
<plars> lool: likely yes - it happened on both mako and maguro, along with lots of failures
<lool> address-book is url-dispatcher
 * lool upgrades to 71
<plars> lool: qtvideo-node didn't seem to upgrade in 71 either
<lool> plars: that was 70 though
<bfiller> plars: no idea, we haven't changed anything that would cause that
<bfiller> could be qtvideo-node
<plars> bfiller: something either broke it in 71, or it's just random enough that we got (un)lucky this time but not in 70
<mfisch> infographics broke in 71 for sure
<lool> plars: so the error is:
<lool> #2  0x401179ba in g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR,  format=format@entry=0xbf18 "Unable to connect to D-Bus: %s", args=...,  args@entry=...) at /build/buildd/glib2.0-2.38.0/./glib/gmessages.c:989
<lool> from the url-dispatcher crash in addressbok
<lool> plars: this looks fishy; either dbus is going away because everything is going away (session), or there is some bad upstart deps somewhere
<lool> url-dispatcher starts on started dbus
<lool> so I'd rather vote on the former
<plars> lool: that seems consistent with the log here: https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-maguro-smoke-ubuntu-clock-app-autopilot/92/artifact/clientlogs/url-dispatcher.log/*view*/
<plars> lool: I'll see if I can reproduce it locally while I'm watching
<lool> plars: just to finish exploiting the crash file: the message is actually "Could not connect: Connection refused", and the reason it's crashing is because it's using g_error which will cause a crash dump
<lool> I mean, it basically causes an abort to get a backtrace
 * lool => bed
<plars> the camera one is easily reproducible for me, the url-dispatcher one is harder to hit it seems
<rsalveti> lool: ogra_: will update the seeds and spin a new image
<robru> fginther, https://code.launchpad.net/~bfiller/ubuntu-keyboard/disable-predictive-text/+merge/188448 humm, no jenkins after 2hrs, can you take a look? thx
#ubuntu-ci-eng 2013-10-01
<fginther> robru, looks like it merged about an hour ago. The build machines are still under load
<robru> fginther, ok, thanks
<plars>  balloons have you noticed that calendar seems to just fail on maguro for the most part? Not saying that makes any sense, just an observation
<plars> balloons: I mean, it does fail on mako too, but not nearly as much. On maguro it's really hard to make it pass though.  maybe something timing sensitive?
<didrocks> Mirv: hey, can you try the camera_app AP tests? (as we have those crashers) to see if you can reproduce with latest image
<didrocks> and then latest image + camera-app in distro?
<didrocks> that will help to have first hints for the meeting
<didrocks> (now that you published libunity, thanks again! ;))
<Mirv> didrocks: ok, I ran them once today before publishing the new camera-app, but I'll try some complete reflash + rety.
<didrocks> Mirv: great, thanks!
<vila> didrocks: so, the DNS has been migrated
<didrocks> vila: great news! Let's cross fingers now :)
<vila> * retoaded announces that he has switched all DHCP services over to the new DNS/DHCP server(s). Networking will need to be restarted on just about everything on the 10.97.2.0/24 network for the system to pick up their new DHCP leases and DNS servers unless you want to wait for the 24 hour DHCP renewal to take care of it.
<didrocks> vila: next topic was those autopilot machines for which the nodes are going down randomly
<vila> ^ that was yesterday evening
<vila> hehe
<didrocks> (again today, the nvidia machine)
<didrocks> retoaded: I guess I have the next topic (we already discussed that) for you ^
<didrocks> something to monitor those machines
<didrocks> reboot (electrically) if we can't ssh to them for 10 minutes
<didrocks> and restart the jenkins node if down
<didrocks> otherwise, rocking on the DHCP! :)
<vila> didrocks: http://10.97.2.10:8080/job/webapps-autopilot-next-daily/306/label=quantal/testReport/webapps.tests.test_hud/HudTests/test_webappicon_firefox_/
<vila> this is a selenium failure I fixed for sst, the way webapps-tests defines browser launch is way too optimistic, not sure who I should talk to about that
<didrocks> rsalveti: great work! you should go to bed now :)
<didrocks> vila: I think this is dbarth's team
<didrocks> (vvruiz should be the one in charge of those tests AFAIK)
<vila> vrruiz_: ping
<vrruiz_> vila: pong
<vila> vrruiz_:  http://10.97.2.10:8080/job/webapps-autopilot-next-daily/306/label=quantal/testReport/webapps.tests.test_hud/HudTests/test_webappicon_firefox_/
<vila> vrruiz_: this is a spurious selenium failure
 * vila searches relevant revision in sst
<vila> vrruiz_: http://bazaar.launchpad.net/~canonical-isd-qa/selenium-simple-test/trunk/revision/425
<vila> vrruiz_: in a nutshell, building a selenium driver can (and will) fail at times, you have to retry
<vrruiz_> Hmm
<vila> vrruiz_: main point of interest in this huge revision is in src/sst/browsers.py (but src/sst/cases.py is also relevant)
<vila> vrruiz_: I realize you can't easily reuse that code but the feature you need is there :-/
<vila> vrruiz_: mostly I wanted you to be aware that the failure in the url above won't magically disappear
<vrruiz_> vila: One question
<vila> until *you* do something about it
<vila> sure
<vrruiz_> vila: Do you know which Launchpad project/branch is that job using?
<vila> vrruiz_: lp:webapps-tests ?
<vila> vrruiz_: at least that's where I found the overoptimistic line
<vila> vrruiz_: http://bazaar.launchpad.net/~vrruiz/webapps-tests/trunk/view/head:/autopilot/webapps/emulators/browser.py#L18
<vila> vrruiz_: i.e. just building a driver without catching the exception and retrying as in src/sst/cases.py roughly (but sst uses a modified driver too)
<vrruiz_> Ah, I see
<vila> vrruiz_: oh, indeed, the trunk for that is yours ;)
<vila> vrruiz_: I didn't dig from there so may be you can just use sst and be done
<vrruiz_> Someone should package sst and put it in universe :)
<vrruiz_> (or main ;)
<vila> vrruiz_: it is packaged but not put in universe (my packaging fu is weak :-/)
<vrruiz_> Yeah, elopio told me there is a PPA
<vila> https://launchpad.net/~vila/+archive/selenium/
<vila> vrruiz_: and (basic) instructions on how to update it in sst: doc/packaging.rst
<vila> vrruiz_: and (basic) instructions on how to update it in sst: docs/packaging.rst
<vrruiz_> Thanks, I will take a look
<vila> vrruiz_: ping the qa team about that maybe, elopio and cgoldberg may want to address that now (I pushed for that but didn't go further than the ppa)
<vrruiz_> Yup
<didrocks> Mirv: I tried here and I don't have any failure, is it the same for you?
<didrocks> (camera-app)
<vila> didrocks: http://10.97.2.10:8080/job/gallery-app-saucy-i386-ci/352/console rings a bell ?
<didrocks> vila: I would say no more loop device available on the machine
<didrocks> which makes pbuilder going crazy and can't unmount others
<vila> wow, lucky it rang a bell, would never have suspected a lack of device leading to unmount failing 8-)
<didrocks> vila: it's a crazy chain of cause/consequence when I looked at it ;)
<vila> didrocks: /var/cache/pbuilder/build also contains stuff as old as March 2013
<vila> didrocks: on kinnara that is
 * ogra_ doesnt understand the camera-app issues
<vila> fginther: can use your help ^
<didrocks> ogra_: me neither, I asked Mirv to look at it (be he doesn't seem around)
<didrocks> ogra_: I tried locally with image 73, all good
<didrocks> (multiple times)
<Mirv> didrocks: hi
<didrocks> hey Mirv!
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20130930.changes
<Mirv> didrocks: yep, no failures, have tried twice with both older and newer camera-app
<ogra_> it wasnt updated either
<Mirv> fresh -b flashing
<didrocks> Mirv: upgrade here, but same :/
<fginther> vila, woah
<didrocks> ogra_: yeah, nothing that I can spot on
<vila> fginther: errk, you're here ! OMG, shouldn't you be sleeping ???
<ogra_> hmm, pulse was updated
<lool> lots of landed over night  :-)
<ogra_> lool, lots of broke over night :(
<fginther> vila, yes
<didrocks> ogra_: well, we do have that one locally as wellâ¦
<vila> fginther: http://10.97.2.10:8080/job/gallery-app-saucy-i386-ci/352/console can't we just kill it ? I suspect it will never get out of that loop
<vila> fginther: but I'm still hesitant to kill jobs without someone confirming ;)
<vila> fginther: http://10.97.2.10:8080/computer/kinnara/ seems healthy otherwise (I've just a couple of other jobs and they progress)
<didrocks> ogra_: can you update as well and tell us?
<didrocks> ogra_: if we are 3 with all tests passingâ¦
<fginther> vila, yes, it's in a bad place, the job will be timed out after two hours, but no reason to wait that long here
<vila> fginther: ha great, where can I see that timeout ?
<ogra_> didrocks, takes a while, i only have 2MBit here ... gimme 30min
<vila> fginther: no, stop, go to bed, I don't want to retain you here ;)
<didrocks> ogra_: still 300 MBit here (well, less as I'm connected through wifi to my router, but I won't complain :p)
<ogra_> didrocks, there is a .crash file in the tests
<ogra_> did you check /var/crash ?
<fginther> vila, alight, I go back to sleep now :-)
<vila> fginther: job killed, will monitor kinnara a bit, have nice dreams ;)
<didrocks> ogra_: yeah, I don't have any crash here
<didrocks> ogra_: but let's give that to upstream
<didrocks> ogra_: image 74? do you know why?
<didrocks> with no packaging changesâ¦
<ogra_> why what ?
<didrocks> why an image 74?
<didrocks> 71, 72, 73 I can understand
<ogra_> dunno, i didnt build it
<didrocks> but why this 74? (just appeared)
<ogra_> lool, yours ? ^^^
<didrocks> ogra_: this is not a bug, right? http://people.canonical.com/~ogra/touch-image-stats/20131001.2.changes
<didrocks> it's really like, there is nothingâ¦
<ogra_> didrocks, yeah, there are only 2h between the two builds
<didrocks> ok, /me sed -i s/74/75/ on the spreadsheet
<didrocks> annoying we don't know who do builds
<didrocks> 2 or 3 for system-image ok
<didrocks> but we shouldn't do more :p
<ogra_> heh, we should do a lot more imho :)
 * ogra_ would like hourly builds 
<ogra_> automated ones
<didrocks> ogra_: well, it's harder to track, I spend my time updating the spreadsheet with build numbers
<didrocks> so if we do that, we need more automation for all the tracking
<ogra_> but that would mean that the build *and* the full tests would have to finish in under 1h
<ogra_> oh, indeed
<ogra_> the spreadsheet doesnt scale
<ogra_> the point is, if you could automate all this at such a fine grained manner, you will be ablet to have one image per change automatically
<ogra_> that means you will spot any regression immediately and will know exactly where it come from
<ogra_> *comes
<ogra_> didrocks, i would replace the spreadsheet with an LP form where people put in everything for one changeset to create a ticket and the "lander" has a button called "do testbuild" that runs the whole process of building, publishing, image creation and a full testsuite to show you the results ... if they are good, the system publishes them with one click from you
<didrocks> argh, sil2100 won't be able to connect :/
<didrocks> ogra_: yeah, we are more or less inline on that
<didrocks> having feature landing
<didrocks> instead of trunk landing
<didrocks> anyway, let's see with what we have ;)
<didrocks> Mirv: ok, so as sil2100 isn't around, do you mind taking the Mir request?
<didrocks> Mirv: landing #52
<lool> nope, I didn't build that image
<ogra_> weird
<lool> did someone launch in the build in the morning?
<ogra_> apparently
<lool> Cause Steve L still had one running not too long ago, but he finished testing ~1h ago, however if someone had launched another build, it probably started just while Steve's finished
<ogra_> i see rsalveti spun 72
<ogra_> oh why did steve run a build ?
<lool> Steve did 73 and 74
<lool> he wanted to test upgrades with system-image
<ogra_> ah
<ogra_> well, then we have identified them all
<lool> it's what I suggested yesterday evening actually, except it took the whole night to complete landing and testing of this
<ogra_> yeah
<lool> (this timezone thing is awesome0
<ogra_> i went to bed then it FTBFS the first time
<ogra_> lool, does it work for you ?
<ogra_> didrocks claims it doesnt
<ogra_> (i'm still flashing here, maguro sucks)
<lool> what doesn't work?
<ogra_> TZ selection
<lool> haha
<ogra_> oh
<lool> I just meant that it was great for US folks to be in another TZ to finish the work while we sleep
<ogra_> yeah, got it now
<lool> but I haven't tested the touch TZ support  :-)
<ogra_> to much timezines in my head today
<ogra_> *zones
<lool> so what do we know about the camera-app crashes?
<ogra_> exactly nothing
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20130930.changes
<ogra_> thats the change set after which it started
<didrocks> lool: I sent an email to olivier, ugo and bill
<didrocks> discussing right now on ubuntu-touch
<ogra_> didrocks, hmm are you sure we're not seeing an UI issue wrt timezone selection ? i cant even pick it here
<ogra_> seb128, ^^^
<ogra_> is that supposed to work ?
<seb128> ogra_, if you type in the text entry you should get locations
<didrocks> I get location
<didrocks> I click on one
<ogra_> seb128, i do, but tapping a location does nothinng
<didrocks> and nothing
<Mirv> didrocks: ok, there seems to be a lot to test, maybe sil2100 can then take some of the AP:s if he arrives and I've still tests to run
<seb128> didrocks, ogra_: btw, whoever landed that content-hub update without updating setting probably regressed background selection again :/
<didrocks> Mirv: right, but this is prio #1 for us, so can you start on those? maybe then sil2100 can pick up when he arrives
<didrocks> seb128: it's ken I guess
<seb128> didrocks, ogra_: that's likely https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1227520/comments/44
<ubot5> Ubuntu bug 1227520 in apparmor (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,In progress]
<didrocks> seb128: he didn't ask
<didrocks> nothing written
<didrocks> so please check with him
<Mirv> didrocks: yep
<seb128> didrocks, no, ken and I agreed yesterday that I would do the organize the landings with you today
<didrocks> seb128: someone published the stack without any requests
<seb128> didrocks, he said he would land the content-hub commit in trunk and a gallery-app rebuild, but those shouldn't have been uploaded
<seb128> didrocks, could be robru?
<didrocks> maybe he miscommunicated with robru and he Robert landed it?
<seb128> I'm pretty confident Ken didn't do it
<seb128> we had a 15 min discussion on how to land settings content-hub and gallery-app synced
<didrocks> yeah, but what I told is that he maybe discussed about it with robru
<ogra_> seb128, well, i know that apparmor is broken, but is the UI supposed to work ? this zero feedback is weird
<didrocks> and Robert misunderstood
<seb128> ogra_, it's supposed to show as selected the timezone, try on your desktop
<ogra_> heh, my desktop runs precise :)
<ogra_> i belive you ;)
<seb128> ogra_, https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1232114
<ubot5> Ubuntu bug 1232114 in ubuntu-system-settings (Ubuntu) "Adding timezone behviour is odd" [Low,New]
<seb128> ogra_, that's a bug about the lack of feedback/current behaviour
<ogra_> yeah
<ogra_> oh, wait !
<ogra_> it sets the timezone right
<seb128> so?
 * ogra_ sees "Europe/Berlin UTC+0"
<seb128> haha
<seb128> \o/
<ogra_> and nothing in any logs :(
<seb128> ogra_, it should show Berlin in orange in the list
<seb128> in the UI
<ogra_> well, i used my hometown
<ogra_> not berlin
<ogra_> and it shows it highlighted in orange now
<seb128> ogra_, it should show as orange all the entries matching your tz
<ogra_> that doesnt fix the UTC offset though
<ogra_> it does
<seb128> ?
<seb128> what offset?
<ogra_> but my clock is still wrong indeed
<ogra_> UTC+0
<seb128> was there any time change?
<ogra_> unless berlin moved to london recently, thats wrong :)
<seb128> we had bugs with clock in the past where the new time would only be picked on refresh
<ogra_> no i freshly flashed
<seb128> e.g the new minute
<ogra_> with a complete re-bootstrapping
<seb128> that's not what I meant
<ogra_> i flashed freshly, and then went to the timezone selection
<seb128> I meant, did you wait a minute, in case the indicator is just too stupid to refresh the time during the minute (where the UI is not supposed to changed)
<ogra_> the TZ selector says UTC+0
<ogra_> i doubt it will adjust anything
<seb128> what does "time" says in adb?
<ogra_> root@ubuntu-phablet:/# date
<ogra_> Tue Oct  1 08:24:45 UTC 2013
<seb128> shrug
<ogra_> (assuming you meant date)
<seb128> yes
<seb128> is /etc/timezone having the right content?
<lool> so I'm going to revert to 73 and test an upgrade to 74
<Laney> pitti posted a comment in the bug saying there were apparmor problems still
<ogra_> root@ubuntu-phablet:/# cat /etc/timezone
<ogra_> cat: /etc/timezone: No such file or directory
<ogra_> aha
<seb128> :-(
<seb128> Laney, yeah, I mentioned that before
<seb128> <seb128> didrocks, ogra_: that's likely https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1227520/comments/44
<Laney> oh ok
<ubot5> Ubuntu bug 1227520 in apparmor (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,In progress]
<ogra_> root@ubuntu-phablet:/# ls /etc/writable/
<ogra_> root@ubuntu-phablet:/#
<Laney> doh
<ogra_> :(
<seb128> let me update here/try
<Laney> is it right in the image?
<Laney> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/ubuntu-touch/latest/livecd-20131001.2-armhf.out says good things
<ogra_> Laney, it does good things ...
 * ogra_ checks livecd-rootfs code
<seb128> ok, let's move that to -touch with pitti
<seb128> on other news, robru's landing regressed the background selection
<seb128> we need to land
<seb128> - a rebuild of gallery-arpp
<seb128> - one commit to ubuntu-system-settings
<seb128> - the new ubuntu-system-settings to saucy then
<ogra_> Laney, i suspect the code doesnt cd into the right place when linking and moving
<Mirv> psivaa: ok so if you have time to also run mir testing, I tried to do mir testing instructions (comments welcome) at http://pastebin.ubuntu.com/6178812/
<Mirv> after, those running the actual tests
<psivaa> Mirv: ack, will do
<Mirv> ogra_: does that pastebin look correct to you? ^
<Mirv> psivaa: thanks!
<psivaa> Mirv: yw
<ogra_> Mirv, touch .display-mir needs to happen in /home/phablet
<ogra_> beyond that, looks ok to me ... make sure to test unity8 last, else the tests behave weird
<Mirv> ogra_: thanks
<Mirv> psivaa: hmm, first things first, can you check with top if you also get 100% CPU usage of unity8 under mir?
<psivaa> Mirv: just doing a fresh flashing, ill check once that's done :)
<Mirv> psivaa: yeah, there's quite a log to flash/install/etc. I just noted that myself.
<Mirv> hmm now after another reboot it calmed down, weird
<Mirv> didrocks: autopilot does not seem to work for me under mir. nothing happens, the autopilot process is there but doesn't do anything.
<didrocks> psivaa: same for you? ^
<Mirv> I've tried -n unity8, camera_app etc, multiple reboots
<ogra_> didrocks, so with 74 i cant get the camera-app to start at all on maguro ... just FYI
<psivaa> didrocks: just flashing.. not yet finished :)
<didrocks> ogra_: hum, we can on mako here
<seb128> so, how do I get a gallery-app update to land?
<seb128> that seems to be enough to make the background selection works again
<seb128> (it needs to be rebuilt with the new content-hub)
<didrocks> Mirv: ok, but there is no regression visible?
<ogra_> didrocks, with a fresh --no-backup flash ?
<didrocks> Mirv: if you play with it?
<didrocks> ogra_: yeah
<ogra_> weird
<didrocks> ogra_: but on majo
<didrocks> mako*
<ogra_> right
<didrocks> same for lool
<didrocks> ogra_: can you try again (after waiting the session to start, like 1 min)
<ogra_> yeah, let me reboot
<didrocks> it seems to be linked to usermetrics
<didrocks> seb128:  you need to check with bfiller, he told me to not release apps without his green flag
<didrocks> seb128: and I see no landing ask from him on this
<didrocks> (it seems they don't have an always releasable trunk)
<seb128> didrocks, what about doing a direct "no change rebuild" of gallery-app to saucy?
<didrocks> seb128: once you get his ack, I'll get that in priority
<didrocks> seb128: fine with me if that's really enough and you backport the changelog upstream
<ogra_> didrocks, nope ... reboot and 1min wait before doing anything didnt change it
<didrocks> urgh
<seb128> didrocks, let me double check, I get the gallery-app from the daily-ppa, but ken told me a rebuild was the key there
<ogra_> i get a white screen
<ogra_> thats all
<seb128> didrocks, coming back to you about that in a bit
<didrocks> ogra_: let me reflash
<didrocks> seb128: thanks!
<seb128> didrocks, yw ;-)
<Mirv> didrocks: I don't have a reference to compare, but it seems to work, yeah. no flickering for example.
<didrocks> Mirv: let's wait for psivaa's result, and please email with those results kgunn
<Mirv> didrocks: but I'm seeing this 100% CPU usage of the unity8 process (not always, but for example on this boot)
<didrocks> yeah, when the screen is blank
<didrocks> this is a known thing
<Mirv> ok
<didrocks> expected to still exist
<Mirv> didrocks: also otherwise
<Mirv> image visible, idling on eg Applications screen, 100% CPU
<didrocks> interesting
<didrocks> Mirv: can you detail those in the email?
<didrocks> (please CC me and olli)
<Mirv> didrocks: ok. after psivaa has some additions to the report.
<didrocks> yep
<ogra_> tested with Mir, doesnt work either
<ogra_> (though i get a black screen now ... )
<didrocks> ogra_: AP or camera app?
<ogra_> the app
<ogra_> i wanted to check wallpaper settings
<ogra_> not even the cam
<ogra_> :)
<didrocks> ahah
<seb128> ogra_, wallpaper settings are not working again (thanks to robru's landing of content-hub)
<ogra_> seb128, yeah, i wanted to verifyx that ... but am not able to take a picture :)
<seb128> ogra_, just copy stuff to ~/Images over mtp
<seb128> that's what I do
<seb128> ups
<ogra_> well, i usually take a closeup pic of something :)
<seb128> ~/Pictures I mean
<ogra_> that way you test both, camera and wallpaper settings at the same time :)
<seb128> right
<ogra_> and its funny trying to find structures to make nice wallpapers from
<vila> ogra_: verifyx, nice one, you fix stuff as you verify it works, you just rock ;)
<ogra_> :D
<psivaa> Mirv: 1. i do not get 100% CPU for unity8 under Mir on maguro
<psivaa> Mirv: 2. unity8 AP test does not pregress.. like you said above
<psivaa> Mirv: the screen was blank when that happened and there was no response to the power button press
<psivaa> Mirv: the same thing even after rebooting (removing the battery etc) for other AP tests
<psivaa> didrocks: Mirv: i see _usr_lib_arm-linux-gnueabihf_hud_hud-service.32011.crash and _usr_bin_maliit-server.32011.crash on reboots
<didrocks> psivaa: ok, anyway, as long as we don't have AP tests running
<didrocks> let's not go further
<didrocks> we can publish Mir, it's not enabled by default
<didrocks> Mirv: mind doing (that + email?)
<psivaa> didrocks: ack
<didrocks> psivaa: sounds reasonable to you?
<didrocks> ok ;)
<ogra_> didrocks, the mediaplayer breakage was expected btw (just seeing your mail)
<ogra_> didrocks, the tests were supposed to be off though
<psivaa> didrocks: Mirv: just to make sure, i disabled Mir (by deleting .display-mir) and then run AP tests and that's working fine
<didrocks> ogra_: no, it's another issue
<didrocks> ogra_: like the app can't start
<ogra_> oh
<didrocks> (see, crashing in setup())
<didrocks> ogra_: normally, just 2 tests are disabled
<didrocks> not all :)
<didrocks> psivaa: \o/
<didrocks> psivaa: thanks for confirming
<ogra_> well, everything that uses the scene selector and thumbnails afaik
<didrocks> psivaa: can you install Mir on your desktop and reboot as well?
<didrocks> psivaa: so that we are all sured
<didrocks> ogra_: right, so 2 ;)
<didrocks> ogra_: but it's crashing in setup(), when trying to launch the app
<psivaa> didrocks: ack, will do
<didrocks> I bet it's the same issue than camera-app
<didrocks> psivaa: thanks!
<psivaa> didrocks: yw
<seb128> didrocks, https://launchpad.net/ubuntu/+source/gallery-app/0.0.67+13.10.20130924.1-0ubuntu2 and https://code.launchpad.net/~seb128/gallery-app/backport-saucy-upload/+merge/188539
<didrocks> seb128: rocking!
<seb128> ;-)
<seb128> ogra_, ^ that should give us back working background selector
<ogra_> awesome !
<ogra_> now if i could take a pic to use as background that would be even more awesome *g*
<Laney> use one of the lovely stock wallpapers we ship
<Mirv> psivaa: ok, thanks for the report and the fact that you have maguro, maybe the 100% CPU happens only on mako
<seb128> Laney, can't do that, the picker only picks from the gallery ... we should probably add those to the gallery by default though
<Laney> if you copy them then they appear in the gallery
<psivaa> Mirv: yea possibly
<seb128> right
<seb128> but it would be nice to have some content in the gallery by default ;-)
<Laney> yes
<Laney> I don't think the wallpapers are even installed yet though
<Mirv> didrocks: doh, the new tick just started, I'm uncertain whether cancelling is ok when prepare job is already running?
<Mirv> it won't pick up any new changes though, as there are none
<Mirv> seb128: I agree, like on desktop the wallpapers package
<didrocks> Mirv: is it wait on stack?
<Mirv> didrocks: no the mir is the first one to build so it's doing that
<didrocks> ah ok
<didrocks> Mirv: if there is no new content, just install it on your desktop quickly and ensuring it's booting
<didrocks> no need for further changes
<Mirv> but it's just a rebuild so I guess I can wait a bit and then publish the rebuild
<Mirv> didrocks: ok
<Mirv> didrocks: with publishing mir do you mean just mir or also unity-system-compositor, or also unity-mir from unity8 stack?
<didrocks> Mirv: there is no ABI break, right?
<Mirv> didrocks: no
<didrocks> so mir + unity-mir (the 2 you tested, right?)
<Mirv> didrocks: right, that's what I thought, the ones tested exactly and nothing else
<didrocks> perfect then
<didrocks> no need for u-s-c
<Mirv> just checking since I haven't done that many mir releases
<didrocks> yeah ;)
<didrocks> Mirv: did you send an email/point me to a bug for Mir not working with AP tests?
<psivaa> didrocks: Mirv: so on desktop, just installed Mir (did not manually enable though) and it works fine
<didrocks> phew!
<didrocks> thanks psivaa ;)
<Mirv> didrocks: writing ATM
<Mirv> didrocks: do you want a bug filed?
<didrocks> Mirv: probably yeah
<didrocks> with the version of the packages that were tested
<Mirv> psivaa: thanks! I also upgraded, but I'm now waiting for the rebuild to finish.
<psivaa> Mirv: ack
<didrocks> Mirv: great email
<Mirv> didrocks: thanks
<Mirv> didrocks: hrm, the i386 build seems quite stuck https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5065483
<didrocks> Mirv: maybe kill it and relaunch the build right away?
 * didrocks tries
<didrocks> Mirv: ok, retried
<didrocks> Mirv: if you are faster than cu2d to notice it, there is no need to do anything then ;)
<Mirv> didrocks: ok, thanks.
<didrocks> let's cross fingers
<Mirv> cool, cu2d refreshed, it didn't notice anything ("still building")
<didrocks> heh ;)
<didrocks> Mirv: successfully built!
<Mirv> didrocks: yes, just publishing
<Mirv> didrocks: unity-mir would tell about packaging changes if the publish job would be at that state, can you ack debian/control at http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/94?
<didrocks> Mirv: sounds good
<Mirv> didrocks: for future runs https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/libunity-mir1_depends_on_libupstart-app-launch1/+merge/188560
<didrocks> Mirv: approved
<Mirv> and deployed, and both mir + unity8 published before that
<didrocks> sweet
 * didrocks goes for some exercise now
<fginther> morning
<didrocks> Mirv: still around?
<plars> bfiller: I saw some keyboard stuff landed again, but the autopilot tests still don't seem to work. Are those pieces going to go back in at some point?
<bfiller> plars: they are back in
<bfiller> plars: what failures are you getting?
<plars> bfiller: dbus introspection problems it seems, I am stoping maliit-server and restarting with 'sudo -iu phablet bash -ic "initctl set-env QT_TESTABILITY=1 && start maliit-server"'
<plars> bfiller: one sec, will pastebin
<plars> http://paste.ubuntu.com/6179730/
<sergiusens> doanac, plars how did I install utah again?
<plars> sergiusens: on your host system I hope?
<sergiusens> plars, yeah, doanac gave me something to test and complains about missing utah
<plars> sergiusens: ppa:utah/stable - then install utah and utah-client
<sergiusens> ty
<fginther> bfiller, anything looking better today? Looks like gallery-app is still hitting one or two failures per MP
<ogra_> fginther, ignore image 71-74
<ogra_> they all have broken filesystem setups
<fginther> ogra_, ack
<plars> ogra_: could that have something to do with the other odd failures we started seeing like camera and url-dispatcher crashes?
<ogra_> yes
<ogra_> it is causing them
<lool> plars: pretty likel
<lool> likely
<fginther> ogra_, should I just roll back to saucy channel for now?
<ogra_> yeah
<fginther> ogra_, thanks
<ogra_> or wait for next image
<fginther> ogra_, if these are causing odd failures, I'd prefer to roll back instead of waiting
<bfiller> fginther: things looking a lot better today. thank you for all of your help. I'll keep you posted if there are specific MR's that we want to selectively re-trigger
<bfiller> plars: looked at your pastebin. you have to start maliit-server with "maliit-server -testability" - looks like this iniitctrl command doesn't set it correctly
<thostr_> do we already have an image 75?
<bfiller> plars: veebers should be able to tell you about using initctrl and whether that is expected to work or not
<lool> thostr_: no
<plars> bfiller: ok, when I checked before I thought we decided that it was correct, but I don't think it was veebers I talked to
<plars> bfiller: I'll try to sync up with him when his daytime rolls around
<bfiller> plars: I've only ever tried it with the -testability flag and it works with that
<plars> bfiller: you just launched it by hand, without upstart?
<bfiller> plars: correct
<bfiller> plars: or I guess you can modify the upstart job to add the -testability flag to the exec
<bfiller> that should work as well for testing
<plars> bfiller: heh, it doesn't seem to like that at all
<plars> bfiller: http://paste.ubuntu.com/6180010/
<bfiller> plars: I see that too but that makes it work
<bfiller> weird
<plars> strange, I'll give it a try though
<Mirv> didrocks: starting to be, for the weekly. I guess mir was resolved, it was stuck in unapproved queue?
<didrocks> Mirv: yeah, it's done now!
<fginther> didrocks, https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/revert_reverted/+merge/188371 building now (about 50% done)
<sil2100> Oh my
<sergiusens> doanac, lets discuss after image updates
<doanac> sergiusens: k
<didrocks> great ;)
<Mirv> sil2100: you has internet? :)
<sil2100> Mirv: yes!
<sil2100> Mirv: although I seem to be having lags
<psivaa> plars: balloons: dpm_ : regarding the calendar app test failures on maguro.. i see "x_pad = 0.15" is a little thin for maguro in test_monthview.py
<psivaa> i experimented it with x_pad = 0.35 and the appear to fix the failures..
<balloons> psivaa, ohh excellent. thank you
<plars> psivaa: awesome!
<plars> psivaa: did you propose a merge for it?
<psivaa> balloons: plars: not yet, i could do it rightaway
<didrocks> Mirv: sil2100: https://plus.google.com/hangouts/_/e4e5ae9e0927194b088489edf431527da8f0e4bd
<balloons> psivaa, go for it.. I assume it doesn't break mako
<balloons> but I will check ofc
<plars> psivaa: do you happen to know if it... right mako, was just going to ask but baloons beat me to it :)
<psivaa> balloons: plars: i have not tested with mako though.. i dont have one
<didrocks> ogra_: coming as well?
<didrocks> robru: ^
<lool> thostr_: upstart-app-launch >> I see this is all in trunk now, but will it work without Mir?
<lool> thostr_: I think this is unity-mir API?
<thostr_> lool: it's supposed to, otherwise we have a problem
<thostr_> lool: let me recheck
<cjwatson> I've certainly used it in the past without mir
<cjwatson> Maybe it doesn't do all the things it will with mir
<thostr_> lool: yes, latest upstart-app-launch should be fine
<thostr_> yes, it doesn't do everything without mir
<psivaa> plars: balloons: https://code.launchpad.net/~psivaa/ubuntu-calendar-app/fix-maguro-smoke/+merge/188646 is the MP :)
<lool> thostr_: it shouldn't regress on SF though, IIUC; will test this tomorrow morning so that we can land it just after tonight's image is confirmed good
<lool> (tonight's image isn't built yet)
<thostr_> lool: ok
<elopio> ping didrocks. So, image 75 will be out today or tomorrow?
<didrocks> elopio: tomorrow (for promotion)
<didrocks> elopio: it will start building in then next 3 hours
<elopio> great. Thanks.
<didrocks> yw ;)
<ogra_> *twiddle*
 * ogra_ waits for an android to come out of britney ...
<ogra_> *twiddle*
<didrocks> ;)
<didrocks>  I want to see a blinking ogra_
<ogra_> sorry, <blink> tag not supported
<ogra_> :)
<didrocks> ;)
<robru> ogra_, so what is the deal with the image upgrades? phablet-flash can only find image 70 and then if i try to update from system settings, it can't find any updates.
<fginther> Any CI team member want to help review: https://code.launchpad.net/~fginther/pbuilderjenkins/retry-apt-and-bzr/+merge/188664
<fginther> vila, ^?
<ogra_> robru, are you on the right channel ? we didnt release anything after 70, sounds liek you use stable
<josepht> fginther: reviewed
<fginther> josepht, clever
 * fginther wishes he was clever
<ogra_> image build running
<ogra_> build 75 done
<plars> ogra_ bot? :)
<ogra_> heh
<ogra_> no
<ogra_> :)
<fginther> plars, you still have the job for doing an image test with mir, right?
<plars> fginther: there's no job, because it never worked. I'm talking to olli about it now. The change to make it work is supposed to land today, and I'll retry then
<fginther> plars, ah, thanks. I had thought your results were from the job already, didn't think about just doing it manually.
<fginther> plars, doanac, is there anything available for diffing the results of two image tests? (just curious before someone builds a new one)
<plars> fginther: not at the moment
<doanac> fginther: sorry. we really need to carve out time for that in the next cycle
<fginther> plars, doanac thanks
<vila> fginther: approved, nice and simple ! Cool
<thomi> fginther: is CI/AL set up for lp:python-ubuntu-platform-api? If not, are you able to configure that for me pleae?
<thomi> *please
<fginther> thomi, looks like it's already there
<thomi> fginther: awesome,t hanks
<fginther> vila, thanks
<lool> ogra_: updated the landing pipeline for newimage
<lool> robru: this is what you'd expect on the "stable" channel; the devel-proposed channel would have image 75
<lool> Added landing slot for music-app powerd lock
<pmcgowan> lool, any chance we can land the toolkit? want to use the url handler in apps
<ogra_> lool, thanks
<sil2100> ogra_: is 75 released?
<ogra_> sil2100, no, but build
<ogra_> omg, gallery-app looks really bad
<sil2100> Oh, so there were some problems?
<ogra_> sil2100, beyond the ones durign the day ? no
<ogra_> there were no plans to release 75 today, thats planned for tomorrow
<sil2100> I thought 76 was for tomorrow, but I might have missed something
<sil2100> Ok, thanks!
<robru> ogra_, lool: ok, thanks guys. trying again
<ogra_> sil2100, 75 is just for getting back to a good state
<ogra_> plars, mako doesnt really look so well on the dashboard
<plars> ogra_: checking
<ogra_> maguro looks really good
<lool> popey_: you around tonight?
<lool> popey_: assuming 75 does well in testing, would you be good to release it?
<ogra_> (for the state the tests are at)
<plars> ogra_: both mako and maguro failed on mediaplayer it seems, mako failed on gallery too for some reason, let me check it out
<ogra_> plars, mauro only had one fail on mediaplayer ... for mako nearly everythign failed
<ogra_> *maguro
 * ogra_ vanishes back into the night 
<plars> ogra_: doesn't appear to be universal though, webbrowser passed
<ogra_> yeah
<plars> ogra_: I'll keep an eye on it, don't worry
<ogra_> thx
<ogra_> i'll driop by later again
<popey_> lool: i can't
<popey_> ooh
<popey> ogra_: mako looks good too. only one unity crash
<lool> popey: you can't?
<popey> lool: well, I have no knowledge of the process, and probably no access to the systems
<lool> the URL thing, is this the DBus interface to tell a running app about an URL to load?
<lool> pmcgowan: ^
<lool> pmcgowan: I've added it to plan in any case, but would like to know whether it relates to the "tell running app to load another URL" thing
<lool> popey: Oh sorry, I was asking for your approval, not for you to press the button
<lool> popey: my bad, wasn't clear
<popey> ah okay, that makes more sense
<popey> but yeah, 75 is good here
<pmcgowan> lool, yes it has the API for that
<pmcgowan> lool, did the qtubuntu change get in already?
<lool> pmcgowan: no, no qtubuntu update for 8 days or so
<lool> in trunk
<lool> pmcgowan: I don't know who's on the qtubuntu side in fact
<lool> I've lost track  :-)
<lool> pmcgowan: is this loicm?
<lool> Gerry is on the unity-mir side
<lool> but it's not complete
<vila> lool: doh ! just realized loicm is not another nick for you but another Loic ;-D
<pmcgowan> lool, I thought he finished the qtubuntu stuff some days ago, unless I am confusing it with something else
 * thomi hugs doanac for his termsize script :)
<doanac> thomi: gotta get your money's worth out of that giant screen!
<thomi> hell yes
<pmcgowan> lool, this was merged over a week ago so it must already been in https://code.launchpad.net/~aacid/qtubuntu/qtubunturl/+merge/181752
<thomi> doanac: am I missing something ? I seem to get 100% failures on all autopilot tests, with all AP packages from the image
<thomi> is there some step I'm forgetting? I ran phablet-click-test-setup, and then phablet-test-run
<doanac> thomi: are you try click packages or just normal apps?
<thomi> doanac: I'm trying everything in ~/autopilot
<thomi> like, unity8 for example
<doanac> thomi: hmm. unity8 worked fine for me (although it was broke). maybe you need to run the aa-click-hook to enable dbus probing?
<doanac> i don't think that's your issue, but might help
<thomi> doanac: ok, thanks - just wanted to make sure I wasn't missing something
<sil2100> lool: hm, I just switched to ubuntu-system - how can I make things read/writable? .writable-image doesn't seem to work
<sil2100> popey: ^? ;)
<sil2100> I'm used to using cdimage-touch
<robru> sil2100, it's .writable_image
<sil2100> robru: then the wiki needs updating
<robru> sil2100, yeah, I noticed that too...
<sil2100> robru:  adb shell touch /userdata/.writable-image is written there...
<popey> then reboot
<robru> sil2100, i tried to update it earlier but for some reason i can't login to the wiki... openid just loads forever & ever and never completes the login
<sil2100> robru: I updated it
<robru> sil2100, great, thx
<robru> sil2100, ungh, using terminal on the n7 for the first time (usually just use adb shell). how do I scroll?? finger scrolling is scrolling up to previous inputs. i can't see how to scroll back to read old output
<robru> sil2100, or, better question: how do I get autopilot tests to run from an adb shell? they just complain about not being able to connect to X that way
<sil2100> robru: use ssh for that
<sil2100> robru: just when using adb shell start ssh, connect and run autopilot - but remember you have to manually unlock the phone before running a test
<robru> sil2100, buh, what's the default username/pw for the device?
<sil2100> robru: phablet/phablet
<robru> sil2100, huh, i thought i tried that, of course it works now...
<robru> must have fat-fingered it pretty good
<lool> pmcgowan: Right, I was asking about something else; the merge proposal you quote is the one allowing apps to open URLs using the url-dispatcher as the backend, and that's all in
<sil2100> ;)
<lool> pmcgowan: the ongoing work is about telling an app that would be able to open URLs to load a new URL if it's already running (rather than killing it to pass it on the cmdline)
<pmcgowan> lool, right, and I think the toolkit has something added for the signal callback into QML
<lool> sil2100: touch /userdata/.writable_path + reboot, or mount -o remount,rw /
<sil2100> lool: all working already, but thanks
<lool> pmcgowan: so the change in ubuntu-ui-toolkit is definitely the second type: support for org.freedesktop.Application; at least that's in r768
<lool> by loicm
<lool> Cool, music playback works with screen off and USB cable unplugged here  :-)
<pmcgowan> lool, the behavior on the video lens is when you have a carousel with only 1 entry, it seems to jump around
<pmcgowan> but not playing
<lool> pmcgowan: exactly, but didn't manage to get it playing
<lool> pmcgowan: if it works, great; after reboot I had 2 out of 3 videos picked up and indeed it worked as usual
<pmcgowan> lool, 76 for sure!
<lool> :-)
<lool> pmcgowan: well in doubt I guess we should report this
<lool> filing this against unity8
<pmcgowan> I think its not that though
<pmcgowan> video scope
<lool> pmcgowan: is the carrousel in video scope?
<pmcgowan> lool, I am guessing but I just have one vid
<lool> pmcgowan: what's the name of the video scope?
<lool> there's unity-scope-video-remote, but not sure
<lool> seems only for remote videos
<pmcgowan> lool, I cant find it either
<lool> pmcgowan: the carousel is definitely in unity8
<lool> Dash/Video/VideosCarousel.qml
<lool> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233859
<pmcgowan> ok lets log there
<ubot5`> Ubuntu bug 1233859 in unity8 (Ubuntu) "Video carrousel doesn't activate mediaplayer for one video" [Undecided,New]
<pmcgowan> oh
<lool> Saviq: ^
<pmcgowan> lool, oh I get it now, with 2 they work
<lool> pmcgowan: yeah, that's what I was seeing in the sync call with rickspencer earlier today
<lool> ah crap, I broke the displaystatechange thing in unity
<Saviq> lool, pmcgowan https://bugs.launchpad.net/unity8/+bug/1226288
<ubot5`> Ubuntu bug 1226288 in Unity 8 "Carousel should only be used when there's enough items" [Medium,Triaged]
<pmcgowan> Saviq, indeed
<lool> Saviq: thanks
<thomi> doanac: still around?
<doanac> thomi: yes
<thomi> doanac: so I'm trying to run the ubuntuuitoolkit autopilot test suite...
<thomi> doanac: I get the tests using the phablet-click-test-setup script...
<thomi> doanac: but when I try and run the tests, it looks to me like the qml file(s) it launches and the desktop file it references are not present
<thomi> doanac: so it seems I need to install some other package
<thomi> and I was hoping you'd know what that was
<doanac> thomi: let me check. plars just added support to for that in our daily smoke testing this afternoon
<thomi> awesome, sorry, I'm not really sure who I should be pinging about thi
<thomi> s
<doanac> thomi: he sets up that test by installing the package. ie "apt-get install ubuntu-ui-toolkit-autopilot"
<doanac> so the the click-setup might be missing a dependency
<thomi> huh, ok, thanks :)
<thomi> doanac: who maintains that script? They probably want to fix that :)
<doanac> thomi: that would be sergiusens ^^^
 * doanac thinks all roads lead back to sergiusens
<sergiusens> hmm
 * sergiusens looks
<sergiusens> doanac, thomi ok, two weeks ago I said phablet-click-test-setup could potentially be used for testing ui-toolkit and unity8, but that required first getting the click stuff working
<sergiusens> doanac, thomi not really missing a dependency, just not installing the extras from the binary package
 * doanac bbiab
<thomi> sergiusens: the confusion is that that script downloads the tests
<thomi> sergiusens: I think it should either fully support ubuntuuitoolkit, or not at all
<thomi> downloading the tests, but not the test dependencies is confusing.. to me, anyway
<sergiusens> thomi, ah, well it doesn't I just download it so the emulators can be used from there
<thomi> ahhhh
<thomi> gotchya
<sergiusens> thomi, same for unity8
<sergiusens> thomi, with a bit more work, it could be made to work with everything
<thomi> sergiusens: so I still need to install unity8-autopilot with apt-get before running those test suites?
<sergiusens> thomi, yup, that's what I was just telling veebers on #ubuntu-unity
<thomi> oh, cool
<sergiusens> thomi, the click from phablet-click-test-setup probably needs to be removed once we support unit8 and the toolkit too :-)
<thomi> yeah
<kgunn> fginther: ...ping
<robru> kgunn, ping ;-)
<robru> kgunn, so, didrocks told me to poke you and ask for help testing mir on the device... I have the updated python-ubuntu-platform-api built in PPA and need help testing it before i can push it to distro
<kgunn> robru: you can find us on #ubuntu-unity having loads of fun
#ubuntu-ci-eng 2013-10-02
<fginther> kgunn, pong
<kgunn> fginther: hey man...sorry to bug you...just wondering about the ci run on this one
<kgunn> https://code.launchpad.net/~mterry/unity8/load-testability/+merge/188064
<kgunn> it looks like its failling to connect to local host ?
<kgunn> or maybe i dont understand the output
<kgunn> or is it b/c the autopilot tests fail...which ironically is why this mp is being approved to go thru
<fginther> kgunn, this one was human error on my part. I had updated the unity8 jobs to use the old VM test runner since the otto based one was failing every build. I missed an update of the internal test name
<kgunn> fginther: hey no prob....it happens
<fginther> kgunn, the runs are wired back correctly using the otto runner now. Saviq was able to identify the issue
<plars> doanac, psivaa: heads up, I'm regenerating all the jobs, this should bring in ui-toolkit, sergiusens click package check, and eventstat
<sergiusens> nice
<plars> sergiusens: this isn't full click testing support, this is just the thing you gave me back at the sprint
<sergiusens> plars, yup, I remember
<didrocks> Mirv: hey! I don't see a lot that entered yesterday, not sure what difficulties had robru and sil2100, are you continuing from there?
<didrocks> Mirv: sdk is the latest one, not for that imag please
<jibel> didrocks, it 20131001.3 going to be next current or there is another build on the road?
<jibel> *is
<didrocks> jibel: image 75 should be the next current. We need to investigate on the mediaplayer-app failure though
<jibel> didrocks, thanks, I'll start working on this image
<didrocks> thanks :)
<Mirv> didrocks: yes, I'm continuing. robru seemed to land stuff, sil2100 not so. I'm just about to publish libusermetrics - it does not fix media player app failures, but it's not worse either so I think it should be ok to land?
<didrocks> yeah ;)
<didrocks> no color automated on the spreadsheet, I read too fast
<didrocks> Mirv: +1 on usermetrics
<didrocks> Mirv: the failure due to usermetrics is fixed in the initramfs, it's just another protection
<didrocks> I hope that robru tested AP with python-ubuntu-platform-api, but let's see
<didrocks> jibel: as mediaplayer-app is crashing, maybe we won't promote image 75
<Mirv> didrocks: +1 also on http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libusermetrics_1.1.1+13.10.20131002-0ubuntu1.diff ?
<jibel> didrocks, that's fine, I'm testing mir and the shell
<didrocks> jibel: ok, if you install python-ubuntu-platform-api (now in archive) on top of it, it's supposed to have AP tests running
<didrocks> jibel: can you keep me posted about this?
<jibel> didrocks, okay, right after I reported crashes of maliit and hud
<didrocks> Mirv: +1
<didrocks> :)
<jibel> aha, even hud apport hook is buggy
<veebers> jibel, didrocks: Hi guys. I'm not sure if mir + autopilot will work at the moment, I see thomi filed this bug: https://bugs.launchpad.net/mir/+bug/1233944
<ubot5> Ubuntu bug 1233944 in Mir "Unity8/Mir is unable to open autopilot uinput devices" [Critical,New]
<didrocks> veebers: well, the Mir team promissed it was the case, but not sure if it was tested ;)
<didrocks> veebers: we'll see
<veebers> didrocks: sounds good :-)
<didrocks> Mirv: oh, if you have to do a partial publication, I want to try an update to the jenkins job first
<didrocks> Mirv: so, just ping me first please ;)
<jibel> didrocks, is there any specific AP tests you'd like me to run?
<didrocks> jibel: well, start with some apps one (not mediaplayer-app obviously as it crashes)
<jibel> (not notes-app, it doesn't start with mir enabled)
<didrocks> jibel: we were not able to start any AP tests before
<didrocks> jibel: you do have python-ubuntu-platform-api from the archive installed?
<jibel> didrocks, yes, that's the only package I upgraded.
<didrocks> interestingâ¦
<jibel> I disabled mir again, and notes starts fine
<didrocks> tell me for other apps if it's the case
 * jibel wishes he had 2 devices
<Mirv> didrocks: ok, the next one would be ubuntu-system-settings from settings, although I'm a bit struggling finding a way to test the Bluetooth part
<didrocks> Mirv: ok, can I deploy my change on the settings stack meanwhile?
<Mirv> does anyone happen to know how it should be possible to see non-headsets in ubuntu-system-settings Bluetooth?
<Mirv> didrocks: feel free
<didrocks> Mirv: if you are confident with the rest, seb128 tested it, so I trust him :)
<Mirv> didrocks: ok, I'll poke at it for some time still, since I'm interested, but at least pairing with headset works (no PIN, or actually bluez guesses the PIN because it's always 0000 or 1234)
<didrocks> Mirv: oh, bluez guess 0000 and 1234? Interesting ;)
<didrocks> Mirv: ok, partial publication is ready in theory ;)
<Mirv> didrocks: not generally, but it's some sort of "industry standard" that headsets have it 0000/1234
<Mirv> didrocks: sounds nice, the theory part
<thostr_> didrocks: do we have a new package by now?
<didrocks> heh :)
<thostr_> didrocks: or rather image
<didrocks> thostr_: new package for what?
<didrocks> thostr_: ah, not yet, mediaplayer-app failed
<didrocks> (the tests)
<didrocks> so there is image 75
<didrocks> which is proposed
<didrocks> but we can't promote it
<didrocks> (mediaplayer-app crashes)
<thostr_> didrocks: I see. I'll still give it a shot
<didrocks> Mirv: so, normally if you force publication and set "ON_PACKAGES" (replacing FORCE_REBUILD) to filter what you want to publish, it should work
<Mirv> didrocks: ok... I think it would be safest if I pick up the online accounts task as well, test that it doesn't blow and then try settings selectively...
<didrocks> Mirv: if you can do that, that would be lovely :)
<jibel> didrocks, I tried all the pre-installed application, only notes doesn't launch
<jibel> I'm reporting a bug but I'd appreciate a confiramtion from some one else
<didrocks> jibel: oh interesting
<didrocks> jibel: ok doing
<Mirv> didrocks: I'll try... any idea about "Try running ubuntu-system-settings-oneline-accounts AP tests", I don't find any autopilot package?
<didrocks> jibel: can you try Unity8?
<Mirv> I think I remember I tested it manually the last time too, adding some account etc
<didrocks> jibel: also, getting the results (failures/pass) would be grand
<Mirv> or is the AP tests the new thing, hmm..
<didrocks> Mirv: hum, there was a new one, no?
<didrocks> it's supposed to be the new one :)
<Mirv> oh yes, they are
<jibel> didrocks, ack
<didrocks> \o/
<Mirv> nice to see autopilot tests added
<didrocks> jibel: I think that will help to take a decision seeing how many tests are failing with Mir (so basically running tests as the dashboard)
<didrocks> jibel: I'm flashing here
<didrocks> Mirv: isn't it? ;)
<thostr_> don't we support --channel=daily-proposed any longer?
<didrocks> thostr_: saucy-proposed
<thostr_> ah, so the alias is not valid any more...
<Mirv> didrocks: I think the online-accounts is twice in the landing plan? landing no:s 69 and 78
<didrocks> Mirv: you're right, feel free to nuke one :)
<Mirv> ok
<didrocks> thanks!
<didrocks> jibel: trying Mir now
<jibel> bug 1234001
<ubot5> bug 1234001 in Mir "notes-app doesn't start with mir enabled" [Undecided,New] https://launchpad.net/bugs/1234001
<didrocks> jibel: unity8 is fine?
<jibel> 1 minute please
<Mirv> didrocks: can you check the error on the selective publishing at settings publish job?
 * Mirv afk, brb
<didrocks> Mirv: doing
<didrocks> hum, didn't I pull on magners?
 * didrocks recheck
<didrocks> didn't pull strongly enough :)
<jibel> didrocks, 24 failures with mir enabled. I re-running the tests without mir to make sure I ran them correctly
<didrocks> jibel: ok ;)
<didrocks> Mirv: ok, fixed, and published the settings. I'm trying another case right now (publishing ubuntu-system-settings-online-accounts)
<didrocks> Mirv: ok, both scenarios work, I'm deploying it everywhere
<didrocks> Mirv: everything is redeployed!
<jibel> didrocks, unity8 test results: 24/24 tests failed with MIR http://paste.ubuntu.com/6182814/
<didrocks> jibel: that's a nice score :)
<jibel> without MIR *only* 10/24 failed
<didrocks> urgh, really?
<didrocks> this is not the results we have in the dashboard, isn't it?
<jibel> with 20131001.3 and latest upa
<didrocks> jibel: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4512/
<didrocks> are they flacky tests?
<didrocks> (without Mir)
<Mirv> didrocks: ah, ok, thanks, I didn't check the channel :)
<Mirv> didrocks: so good that there's a simpler way than ssh:ing and renaming
<didrocks> Mirv: yeah, I'm sending instructions now ;)
<sil2100> Hi guys
<didrocks> Mirv: tell me if you see anything bad
<didrocks> hey sil2100!
<didrocks> how are you today?
<sil2100> didrocks, Mirv: do you know if mediaplayer-app AP tests are ok on the device for you guys?
<jibel> I'll try again without MIR and save the logs
<didrocks> sil2100: they are real crashers, we can't publish because of that
<Mirv> sil2100: not yet, but also not worse than on previous images
<didrocks> sil2100: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1234007
<ubot5> Ubuntu bug 1234007 in libhybris (Ubuntu) "[mako] out of index crash when handling media_codec output buffers list" [Critical,In progress]
<sil2100> Since I was running them yesterday as part of the libusermetrics testing, but I was getting crashes in both the new and old versions in mediaplayer-app
<didrocks> jibel: thanks! I'll succeed in testing this :)
<didrocks> sil2100: yeah, ignore mediaplayer-app for now
<sil2100> didrocks: good to know!
<jibel> didrocks, which version of UPA do you want me to test, the one on the image or the archive?
<Mirv> sil2100: I took some of the open tasks you had, so check the chart. hopefully you'll have time for some of the remaining stuff today since I'll be (mostly) away afternoon and then back in the evening
<sil2100> Mirv: sure, I was testing stuff yesterday, but since 75 wasn't released yet - I didn't want to publish stuff before I got a clear ACK on those
<didrocks> jibel: well, if you use surface flinger, that shouldn't impact. If it does, would be nice to know :)
<Mirv> sil2100: right.. the chart didn't state if anything was done on them so I obviously tested from scratch
<didrocks> sil2100: next time, please write that on the char ;)
<didrocks> chart*
<sil2100> Right... sorry about that, could have done that
<didrocks> sil2100: do you use any special video for mediaplayer-app that you send through mtp?
<sil2100> didrocks: not really, thought that the tests are self-contained and nothing special is needed
<didrocks> sil2100: ah ok, I thought you try to dogfood a little bit as well
<sil2100> didrocks: didn't push anything to the device, I was just using the mp4's that are on the nexus
<didrocks> sil2100: hum, where are they? I don't see them in music or video
<jibel> didrocks, I confirm the 10 failures without MIR, http://paste.ubuntu.com/6182868/
<jibel> didrocks, do tests publish on the dashboard run in a special way?
<didrocks> jibel: with phablet-test-run, but nothing else
<didrocks> jibel: the only thing I can think is downgrading upa
<didrocks> just in case it regressed the unity8 tests
<jibel> ah, I ran directly on the device
<didrocks> jibel: ah, try phablet-test-run -p <autopilot package> -n <AP test name>
<jibel> yes but it shouldnt make a difference
<didrocks> yep
<didrocks> all unity8 are fine here, upgrading upa now
<jibel> didrocks, <testsuite errors="1" failures="9" name="" tests="24" time="490.446">
<jibel> didrocks, with p-t-r that is
<didrocks> and latest upa, right?
<jibel> didrocks, I'm reflashing the phone to use upa from the image
<didrocks> yeah, let's see if we confirm that
<didrocks> tests already running
<didrocks> (here)
<jibel> didrocks, with 1.1+13.10.20131001.1-0ubuntu1
<jibel> didrocks, besides upa is there any other package I should have upgraded
<jibel> ?
<didrocks> jibel: no, it's the only one we are interested in right now
<didrocks> (for Mir support)
<ogra_> hmm, webbrowser-app could need a retry on mako for #75
 * ogra_ is pretty sure the failure will go away 
<Mirv> didrocks: I tend to test on the sintel clip extracted from demo-assets-videos .deb
<ogra_> didrocks, http://people.canonical.com/~jhodapp/
<didrocks> sil2100: back?
<ogra_> there is sintel too :)
<didrocks> ah, so you do install/grab it
<ogra_> yeah
<didrocks> there is nothing in the image by default?
<didrocks> jibel: Ran 24 tests in 412.164s
<ogra_> nope
<Mirv> not anymore by default
<didrocks> OK
<didrocks> with latest UPA
<didrocks> ok :)
<didrocks> I wonder if sil2100 didn't flat his install for a long time :)
<ogra_> i think design works on something with one video, one mp3 and a few wallpapers
<ogra_> but not sure if that will make it in time
<didrocks> ogra_: basically you download it, push to the video folder by mtp and it appears after a reboot on the video lens?
<didrocks> ah, back with the example package!
<ogra_> didrocks, hopefully without reboot :)
<didrocks> IIRC, it doesn't work without the reboot, but let's see
<ogra_> well, for the final image it should work without ... i wouldnt really like to reboot every time i put some data on my phone
<didrocks> yeah ;)
<didrocks> no arguement here :p
<Mirv> I didn't have luck with the appearing part, so for mediaplayer I tested it from command line..
<ogra_> especially in the light that we have no reboot UI support :)
 * didrocks tries a reboot :)
 * ogra_ would have tried a HUD search first ;)
<Mirv> I think it's the mediascanner's responsibility to get it visible
<ogra_> it is
<didrocks> it's crazy that it's taking less time for me to dl the latest image than rebooting the phone
<ogra_> haha, yeah
<ogra_> i'll do some bootcharts before end of the week ...
<ogra_> probably we can improve some low hanging fruit before release
<didrocks> ogra_: hum
<didrocks> is it working for you?
<didrocks> like I see an empty thumbnail (normal as we don't have thumbnail support anymore)
<didrocks> then I click on it
<didrocks> it move to the center (but not full screen)
<didrocks> and nothing
<didrocks> keeping it pressing show the preview
<ogra_> on mako or maguro ?
<didrocks> and I can play the video
<didrocks> mako
<ogra_> well, there is bug 1234007
<ubot5> bug 1234007 in libhybris (Ubuntu) "[mako] out of index crash when handling media_codec output buffers list" [Critical,In progress] https://launchpad.net/bugs/1234007
<ogra_> fix is attached but waiting approval from jhodapp
<didrocks> ogra_: yeah, but this is camera_app itself
<ogra_> afaik thats also supposed to fix the AP errors
<didrocks> ogra_: I know, I tracked that with ricardo this morning ;)
<ogra_> err
<ogra_> camera_app ?
<didrocks> mediaplayer_app
<didrocks> sorry ;)
<Mirv> didrocks: I've the same, but I didn't figure out it still also works from the UI, so I played the clip from command line.
<ogra_> ah :)
<didrocks> Mirv: yeah, it works if you succeed to enter the preview mode and press play
<didrocks> not really a stellar experience but good enough to test
<ogra_> on maguro everything should work fine
 * ogra_ is still flashing 
 * StevenK calls the police to ogra_'s apartment
<ogra_> *uiiiuuuu* *uiiiuuu* *uiiiuuu*
<Mirv> hmm the quiet mid-stop cafe became extra noisy with lunch time, I guess I need to find a better place somewhere
<didrocks> heh ;)
<sil2100> Damn, not sure why but autopilot tests are hanging up for me
<Mirv> sil2100: does something start on the phone side, or nothing seems to happen?
<Mirv> sil2100: are you sure you're not running mir which had the AP problem?
<sil2100> Mirv: for sure, I guess it happens like every 3-4 runs so it's not that bad
<sil2100> Mirv: but it's hanging up and nothing is moving, the application stays frozen - probably not even an AP problem
<sil2100> Maybe an overall touch problem
<Mirv> sil2100: I tend to reboot a lot anyway when doing tests
<didrocks> sil2100: everything's good? need newing?
<sil2100> didrocks: all tested, one moment - btw. do you have issues with connecting to mangers today?
<sil2100> didrocks: normally it took around a minute to connect, but now it's like forever
<sil2100> Mirv: ^?
<didrocks> sil2100: why do you need to ssh to it?
<Mirv> sil2100: works for me. FYI I'm attending a couple of conference sessions right now, will work more afternoon your time.
<didrocks> (yeah, same here, stalled to connect)
<Mirv> right, ssh doesn't seem as good as web side
<Mirv> sil2100: but with the partial release now supported you shouldn't need to
<didrocks> yeah, hence my question :)
<sil2100> Stone age from my side, didn't know it was tested already! But good - then just 'ON_PACKAGES' and force_publication, right?
<sil2100> I think we need to update the flag descriptions on the head job a bit
<didrocks> sil2100: you should have get an email from me :)
<didrocks> the description was updated, wasn't it? "space separated list of project that will effect a rebuild or a publication
<didrocks> "
<sil2100> didrocks: yes, but FORCE_PUBLICATION has: "Force publication of all pending components for this stack"
<sil2100> didrocks: should be "for all or the listed components" or something ;)
<didrocks> sil2100: it's all but filtered ;)
<didrocks> yeah
<didrocks> feel free to do it
<didrocks> and redeploy :p
<sil2100> Nooo, so many jobs, I think it's awesome as it is... ;p
<didrocks> sil2100: you didn't get my email then?
<didrocks> sil2100: if you can test the command line tool in the next publication, I would be interested
<sil2100> I got it, but I think my Thunderbird doesn't check for new e-mail until I don't switch between inboxes
<sil2100> Which is probably wrong
<sil2100> I'll test the tool
<sil2100> didrocks: if a stack is on 'waitonstacks', will running publishing work for the old state?
<didrocks> sil2100: yeah
<sil2100> -P without -f is the "foo" trick for publishing? Like, ./cu2d-run -P stack_name ?
<seb128> sil2100, right click on the tb box, you have a "when receiving new emails, always check that folder" box to tick
<sil2100> didrocks: I see a strange problem, I guess not related to the latest changes even - if a stack is waiting on waitonstacks and we tell him 'do publishing without forcing', it will not do that then
<sil2100> didrocks: since the second head job will start, second waitonstacks job will successfully finish, but the second head job will still wait for the first (valid) waitonstacks job to finish
<sil2100> didrocks: so now there are 2 head jobs waiting on waitonstacks ;p
 * sil2100 wonders if the same issue is when forcing stack publication or not
<didrocks> sil2100: yeah, without force, it won't publish on waitonstacks automatically
<didrocks> sil2100: forcing should work
<sil2100> didrocks: cu2d-run works nicely in this case, although in the e-mail in the -P -f <list of packages> case you missed the stack name, so that it's -P -f <stack> <list of packages>, but that's obvious as it doesn't make sense otherwise ;)
<sil2100> didrocks: pushed the onlinemusic scope and thumbnailer
<didrocks> sil2100: in the email, I was just talking about the change in parameters, but yeah ;)
<didrocks> sil2100: \o/
<lool> didrocks: outside of music-app, which other coreapps AP tests were failing?
<lool> didrocks: I'm joining a HO with coreapps folks in a few, might as well mention these
<didrocks> lool: rssreader
<didrocks> lool: calendar-app seems flacky as well
<didrocks> lool: will be nice to refrain their landing btw
<didrocks> lool: do you want me to join?
<lool> didrocks: I think I can cover, will mention the landings too
<didrocks> ok
<didrocks> thanks
<lool> chatting with dpm to see how we do this
<vila> didrocks: we need some more info about that loop device issue you mentioned about pbuilder, at least whether you know the cases where pbuilder needs such a device. cowbuilder is a clear one but are there others ?)
<didrocks> vila: I think only cowbuilder needs it, that was the trace you pointed at, right?
<vila> didrocks: damn, where is is now that I need it
<didrocks> vila: hidden from you ;)
<vila> didrocks: got it: http://10.97.2.10:8080/job/gallery-app-saucy-i386-ci/352/consoleFull it's -ci job, so no cowbuilder used there
<vila> didrocks: good
<vila> didrocks: I'll keep the cowbuilder <-> loop device issue in the back of my mind but something else was going on there
<vila> didrocks: thanks for confirming
<didrocks> vila: yeah, this one is different, I saw it once IIRC on magners IIRC (and had to reboot the machine)
<sil2100> didrocks: after pushing onlinemusic scope and thumbnailer, I don't see it neither on the queue nor in -proposed, am I unaware of something?
<didrocks> sil2100: hum, are you sure the whitelist was refreshed on the server side?
 * didrocks looks
<sil2100> didrocks: I have no ways of checking that, but seb128 said it was ok
<didrocks> seb128: you refrshed on snakefruit, right?
<sil2100> Snakewhat?
<sil2100> ;O
<didrocks> sil2100: wasn't refreshed, so rejectedâ¦
<sil2100> Names keep getting better
<sil2100> seb128: ^ ?
<sil2100> didrocks: is snakefruit different from lillypilly?
<seb128> didrocks, I followed https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack
<didrocks> sil2100: yeah, it moved
<didrocks> seb128: needs refreshing, was about to do that the other day, but then, interruptionâ¦
<seb128> didrocks, so no, I pulled on lillypilly
<sil2100> I didn't know about the move as well, so I asked seb128 to do it on lilly as well;)
<seb128> didrocks, would be good to rm that directory on lillypilly if it's not used there anymore
<seb128> didrocks, I would have went "wait"
<didrocks> done now
<seb128> didrocks, thanks
<seb128> didrocks, "done" includes the pull on baskedoffruit?
<seb128> :p
<didrocks> yeah, wiki updated and pulled :)
<didrocks> so I have to resurrect the request
<sil2100> didrocks: how should I push it to the queue again now?
<seb128> didrocks, thanks
<didrocks> sil2100: handling that :)
<seb128> didrocks, https://wiki.ubuntu.com/DailyRelease/FAQ?action=diff&rev2=47&rev1=46 ;-)
<sil2100> ;p
<sil2100> seb128: shouldn't it be... basketoffriuit?!?!
<seb128> sil2100, lol, I was trolling on the name ;-)
<sil2100> ;D
<didrocks> seb128: argh, ok, missed that one :p
<didrocks> (done)
<didrocks> sil2100: lucky you, copied at 13:37! ;)
<cjwatson> seb128: um, what directory on lillypilly?  if /home/ubuntu-archive/anything, everyone's sudo access to ubuntu-archive@lillypilly was already supposed to be locked out to avoid confusion
<cjwatson> That was part of the switchover
<cjwatson> bah, that regressed
<seb128> cjwatson, what I did is
<seb128> ssh lillypilly.canonical.com
<seb128> sudo -u ubuntu-archive -i
<seb128> cd cu2d/cupstream2distro-config/
<seb128> bzr pull
<seb128> cjwatson, ^
<didrocks> (confirmed, I can as well)
<seb128> cjwatson, no error
<cjwatson> Yeah, reported on #is
<seb128> cjwatson, thanks
<cjwatson> Anyway, use ubuntu-archive@snakefruit.  It's much faster :)
<cjwatson> It hadn't occurred to me to grep the wiki
<cjwatson> Cleaning up a few other references now
<seb128> cjwatson, I had no idea we migrated to snakefruit (I might have read the mail and forgot about it in my after-holidays-backlog, if there was one)
<seb128> well, now I know ;-)
<bregma> the libunity version bump has descended the last several Unity7 daily builds into dependency hell...  there's nothing we can do on the code side to fix this, is anyone on the build side tracking the libunity bump consequences?
<cjwatson> I thought I'd mailed everyone, but no matter ...
<seb128> cjwatson, yeah, as said,  probably my fault, I tried to not spend too much time on emails backlog after my holidays, and I probably overlooked it/read quickly and didn't store the info
<cjwatson> I'd also expected the sudo change to stick so that it wouldn't be a big deal if people didn't notice straight away, and it didn't occur to me that IS wouldn't put that change in puppet :-P
<didrocks> well, at least, we discovered it, that's all what counts ;)
<didrocks> sil2100: as your hands are a little bit more free now, can you look at what bregma's telling?
<sil2100> didrocks: ok
<sil2100> bregma: let me take a look
<bregma> sil2100, thanks... the problem my not be related to the libunity bump after all, but it's still a dependency fail somehow
<sil2100> bregma: do you mean the check job? Or is there a crash somewhere? Since I see that the cu2d build job needs updating indeed
<bregma> sil2100, I'm looking at http://10.97.0.1:8080/job/autopilot-saucy-daily_release/2283/label=autopilot-intel/console
<bregma> nvidia job is the same
<sil2100> bregma: right! Merge coming
<bregma> I want all the failures to be my fault... no wait...
<sil2100> ;D
<sil2100> I seem to have redeployed the stack some time ago without having the change merged in, so it got cleared out after subsequent redeployments
<didrocks> sil2100: bad bad ;)
<didrocks> ok, time for some exercise, be back in ~1h
<sil2100> pff ;p Not the first time I did bad things! I'm bad to the bone :(
<sil2100> didrocks, Mirv, seb128: https://code.launchpad.net/~sil2100/cupstream2distro-config/bump_libunity_unity/+merge/188822 <- anyone of you can take a peak and approve?
<sil2100> *peek
<didrocks> sil2100: approved
<sil2100> didrocks: thanks! Have a nice exercise ;)
<didrocks> thx!
<lool> so qtpowerd is coming in later today
<lool> with music-app changes
<cjwatson> FYI there will be some hopefully brief buildd downtime in about an hour for code upgrades
<cjwatson> Things look fairly quiet at the moment aside from the test rebuild
<lool> ogra_: is the timezone selection from settings fixed in archive?
<ogra_> yes
<ogra_> with pittis last upload
<lool> ogra_: but not in #75?
<ogra_> oh, wait
<lool> ogra_: is that systemd upload?
<ogra_> no
<ogra_> the additional initramfs-tools-ubuntu-touch one
<ogra_> from today
<ogra_> just strikes me, we need an android rebuild to pick it up
<cjwatson> android takes about an hour to build, right?
<ogra_> lool, 75 is only half working
<ogra_> cjwatson, 40min
<cjwatson> if you do it RIGHT NOW it might squeeze in before buildd downtime
<cjwatson> looks like 30min in fact
<ogra_> i have to donload it ... over 2M
<ogra_> thats takes 15min or so
<ogra_> lool, ^^^ could you ?
<cjwatson> I meant the raw build time
<ogra_> (no change rebuild of android)
<ogra_> cjwatson, i was referring to the "RIGHT NOW" :)
<lool> sorry, was in a HO
<lool> I have too little bandwidth
<lool> ogra_: you still want that to be done?
<ogra_> lool, would be good, yeah
<lool> I can try from a remote host
<lool> unpacking........... |===                          |
<cjwatson> If it takes that long maybe it isn't a big problem if it waits until after buildd downtime
<lool> :-)
<lool> building the source package...
<lool> uploaded
 * ogra_ hugs lool 
<lool> it's in unapproved
<lool> cjwatson: ^
<cjwatson> I expect it'll be auto-accepted
<cjwatson> thanks
<ogra_> yeah
<lool> ah right, unseeded
<ogra_> it usually is
<cjwatson> Yep
<cjwatson> I think I'll cancel the interminable openclipart2 test rebuild to make way for it; I was going to have to cancel that anyway, probably
<lool> ogra_: so what's the missing stuff to get timezone selection working?
<ogra_> lool, that was it :)
<lool> ogra_: ok
<ogra_> the "synced" mode needs another fix to not replace links with their target files on boot
<ogra_> s/needs/needed/
<fginther> didrocks, are you seeing 'autopilot issues' again? I noticed a new one back in the ppa and at least one test run is showing similar test failures again.
<fginther> sil2100, are you seeing 'autopilot issues' again on the daily release tests? I noticed a new one back in the ppa and at least one test run is showing similar test failures again
<lool> taking a break, bbiab
<didrocks> fginther: urgh, really?
 * didrocks looks
<didrocks> sil2100: new autopilot in the ppa? Not sure how you disable it, but it seems you either don't push the branch or do something wrongâ¦ :/
 * didrocks will do this one himself
<didrocks> fginther: autopilot removed from the ppa
<didrocks> (needs to publish the removal)
<fginther> didrocks, thanks
<didrocks> fginther: I'm pushing to cupstream2distro-config the removal as well
<fginther> didrocks, ack
<didrocks> fginther: ok, done :)
<didrocks> fginther: were those issues the one you reported to thomi? apparently he has no idea that AP is creating issues
<didrocks> (or don't want to test)
<fginther> didrocks, we discussed just the problem, but in great detail. I'll work with him to test this in the same env
<fginther> didrocks, err *not* in great detail
<didrocks> fginther: well, basically it's latest image + AP trunk
<didrocks> (and running all AP tests)
<fginther> didrocks, I see the problem when running ubuntuuitoolkit tests
<fginther> didrocks, we'll get it figured out
<didrocks> thanks fginther :)
<lool> ogra_, didrocks: Who's seeding thumbnailer in the image?
<ogra_> is that supposed to land this build ?
<didrocks> lool: right now nothing, I think we'll have a dep?
 * ogra_ thought that was for next one
<didrocks> ogra_: it's in the archive for this one, I think the dep is coming to the next one
<ogra_> ah, fine then
<lool> didrocks: I think thostr_ wanted it in the image to make their life easier somehow
<lool> thostr_: Heya
<lool> thostr_: so thumbnailer is in archive, but it wont be in image unless something pulls it in; usually it's a dependency
<lool> thostr_: do you need it in the image?  if so, do you have a piece to land that will pull it?
<didrocks> lool: not sure how this help compared t ohaving it in the archive
<lool> ogra_: Would you know where the powerd changes for dconf are staged?  don't see them in PPA
<lool> didrocks: not sure either, hence pinging thostr_
<lool> :-)
<thostr_> lool: we need that to then build the sdk changes
<didrocks> thostr_: so, it's fine in the archive I guess
<thostr_> didrocks: yes, then all builds should run at least
<lool> thostr_: all builds?
<ogra_> lool, in a branch, didnt i link it ?
<thostr_> lool: well, getting that properly build
<lool> thostr_: so
<lool> thostr_: is https://launchpad.net/ubuntu/+source/thumbnailer being in archive good enough for you?  :-)
<lool> for now
<thostr_> lool: yes
<lool> thostr_: ok, marking your landing for this one as DONE then, thanks for confirming
<jibel> plars, psivaa quantal ec2 have been failing for a while, is someone taking care of them?
<plars> jibel: afaik, the server team looks after those, but we'll check on it
<jibel> plars, well they apparently look then run when they see the results
<jibel> plars, if they are useless, they should be disabled
<jibel> plars, that'll lighten the load on the publisher
 * psivaa would like to see the link of that :)
<plars> jibel: indeed
<didrocks> thostr_: re: libusermetrics, how important is the regression?
<didrocks> thostr_: I see the MP, but no assessment of what the impact is
<plars> psivaa: http://10.98.0.1:8080/view/ec2/job/quantal-server-ec2-daily/
<didrocks> (some tests are failing?)
<thostr_> didrocks: that's more a functional regression
<psivaa> plars: thanks, lots of red balls
<didrocks> thostr_: so, on AP tests are impacted? (like no rush to push it?)
<thostr_> didrocks: qml api didn't provide the same as c++/qt api
<didrocks> oh, but nothing is using it as of now?
<didrocks> ok*
<plars> jibel: do you know who set all of those up originally?
<plars> jibel: or if there's any documentation of it?
<thostr_> didrocks: nothing will crash or so, it just makes the infographic looking a little bit strange in worst case
<didrocks> thostr_: ok, I'm planning for image 77 then
<jibel> plars, it was James Page and Carlos. I don't know if james is still in charge of these jobs
<didrocks> (not 76)
<thostr_> didrocks: ok
<didrocks> thostr_: when I see "regression", this is like an alarm :p
<thostr_> didrocks: ok, will be more careful the next time
<didrocks> no worry ;)
<didrocks> (just think about my heart ;))
<didrocks> sil2100: you can pre-prepare some more task for landing #77 if you want
<didrocks> sil2100: also, it would be interesting to see why libfriends want to rerelease
<balloons> didrocks, plars lool I have pending fixes for all the failing tests for music, rss reader and calendar. Due to sdk and emulator bugs it's been hard to land them this week
<didrocks> balloons: waow, excellent! so this is going to be in for image 77?
<didrocks> balloons: can you just wait for 76 to be building (like in 3 hours at max?)
<didrocks> balloons: you did rerun AP yourself I guess on them?
<balloons> didrocks, well, I've been trying to land them -- they are still pending on not yet merged
<didrocks> balloons: ok, let's target image 77 rather
<balloons> kk
<didrocks> we can warn you if needed
<didrocks> balloons: just ensure that all AP tests are back to green with them please ;)
<balloons> didrocks, when do you plan to land 77?
<didrocks> balloons: we'll certainly kick a build tomorrow morning
<didrocks> (my morning)
<didrocks> balloons: but you can get them landed in the ppa just when 76 finishes to build
<didrocks> balloons: in this 3 hours window (we can ensure to ping you for this)
<didrocks> balloons: mind adding a landing ask for those?
<didrocks> so that we track them
<balloons> didrocks, sure
<didrocks> thx!
<sil2100> ACK
<balloons> didrocks, I actually don't seem to have edit privileges
<didrocks> balloons: we can fix that :)
<didrocks> balloons: done
<balloons> "=_
<lool> balloons: (following up from #ubuntu-app-devel)
<lool> balloons: yes, list of known ui-toolkit critical bugs still affecting bzr trunk very much welcome
<lool> balloons: we were about to consider an updated version
<lool> So, I've dist-upgraded to everything in archive + PPA (I know, crazy)
<lool> and things were mostly working
<lool> music activation only works once though, I see the attempt to tell music-app to load new URL, but it doesn't work
<lool> will try to add that to music-app rather than adding workarounds in upstart-app-launch
<sil2100> didrocks: for the AP issue - it was disabled and redeployed, but the branch was not pushed to trunk as I thought we'll have it fixed ASAP - and while you were redeploying for the new cu2d functionality it got enabled back again, bad call from my side
<lool> launching music-app from shell and from music scope results in a single music app
<sil2100> I knew bzr push was the way to go
<lool> hmm actually, launching from shell first, then opening URL results in two music-apps
<lool> but not the reverse  :-)
<didrocks> sil2100: heh, no worry, fixed now
<balloons> lool, I would say the only "critical" bug is the one I mentioned already: https://launchpad.net/bugs/1233402
<ubot5> Ubuntu bug 1233402 in Ubuntu UI Toolkit "The Tab needs a tabIndex property" [Critical,Confirmed]
<sil2100> didrocks: eh, indeed - one release on the 30th and then next was today ;/
<didrocks> yep
<lool> balloons: ok
<didrocks> ogra_: is really "
<sil2100> ogra_: did you seed the onlinescope and thumbnailer? ;)
<didrocks> initramfs-tools-ubuntu-touch, android: bugfix for readlink with empty path"
<didrocks> in archive?
<didrocks> (we set it for image 77)
<ogra_> didrocks, no, waiting for 77 :)
<didrocks> ogra_: hum, the status is wrong, TODO then?
<didrocks> ogra_: oh, sil2100 is right, the onlinescope will need seeding, I can do it
<didrocks> (not thumbnailer as we discussed)
<Mirv> didrocks: hi. there'd be a qtdeclarative patch request, where could we fit that in?
<didrocks> Mirv: I guess image 77 or 78, what the patch is supposed to fix?
<Mirv> didrocks: bug https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1233705
<ubot5> Ubuntu bug 1233705 in qtdeclarative-opensource-src (Ubuntu) "Add patch to fix loading of ListView items in some corner cases" [Undecided,New]
<didrocks> Mirv: ok, please add a landing ask, I think we can get that with the new sdk as you will need to relaunch all AP tests
<Mirv> didrocks: so basically any lists, tsdgeos is requesting it. I'll make preparations anyhow and test it.
<Mirv> didrocks: ok
<didrocks> Mirv: so if you can deal with both, fine with me
<didrocks> ensure you have DEP5, forwarded, and so on
<Mirv> ok, adding
<Mirv> yep
<didrocks> ogra_: sil2100: seeded and metapackage uploaded
<sil2100> didrocks: thanks!
<didrocks> yw ;)
<didrocks> sil2100: re: thumbnailer, this will come with a dep I guess
<sil2100> didrocks: makes sense, otherwise it's rather useless to include
<thostr_> sil2100: didrocks: yes, sdk/unity8 will depend on thumbnailer... working on those MPs right now
<thostr_> didrocks: can you schedule line 118 for landing?
<sil2100> Awesome
<didrocks> thostr_: I'm talking with lool about it
<thostr_> didrocks: ok
<didrocks> thostr_: there is an upstart-app-launch landing already planned, I wonder if we can sneak that one into it
<didrocks> sil2100: don't forget to prepare the HUD req. as well btw ;)
<thostr_> yes, 113, 118 and 119 at the same time?
<didrocks> oh you did update
<didrocks> sil2100: great, well, I think you will let ted knows about the regresssion if it's not flacky tests
<didrocks> thostr_: yep, that's what would make sense to me
<thostr_> didrocks: then let's go for it
<lool> thostr_: so I did some testing with new upstart-app-launch
<didrocks> thostr_: yeah, done ;)
<lool> thostr_: it kind of regresses a bit if we dont update music-app at the same time
<lool> and mediaplayer-app I guess
<thostr_> lool: correct
<lool> and perhaps webbrowser-app  :-)
<lool> thostr_: So I've been looking at updating music-app, but it will take me some time to test
<thostr_> lool: bfiller pinged me on that and we need to move all at once
<lool> yeah
<lool> thostr_: so holding up url-dispatcher + upstart-app-launch to go at the same time
<didrocks> lool: as bfiller asked me to ensure before each app landing that they are ready, please ensure that as well :)
<didrocks> keeping ? for landing target as of now
<lool> thostr_: otherwise, seemed good; I did get two copies of music-app in one case, and haven't tested with Mir yet
<lool> thostr_: a couple of settings:/// URLs worked, but not the last one
<lool> didrocks: music-app is coreapps though
<lool> didrocks: but the other ones would be bfiller indeed
<didrocks> yeah, for that one :/
<didrocks> right
<bfiller> lool: why url-dispatcher and upstart-app-launch at the same time?
<thostr_> lool: didrocks: I guess at some point we need to move... it won't get easier trying to sync all settings pages and apps
<lool> bfiller: they don't particularly depend on each other for the staged changes, but they touch the same use cases right now (mainly opening URLs)
<bfiller> lool: fine with me if they go in together but lets get them in the queue as I believe they are ready
<sil2100> ;)
<lool> bfiller: as I note above, there are some small regressions with upstart-app-launch and I'd rather we merge them along the *-app updated to deal with opening URLs
<lool> bfiller: do you have the webbrowser/mediaplayer changes in the pipe for this?
<lool> also, this needs ubuntu-ui-toolkit, which has some regressions
<bfiller> lool: yes, the MR's need ui-toolkit before they can be approved and landed
<bfiller> lool: and also needs changes to unity8 to promote running apps
<bfiller> lool: two oustanding MR's for media player and browser to handle urls when running
<lool> bfiller: so music-app missing?
<bfiller> I'd prefer to see stuff that is not blocked go in right away rather than waiting for all the related stuff to land
<lool> bfiller: Will try to cover the music-app part then
<bfiller> lool: don't know about music-app
<lool> bfiller: the problem is not that they are related, but that there are regressions if we don't push them together
<lool> I think the only thing that might be able to get in alone is url-dispatcher
<bfiller> ok
<lool> which only adds safety nets
<lool> Hmm and calendar URL it seems
<bfiller> and support for :/// urls
<didrocks> ogra_: i386 published in proposed for hybris, can we push android now?
<ogra_> rsalveti, ^^^
<ogra_> didrocks, yeah, we should be fine
<rsalveti> doing as we speak
<didrocks> \o/
<didrocks> sil2100: Mirv: I added you to the meeting so that I don't have to paste url everytimes :)
<lool> cjwatson: heya, https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+build/5069701 is waiting for an armhf PPA buildd, but Launchpad says there are 0 armhf PPA builders?
<vila> didrocks, lool: Finally get out the rabbit hole and fixed 'la mochetÃ©' ;) https://code.launchpad.net/~vila/cupstream2distro/star-log/+merge/188875
<vila> *out of
<lool> cool
<lool> vila: you joining our HO in 2mn?
<sil2100> ;)
<sil2100> didrocks: thanks!
<cjwatson> lool: Mid-upgrade
<lool> cjwatson: ah ok; thanks
<didrocks> vila: ah nice! will probably review it tomorrow morning though
<cjwatson> lool: Unfortunately the upgrade has been a bit rocky and IS is still working on getting the various backend machines back
<lool> cjwatson: do we have an ETA?
<cjwatson> 16:54 <ChrisS> cjwatson: Some (well, most) of them are misbehaving ("Error: Device 769 (vbd) could not be connected. Hotplug scripts not working") and needing ppa-makebaseing.  Getting there, though.
<lool> cjwatson: cause we'd like these builds in an upcoming image build
<Mirv> didrocks: I've so poor connection that I can try to listen to but probably need to get the url:s from elsewhere anyhow..
<cjwatson> is all I have
<cjwatson> lool: Uh, that makes no sense
<cjwatson> lool: If it's to be in an image build, surely it should be in a devirtualised PPA instead?
<lool> cjwatson: sadly, coreapps PPA is still used in our builds
<cjwatson> lool: And all of those builders are back ...
<didrocks> Mirv: https://plus.google.com/hangouts/_/e02813c8dad5247b82691825a672a098f47139d5
<cjwatson> lool: Oh, ugh, I didn't realise that was virt
<lool> cjwatson: maybe it's virt
<vila> lool: good idea !
<vila> didrocks: no urgency
<lool> cjwatson: we're trying to drop this PPA for release BTW, I'm meeting in 30mn to get up to speed on where things stand there
<cjwatson> Yeah, it's virt
<cjwatson> Let me see if one of the working builders can do the job
<didrocks> sil2100: joining?
<didrocks> robru: ^
<sil2100> !
<rsalveti> didrocks: ogra_: pushed android, once available in the archive, please trigger a new image
 * ogra_ is already watching https://launchpad.net/ubuntu/saucy/+source/android/20131002-0539-0ubuntu3
<ogra_> :)
 * ogra_ hugs rsalveti ... thanks for the upload 
<ogra_> didrocks, gst1.2 will be all fine, dont be so worried, its just bugfiuxes :)
<cjwatson> lool: I *think* hamsa will be able to do it.  I've reassigned it to armhf temporarily, though I don't know how long it'll take to finish its current build
<cjwatson> lool: Are there any other vitally urgent builds?
<cjwatson> Building.  Let's see ...
<lool> cjwatson: yes, but the other one isn't uploaded yet
<rsalveti> didrocks: fginther: cyphermox: awe_: needs help setting up CI for ofono, packaging + code branch pushed at https://code.launchpad.net/~phablet-team/ofono/ubuntu
<lool> https://launchpad.net/bugs/1233402
<rsalveti> bzr bd compatible, source format 1.0
<ubot5> Ubuntu bug 1233402 in Ubuntu UI Toolkit "The Tab needs a tabIndex property" [Critical,Confirmed]
<rsalveti> didrocks: fginther: who can help me on that? :-)
<cyphermox> rsalveti: I can
<fginther> rsalveti, I can help
<cyphermox> do you have CI already?
<rsalveti> cyphermox: nothing, just created that branch
<fginther> cyphermox, no upstream merger yet
<cyphermox> ok
<lool> cjwatson: https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+build/5069757 is the other one
<cyphermox> then I'll let fginther play with it :)
<cjwatson> lool: i386, really?
<awe_> rsalveti, thanks for the update.  I created: https://wiki.ubuntu.com/Touch/Telephony/ofono
<awe_> will update with the branch, and further instructions later on
<cjwatson> lool: Oh, arch all I guess
<rsalveti> awe_: cool, thanks
<cjwatson> lool: scored up
<fginther> rsalveti, is there a separate lp branch for ofono upstream?
<rsalveti> fginther: https://code.launchpad.net/~phablet-team/ofono/rilmodem, which is an auto-import from git
<awe_> fginther, see the page I just posted above
<awe_> on the wiki
<fginther> awe_, ack
<awe_> which describes the setup in a bit more detail
<rsalveti> fginther: the branch I gave you (lp:~phablet-team/ofono/ubuntu) has that included + packaging, which works fine with bzr bd
<lool> cjwatson: thanks
<sil2100> Do the gallery_app tests work ok for all of you all the time? Since I noticed those hang up the most
<didrocks> rsalveti: sorry, back from meeting
<didrocks> ogra_: worried me? never ever ever :p
<didrocks> rsalveti: sil2100 is a good victim for that :)
<ogra_> haha
<didrocks> robru: can you pair with sil2100 on the tasks assigned to him?
<robru> didrocks, sil2100: sure
<didrocks> robru: then, feel free to continue during the day one his tasks
<didrocks> thanks!
<robru> sil2100, which do you want me to start with?
<ogra_> didrocks, https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1234087 ... i'll add a landing asks entry for it
<ubot5> Ubuntu bug 1234087 in telephony-service (Ubuntu Saucy) "No sound notification for Call/SMS" [Critical,Confirmed]
<didrocks> robru: please don't push anything before 76 is building :)
<robru> didrocks, when will that be?
<didrocks> ogra_: who needs sound? ;)
<ogra_> yeah
<didrocks> robru: stare at ogra! ;)
<ogra_> heh
<robru> ogra_, !!!
<ogra_> once this is fully in tegh archive https://launchpad.net/ubuntu/saucy/+source/android/20131002-0539-0ubuntu3 i'll trigger the build
<robru> ogra_, http://goo.gl/isDWPJ
<didrocks> ogra_: ok, let's see once we get the fix to schedule it ASAP
<lool> fginther: ubuntu-touch-coreapps-drivers
<didrocks> ogra_: thanks for the notificatoin :)
<lool> fginther: ppa:ubuntu-touch-coreapps-drivers/daily
<ogra_> should be done building in ~20 min ... then promotion etc
<didrocks> (no sound for this notification though :p)
<ogra_> robru, LOL !
<robru> I am staring at you ;-)
<sil2100> What's up?
<robru> sil2100, I don't have any work assigned in the landing plan, so i'm helping with yours. pick a couple things for me to do
<ev> didrocks: do you think it would be helpful to put gstreamer into the proposed-migration hinting to prevent it from accidentally landing again?
<sil2100> rsalveti: if it's about packaging, I'm all ears!
<rsalveti> sil2100: actually we just need to set up the CI for, I believe the packaging should be mostly fine, but a review (for the CI infra) would be welcome if you got the time
<sil2100> robru: could you tackle 123?
<cjwatson> ev: Well, it was already blocked
<sil2100> rsalveti: always, that's my greatest passion ;) Let me take a look
<rsalveti> I believe fginther is setting up the CI infra for it already
<cjwatson> ev: Not in proposed-migration, but it landed in unapproved ...
<robru> sil2100, sure
<rsalveti> sil2100: thanks!
<didrocks> ev: I think we won't have big migration again (like jump from 1.1.4 to 1.2), only small bug fixes from now on. So I don't think that will help us. I don't see the issue being different than someone pushing the SDK today for instance
<sil2100> robru: I'll finish up HUD and libusermetrics - last time it didn't really work as mediaplayer-app had issues
<didrocks> ev: I mean, it's more a social issue
<robru> sil2100, ok
<ogra_> cjwatson, all of it ? i think there are universe and multiverse bits that dont
<cjwatson> the relevant bits
<fginther> lool 0.0.20130924~bzr4~ubuntu13.10.1
<ogra_> k
<cjwatson> ev: I'm not sure that the release team could have known not to unblock it since the request came from a phonedations developer
<didrocks> cjwatson: yeah, I think no one is blaming the release team at all :)
<ev> didrocks, cjwatson: ah right, thanks.
<ev> yeah, that wasn't my intention here
<ev> I'm just brainstorming on how we can feed the landing task force into the loop for this without the release team having to communicate every single action to them
<ev> but having been away when all of this was set up, I am not going to begin to propose I have the right answers :)
<cjwatson> ev: Well, I'm all for the touch landing team blocking everything they care about in proposed-migration and selectively unblocking; that's why I set that up
<cjwatson> ev: I'm just sceptical that it would have solved this particular problem, that's all
<rsalveti> didrocks: what is the big issue with the 1.2 transition? the main problem we had was with the media stack itself
<didrocks> rsalveti: yeah, but we wanted to promote an image with the media stack first
<rsalveti> and that's a stable release, mostly with bugfixes, comparing with 1.1.4, that we had discussed before
<didrocks> rsalveti: so the unexpected upload (it's always a risk) is just making 76 at risk if things go wrong
<ev> cjwatson: so then perhaps I don't understand the point you're making. So if proposed-migration is before unapproved, wouldn't this have blocked well before hitting the release team?
<rsalveti> didrocks: right, but we had another blocker that wasn't related with 1.2 at all
<ogra_> didrocks, its like going from a 0.99 version to 1.0 with only bugfixes added
<rsalveti> didrocks: it's not unexpected in this case
<rsalveti> we tested and verified the media stack on top of it, and our issue wasn't related at all with that
<didrocks> rsalveti: well, nobody from the landing team planned to get it before we promote an image
<cjwatson> ev: You have it exactly backwards :)
<rsalveti> was a broken code
<didrocks> rsalveti: so it was added to the landing ask without concertation
<robru> didrocks, sil2100: for unity-scope-home / unity-lens-applications, the landing plan says "check that the string change was acked by translators"... who are the translators, how would i check this?
<didrocks> landing plan*
<ev> cjwatson: whoop. But then surely it still blocks at proposed-migration?
<didrocks> rsalveti: no worry, but again, I wish we could have promote an image (so having the media stack landed with all AP tests passing)
<cjwatson> ev: And the other point is that only a single unblock is needed - so in exactly the same situation, if somebody comes to the release team and says "we need the new gstreamer" ...
<didrocks> then, getting 1.2
<rsalveti> didrocks: right, what did you want me to do in this case?
<didrocks> rsalveti: just ask us to schedule it on the landing plan
<rsalveti> we discussed it was a bugfix release, tested our mediastack, added to the spreadsheet, and landed
<didrocks> rsalveti: that was the reason it wasn't on the schedule yet
<ogra_> rsalveti, put it on the sheet and wait til next landing team meeting to get approval i guess
<didrocks> yep, what ogra told :)
<rsalveti> right, that's what I wanted to get
<rsalveti> where did we decide that?
<rsalveti> when, and how :-)
<ogra_> trhere was a mail where the spreadsheet was introduced
<ev> cjwatson: so is that more of a social issue? That someone comes to the release team and says "we need this" and so they unblock it at proposed-migration without consulting with the landing task force?
<didrocks> rsalveti: we have 2 meetings a day and I send a report after each meeting on ubuntu-phone ML
<cjwatson> ev: the release team shouldn't be expected to know about the ins and outs of touch landing, basically
<ogra_> i dont think it got across in that mail that this is a mandatory process
<rsalveti> didrocks: right, so you want me to put something there and wait your report to expect when such transition could land?
<cjwatson> ev: people shouldn't be requesting things of us that aren't touch-authorised in the first place :)
<rsalveti> ogra_: exactly
<rsalveti> and this is part of the stack we were *landing*
<didrocks> rsalveti: indeed, if you want to speed it up or have questions, ping works
<cjwatson> ev: (but IMO the entire touch landing process is broken)
<didrocks> rsalveti: hum, no that was 2 requests on purpose
<didrocks> as you got fears as well about landing it IIRC (from the hangout)
<rsalveti> didrocks: right, but we didn't necessarily needed to land both separately
<didrocks> like we all have with new code
<ev> cjwatson: sure, I wouldn't expect that of the release team. I had just assumed the tools at their disposal pointed to "hints-ubuntu-touch" in the case of this block
<rsalveti> didrocks: because we thought we would land the first stack way before
<didrocks> let's imagine AP tests for media are screwed tomorrow
<didrocks> it will be more difficult to know if it's gst1.2
<didrocks> or the change
<cjwatson> ev: perhaps they would; it's hard to say yet because the touch landing team generally isn't using the tools I provided
<rsalveti> but it was blocked until the point where we decided to do both together, and then fix the remaining issue on top of it
<didrocks> I think this could have just wait one image
<ev> and so once this was properly socialised, they'd know that the release task force really should be signing off on any override of that
<cjwatson> yeah, perhaps
<rsalveti> didrocks: but this was a low risk bugfix only, that's why I didn't follow all this process
<ev> (to be clear I'm not trying to assign blame here; just trying to prevent this sort of thing from happening again while not creating an incredible burden on the release team)
<didrocks> rsalveti: but no worry again, it's just that we have a process for acking things and it's better that everyone follows it
<rsalveti> didrocks: but I'll make sure to attend the meeting if I want to land something again
<didrocks> noone died ;)
<rsalveti> this is just horrible and painful
<didrocks> rsalveti: yeah, or ping if you don't want to spend your time on it
<cjwatson> rsalveti: amen
<rsalveti> didrocks: you're not on-line all the time
<didrocks> rsalveti: well, I didn't design the process ;)
<rsalveti> so I need to sync my ping as well :-)
<ogra_> ev, well, imho the blame lies in the initial email describing the process ... it wasnt clear from it that this is a mandatory process for everyone and how strict it is
<rsalveti> exactly
<cjwatson> ev: if it takes a small amount of socialisation in the release team of making sure not to override touch hints without checking, in order to burn the spreadsheet landing process to the ground; I would be happy with that
<ogra_> ev, imho we have some communication improvement to do here +
<didrocks> rsalveti: I'm not the only one, there is lool, ogra, asacâ¦
<Laney> all in the eu
<ev> ogra_: absolutely! this is *brand* new. It's going to take a few attempts to get it running smoothly.
<ogra_> yes
<didrocks> Laney: unfortunately yes
<ogra_> well it is more about getting people less grumpy by knowing what they have to expect
<ev> cjwatson: I can send a mail around asking for that, if you think it would help
<cjwatson> ev: Well, I sent mail when I set up the touch hints in the first place; very little response
<cjwatson> ev: I don't think there's much to be done in the release team until people start using it
<ev> didrocks: so why aren't we really using this yet? ^
<cjwatson> ev: And everyone seems too heads-down-focused-on-13.10 to even consider this
<ev> I did notice that as well. The only change is from lool, and it's commenting something out.
<ogra_> ev, because it is duplication
<cjwatson> ogra_: it is intended to be replacement, not duplication
<cjwatson> your current process is utterly dire and hopeless
<ev> duplication of what?
<ev> (this is what I get for going on holiday)
<cjwatson> it is the most human-intensive thing I have ever seen, with very poor use of technology
<ogra_> ev, as long as we have the spreadsheet and nobody agrees that we can instead use proposed it wont fly i think
<cjwatson> (sorry, but nobody seems to be listening to milder criticisms)
<ogra_> cjwatson, and i think many of us agree
<cjwatson> so it is absolutely not intended to duplicate, but to replace
<cjwatson> of course it can be run in parallel as a safety net
<sil2100> robru: best use the translator's ML I guess
<cjwatson> and in that mode it's indeed somewhat duplicative
<cjwatson> I can't do much about that except complain :)
<fginther> rsalveti, I should get that ci setup soon, will ping you when it's ready
<didrocks> cjwatson: nobody was aware about that process before the email
<didrocks> cjwatson: it just went out by surprise
<didrocks> we all agree I think that's not the way to go
<didrocks> unfortunately, it helped to get a green image, and management seems to think it's the way to go
<didrocks> I hope that by enforcing it and showing how intensive this is, we can help post-v1 to revisit it
<cjwatson> My fear is that it will simply entrench it
<didrocks> I can only see one positive side on this process: we know exactly what enters
<cjwatson> And burn you guys out in the process
<rsalveti> fginther: awesome, thanks
<didrocks> cjwatson: well, I made it clear that I won't continue post v1 with the current process
<cjwatson> TBH if I didn't have to work on touch-related things I would be finding other things to do; as an uploader it's utterly demotivating too
<didrocks> so either they will find someone else
<cjwatson> didrocks: *nod* good
<didrocks> or so be it :)
<rsalveti> yeah
<ogra_> didrocks, lets just all convince asac that proposed is the way better place for gatekeeping
<ev> cjwatson: demotivating how?
<ogra_> didrocks, after all it was exactly designed for this
<rsalveti> why would you propose a fix if you know how painful the process is
<cjwatson> ev: instead of "upload source, let it build, request somebody to ack it, they can do that regardless of whether I'm around"
<didrocks> ogra_: I think we need propose + some tracking
<didrocks> then tracking needs to be automated
<ogra_> didrocks, right
<didrocks> I don't have any answer for that
<ev> cjwatson: *nods*
<rsalveti> didrocks: my issue is having this blocked my a human process, and by people as well
<ogra_> didrocks, i would also like to have automates PPA image builds, so we can pocket copy feature sets of packages from proposed there and start a special image build
<cjwatson> ev: I have to prepare the source, fill in an entry in a cumbersome spreadsheet, wait some undefined time for people to ack it there, then if I happen to still be around I can upload but only if there isn't an image currently being prepared ...
<rsalveti> that are not 24 hours available (of course), and that wants to control the pipeline
<ev> cjwatson: have you broached this with asac and rick?
<didrocks> rsalveti: don't worry, I don't have time to do anything technical anymore due to that, so I can only concurre :/
<ogra_> didrocks, that will give us automated testing for free for the stacks
<cjwatson> I've tried
<rsalveti> while we have tons of stuff that needs to land and get fixed by this cycle still
<didrocks> ogra_: yeah, I think we need the feature approach
<cjwatson> I set up the proposed-migration stuff after raising my concerns with the current process, as an attempt at constructive contribution
<didrocks> with a set of changes coherent between themselves and tested
<ogra_> we shouldnt look at single packages or commits anymore
<ogra_> but define feature sets we want to land that consist of a bunch of packages ... and then test against the -proposed packages
<rsalveti> didrocks: the issue about not getting a green image is not blocking broken stuff in trunk mainly
<rsalveti> blocking the package later on is already too late
<didrocks> rsalveti: you seem to argue as if I designed this and was the cause of it :)
<ogra_> and if we need a papaertrail, lets pelease use a proper ticket system instead of a spreadsheet
<ev> what would a "proper ticket system" give us over a spreadsheet?
<rsalveti> didrocks: I'm just replying based on what you said
<cjwatson> ev: but what's really demotivating is slaving away for months to make the upload/proposed/build/release pipeline as fast and smooth as possible, and then the whole thing is undone by putting a spreadsheet in front of it
<rsalveti> not pointing fingers
<vila> rsalveti: huh ? You want your trunk to be gated by integration tests with other projects ?
<cjwatson> ogra_: bzr commit to the touch hints branch would do fine as a paper-trail
<cjwatson> I mean, we're all developers here
<ogra_> ev, tickets :) and a proper overview ... did you look at the landing asks sheet yet ?
<didrocks> rsalveti: there is the issue that you have a set of changes that are interdependant
<cjwatson> the landing asks sheet is a self-created problem
<rsalveti> vila: historically, the issue we had was that we got broken stuff that was approved without being properly tested
<rsalveti> vila: in trunk
<ogra_> cjwatson, well, i think management still wants langing requests and some "lander" who leads it through the testing and actual landing process
<rsalveti> didrocks: right, this is fine, and can be done in the integration level
<cjwatson> yes, of course if you crank the velocity/risk-aversion slider all the way to the right then you end up with lots of stuff outstanding
<didrocks> rsalveti: that was the goal of daily release: in august, I was asked to get faster, so we got 4 hours daily, then a month later, it was too fastâ¦
<cjwatson> ogra_: so then I hear we have this bug tracking system
<ogra_> cjwatson, ++
<Mirv> ok so qtdeclarative seems to compile fine, so should be ready to be tested together with ui-toolkit in the morning
<ogra_> cjwatson, i didnt specify which ticket system ;)
<vila> rsalveti: right, I got that. I was emphasizing that if you don't want the "package to be blocked later", you need more tests before getting there.
<rsalveti> vila: yup
<ogra_> cjwatson, we are doing a hardcode version of a freeze atm, so indeed the distro freeze process can apply
<ogra_> *hardcore
<rsalveti> but anyway, let me get back to coding as I still have stuff to fix
<cjwatson> ogra_: it's like we're doing a freeze and trying as hard as possible to ignore the benefit of nine years of experience releasing Ubuntu
<ogra_> cjwatson, yeah
<cjwatson> sorry.  I'll go away and do some work now
<ogra_> dont look at me :)
<rsalveti> cjwatson: +2
<rsalveti> I don't even know who is the "release team" anymore :-)
<ogra_> ah, android is done building
<ev> cjwatson: I don't think anyone is intentionally discarding the infrastructure you've built, and I would hope that we all see the value that clearly exists in it.
<ev> My understanding was that the landing task force was created to solve a problem that proposed migration did not handle well at the time - moving sets of changes through in a very coordinated fashion, such that we could test just those changes and then move on to the next set. This with clear communication between the stakeholders.
<ev> I'm assuming (and perhaps I'm wrong) that this was assumed to be quicker than hacking that into proposed-migration for 13.10, which was satisfactory for testing whether the process itself worked.
<ev> If there's a better technical way of accomplishing this with reduced overhead, but still achieving the same goal of moving in chunks with careful coordination (on the archive side - I see no reason to stop developers from throwing everything at -proposed), then great, I think we should make that a reality in 14.04 after discussing it in detail at the client sprint.
<ev> rsalveti: so at least as far as the CI side of things is concerned, we're hoping to simplify this with the "sheriff" role I mentioned at the QA/CI sprint. Put a single face on it.
<cjwatson> ev: Honestly?  It's simply untrue that proposed-migration couldn't have handled that, and nobody even asked
<cjwatson> ev: As far as I know, nobody asked any of the release team (with lots of experience with this kind of thing) how our existing tools might help
<ev> cjwatson: okay, but that's why I said perhaps I'm wrong. I wasn't involved in that conversation (being in the desert at the time).
 * cjwatson nods
<cjwatson> I'm not upset because I feel slighted, I'm upset because everyone talks about how fast we have to move and how vital time is and yet we make no effort to take advantage of existing resources and reinvent the wheel instead
<ev> But I want to believe that everyone has pure intentions here. We all want Ubuntu to either not regress or increase in quality with every set of changes. Maybe they just didn't realise that we had tools for this and picked the ones they were most familiar with.
<ev> I'll talk to asac about it if he pops up tomorrow
<ev> so I'm not just speculating
<ev> but I have seen a pattern of things being done in a certain way because either people weren't aware that a better process was available (and thus didn't know to ask about it), or because of history (testing off of CDs because that's what we've done since those sprints in Millbank) - so I don't think it's entirely unreasonable to think that this all boils down to miscommunication
<ogra_> cjwatson, i brought up proposed several times prior to the spreadsheet with asac and the answer was "not fine grained enough" ...
<cjwatson> ogra_: It's possible there was a misunderstanding there
<ogra_> cjwatson, the point he is making every time i bring it up is that people dont seem to test their code in advance before landing it in trunk
<cjwatson> Which is completely orthogonal
<ogra_> (which i think is valid for a good part of us)
<cjwatson> proposed + bug tracking for requests + test-before-unblocking would be a good process improvement, I think
<ogra_> might be orthogonal, but the current process enforces exactly this testing
<cjwatson> at a great cost
<ogra_> yes
<ogra_> at a way to big cost imho
<ogra_> i agree that there should be such testing in place ...
<ogra_> once we can actually provide it automated
<sil2100> didrocks: if I see that HUD is fine, can I publish that?
 * sil2100 still is having problems in running gallery-app tests
<sil2100> But that's not related to hud, as with the reverted hud I get the same hangups
<sil2100> I guess my phone is broken in overall
<ogra_> sil2100, make sure to never run app tests after doing a unity test
<ogra_> they will fail
<sil2100> ogra_: I'm running fresh after a reboot, the tests are hanging - unity8 as well
<sil2100> No reaction to touch
<ogra_> ouch
<sil2100> ogra_: at first I thought these are only gallery-app tests but no, webbrowser-app are causing the same problems ;/
<ogra_> did you unlock the screen befroe starting the test ?
<ogra_> (needs to be done manually)
<ogra_> didrocks, lool, android is in, should i fire off a build now ?
<didrocks> ogra_: yes please!
<ogra_> doing
<didrocks> sil2100: not before ogra told that the image is published please :)
<ogra_> ~30min
<lool> ogra_: yup
<lool> fginther: So I try to kick a build of http://91.189.93.70:8080/job/music-app-ci/ and got instant failure everywhere; is that because there was no change in bzr?
<lool> e.g. tests failed with bzr: ERROR: Error parsing trunk.recipe:3:14: Expecting the end of the line, got 'lp:music-app'.
<fginther> lool, it doesn't have all the necessary arguments, one moment
<fginther> lool, this is the build we want to rerun: http://91.189.93.70:8080/job/music-app-ci/88/
<fginther> lool, you should see a rebuild link, just hit that and it'll have all the right parameters
<lool> ev: asac comes back on Tuesday I think
<lool> fginther: ok thanks
 * ogra_ wonders if ev became german secretly ... to take advantage of the long german weekend this week :)
<sil2100> ;)
<sil2100> Damn, after upgrade it's much better now, maybe something got screwed up or I don't know
<sil2100> ogra_: how's the publishing going?
<bfiller> fginther: can you relaunch the mako test for this MR: https://code.launchpad.net/~schwann/ubuntu-ui-toolkit/uitk-missing-search-focus/+merge/188640
<ogra_> sil2100, still needs a bit
<ogra_> sil2100, 10min or so i'd guess
<fginther> bfiller, yes
<ev> ogra_: heh, nope. Just wandered out to walk the dog.
<ogra_> heh, that would have been a long walk ... until monday :)
<ogra_> sil2100, go !
<ogra_> cdimage is done ... system-image might still take a while
<rsalveti> great, can test the cdimage one
<plars> ogra_: were there two back-to-back builds on system image?
<sil2100> ogra_: ok, I did an experiment, and it seems when using image 75 my AP tests are hanging up, on for instance 70 that does not happen
<sil2100> ogra_: I guess it's unity8 that's hanging up maybe...
<ogra_> plars, not today, no
<plars> ogra_: odd, something caused the jobs to get triggered twice
<ogra_> sil2100, might be ... i would try to go forward in images to see when it starts ... http://people.canonical.com/~ogra/touch-image-stats/ has all the changelogs
<fginther> bfiller, the rerun passed, I re-approved the branch
<bfiller> fginther: thanks
<fginther> rsalveti, trial run of http://10.97.2.10:8080/job/phablet-team-ofono-ubuntu-ci/1/ passed
<fginther> rsalveti, I want to make sure I understand correctly... developers will propose thier MPs against lp:~phablet-team/ofono/ubuntu, correct?
<rsalveti> fginther: awesome
<fginther> awe_, ^
<rsalveti> fginther: correct
<fginther> rsalveti, and lp:~phablet-team/ofono/rilmodem is just provided as a convenience, we don't actually need to build anything from that in ci?
<awe_> it's where we get our upstream code
<dobey> so, is system-settings supposed to freeze and/or crash all the time on the current image?
<awe_> in order to create MPs
<rsalveti> hm, can't reach 10.*, let me try restarting my vpn
<fginther> rsalveti, jenkins is crawlllllling
<rsalveti> oh, right then
<fginther> as least the Web UI is for me
<bfiller> fginther: can you see why I can't access the deb from this MR: https://code.launchpad.net/~thomas-moenicke/ubuntu-keyboard/ubuntu-keyboard-fix-loader/+merge/188878
<bfiller> get Status Code 404 errors
<fginther> bfiller, the build publisher is stuck, so data isn't currently making is way from 10.97.2.10:8080 to jenkins.qa.ubuntu.com
<fginther> bfiller, retoaded is looking at it
<bfiller> fginther: thanks
<fginther> awe_, rsalveti, do we want something to automatically build updates of  lp:~phablet-team/ofono/rilmodem against the ubuntu branch (or do you already have launchpad setup to do that)?
<rsalveti> fginther: not at this point, we'll be proposing mrs manually
<fginther> rsalveti, thanks
<rsalveti> that's why we only needed the CI for the ubuntu branch right now
<rsalveti> yeah, still unable to load it
 * ogra_ goes afk to watch the game
<awe_> rsalveti, might not be a bad idea though?  We'd know ahead of time if something slipped through which breaks the build...
<rsalveti> right, but let's see how this workflow works, then we can proposed this automerge/release
<awe_> sure
<robru> ugh, is anybody else experiencing launchpad issues? most pages won't load, i get lots of 'connection reset', etc. the pages that do load take several minutes to load
<plars> ogra_: I'm seeing a lot of system-settle issues in 76
<plars> ogra_: with "upstart-propert" (obviously truncated by top)
<plars> upstart-property-watcher
<fginther> cyphermox, can you review? https://code.launchpad.net/~fginther/cupstream2distro-config/add-ofono/+merge/188898
<fginther> cyphermox, not sure if this is ready for daily-release or not.
<rsalveti> plars: yeah, fix in progress, but need to trigger another android build and image
<plars> rsalveti: ok, cool
<plars> I guess the autopilot stuff didn't make it?
<rsalveti> the mediaplayer one got fixed http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4523/mediaplayer-app-autopilot/
<thomi> fginther: got a second?
<fginther> thomi, yes
<thomi> fginther: can I download .deb files from CI runs?
<fginther> thomi, normally you can
<thomi> fginther: I don't have a cross compile setup, and I need armhf binary packages from this MP: https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900
<fginther> thomi, I don't think we're archive debs for mir, let me check
<fginther> thomi, I take that back, they are built, here's an example: https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/76/
<thomi> sweet
<thomi> so I just need to wait for the CI job to finish...
<cyphermox> fginther: thanks, just need a very minor change
<fginther> cyphermox, ack
<fginther> cyphermox, done
<sergiusens> thomi, where's the code for upstart and click in autopilot again? need to add and APP_URIS entry
<thomi> sergiusens: autopilot/testcase.py
<sergiusens> thomi, thanks
<thomi> sergiusens: make sure you base it on lp:autopilot/1.3!
<sergiusens> thomi, ack
<thomi> fginther: jenkins is down?
<fginther> thomi, yes
<thomi> :(
<fginther> sad faces all around
<fginther> thomi, jenkins is up
<thomi> fginther: thanks
<veebers> fginther: ping
<fginther> veebers, pong
<veebers> fginther: hey how are you?
<fginther> veebers, good, how's life there?
<veebers> fginther: not bad, sunny but windy today
<veebers> fginther: following up on my email re: running the tests across the test apps
<ralsina> fginther: I get errors from jenkins about it failing to contact launchpad, are you the person to know about that?  https://jenkins.qa.ubuntu.com/job/unity-scope-click-saucy-amd64-autolanding/38/console
<fginther> ralsina, yes, one moment
<ralsina> fginther: cool, thx
<veebers> fginther: oh although I see jenkins is down; so perhaps this isn't the best time to bother you about that?
<fginther> veebers, it just came back up. I was just looking at a job related to your request
<veebers> fginther: ah awesome, thank you
<fginther> ralsina, it's a transient failure, someone already approved the MP again so that it will be re-run (a fix for the underlying issue is in the works)
<fginther> veebers, so
<ralsina> fginther: awesome, we'll keep retrying then :-)
<fginther> veebers, here's the job I ran to test autopilot/1.3 trunk: http://10.97.2.10:8080/job/autopilot-testrunner-otto-saucy-fjg/89
<fginther> veebers, it appears to be stuck on the first test suite
<veebers> fginther:  :-\ is there any output?
 * veebers looks
<fginther> veebers, it ran 347 autopilot tests, does that sound like the right number?
<veebers> fginther: heh, um I'm not sure. I only really run them as separate testsuites
<veebers> fginther: so it's no longer stuck on the first test suite?
<veebers> ah, _now_ the page loads
<fginther> veebers, guh!
<fginther> veebers, I think it was caused by a bug in the runner script (something I added)
<fginther> veebers, I don't quite understand, "autopilot run" had finished, but "tee $AP_LOGFILE" was still hanging around.
<fginther> veebers, perhaps it didn't receive an EOF
<fginther> veebers, it's finishing now
<veebers> fginther: that's odd. I don't think that has anything to do with my changes though
<fginther> veebers, this test was done using lp:autopilot/1.3
<fginther> veebers, I can fire up another with your branch
<veebers> fginther: ah I see, not running my branch. I understand now :-)
<fginther> veebers, ok, lets see how this goes, which branch do you want tested?
<veebers> fginther: awesome, lp:~veebers/autopilot/fixing_backend_being_none
<fginther> veebers, I kicked off a touch and otto based job from your branch, details in email
<thomi> fginther: I wonder if you could help me? I want to kick off http://10.97.2.10:8080/job/mir-saucy-armhf-ci/ for thsi MP: https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900 but some of the parameters in that job are kind of confusing...
<fginther> thomi, http://10.97.2.10:8080/job/mir-saucy-armhf-ci/77/, If you're just doing a one-off build, all that's needed is the landing_candidate (the branch to build)
<thomi> fginther: cool, thanks
<fginther> thomi, beyond the defaults
<thomi> right
<veebers> fginther: awesome thanks
<rsalveti> plars: pushed a new android package with the upstart-watcher fix
<rsalveti> will spin a new image once that's in
<plars> rsalveti: \o/
<plars> rsalveti: I'm not going to obsess too much about the results on 76 - don't think it's worth it. I'll keep a closer eye on 77 when it comes out though
<rsalveti> plars: yeah
<rsalveti> lool: 77 will be to fix the upstart-property-watcher regression
<rsalveti> we hope to get the ringtone regression at 78
<rsalveti> lool: can you bump the image numbers in the spreadsheet?
<lool> rsalveti: cool
<lool> rsalveti: I did bump a few some minutes ago
<rsalveti> great
<rsalveti> I hope that just communicating this here should be enough
<lool> rsalveti: yeah, look at bottom of landing pipeline, I added a slot for you
<lool> like literally 10 mn ago
<lool> was about to transform into a pumpkin
<rsalveti> lool: right, but ringtone is still planned for 77
<rsalveti> 77 will be for the upstart-property regression
<rsalveti> 78 might hopefully be for the ringtone regression
<lool> ah i forgot the other regression, that's right
<lool> too many things to add
<rsalveti> the pain to track everything manually :-)
<lool> rsalveti: surprizing eh?
<rsalveti> :-)
<rsalveti> thanks for taking care of it
<lool> 2 days without promoting images is quite bad
<lool> rsalveti: so do you have some details about what the ringtones and upstart fixes entail?
<lool> source packages and ETAs mainly
<rsalveti> lool: upstart fix is already in, just waiting android to be migrated from proposed
<rsalveti> ringtone I'm still investigating the issue
<lool> rsalveti: https://launchpadlibrarian.net/152176453/android_20131002-0539-0ubuntu3_20131002-2036-0ubuntu1.diff.gz seemed to reverse other changes; was this intentional?
<rsalveti> lool: that's a change that xnox pushed today
<rsalveti> related with the goldfish target, which we're not yet using
<rsalveti> so that's fine
<lool> rsalveti: well, he's working on the emulator
<lool> rsalveti: so you reverted his change and we want to reupload it, yes?  :-)
<rsalveti> lool: well, he is the one that changed that upstream
<rsalveti> so I believe he knows what he's doing in there
<rsalveti> I just created a new dump from the repo
<lool> rsalveti: ok, so you picked up a new change from upstream, this wasn't an accidental revert; thanks
<rsalveti> lool: yeah
<rsalveti> lool: android just got published, starting a new build
<lool> rsalveti: thanks
<lool> rsalveti: hold on
<lool> rsalveti: it's not published in release pocket yet
<lool>    android | 20131002-0539-0ubuntu3 | saucy/multiverse | source, all
<lool>    android | 20131002-2036-0ubuntu1 | saucy-proposed/multiverse | source, all
<lool> is what I see in rmadison
<lool> don't trust LP web UI
<rsalveti> lool: hm, seems to be here
<rsalveti> crap
<rsalveti> already started it
<lool> rsalveti: it's ok, just build another one after that  :-)
<rsalveti> well, let's see :-)
<cjwatson> rsalveti: It wasn't visible to image builds until :26
<cjwatson> 2013-10-02 22:26:51 DEBUG   Moving the new dists into place...
<cjwatson> lool is correct, always use rmadison to check this
<rsalveti> cjwatson: right, I thought I could trust the launchpad web ui =\
<rsalveti> but thanks anyway
<cjwatson> The Launchpad web UI reflects the database state, and the database state is flipped to published near the start of the publisher run
<cjwatson> Launchpad doesn't actually really know when it hits disk as far as image builds are concerned
<cjwatson> At least not in any way that the web UI can get at
<rsalveti> right, I just thought that the launchpad ui/database would be the last step of the update/publish part
<cjwatson> Nope
<rsalveti> but don't know much how this is actually done internally, so thanks for the explanation
<rsalveti> cjwatson: btw, is there a way to track the live-build log in realtime?
<rsalveti> lool: ^
<lool> from nusakan there might be
<lool> I think http://%s/~buildd/LiveCD/%s/%s/latest/livecd-%s.out might be updated live if you know the right buildd
<lool> rsalveti: http://kishi00.buildd/~buildd/LiveCD/saucy/ubuntu-touch/latest/livecd-armhf.out
<rsalveti> lool: cool, thanks
<rsalveti> lool: so the android bits are actually consumed later on
<rsalveti> when creating the final image, so we might still be good
<cjwatson> rsalveti: Yeah, from the DC you can, otherwise not until we get it into LP
<veebers> fginther: still around?
<veebers> fginther, thomi: Appears http://10.97.2.10:8080/job/autopilot-testrunner-otto-saucy/703/ has finished running. 3 failures, 2 for uut which I need to propose a fix too (creation of mock DbusIntroObj, __init__ now takes an extra argument)
<thomi> veebers: uut shouldn't be creating that directly - what's it doing?
<veebers> thomi: just looking now, looking at the log it's in the test_emulator suite, so I think it's to do with testing itself (and not in use when you use the emualtors in app tests)
<thomi> veebers: OK, well those tests should probably live insdie lp:autopilot, since that's a private API
<thomi> maybe add them to lp:autopilot, so we can remove them in uut
<veebers> thomi: ok, just checking them out now to see what's involve
<veebers> d
<veebers> thomi: oh and there was the issue that doanac brought up, but I saw that on my system regardless of which autopilot was used, so I think it's an issue outside of autopilot (probably with the test etc.)
<doanac> veebers: its not an issue here: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4523/unity8-autopilot/
<doanac> we run each of those autopilot tests 1 by 1
<doanac> i'm not opposed to landing the branch, but it will cause 2 tests to fail in unity8 that aren't failing now
 * doanac has to step away for dinner
<veebers> doanac: How are the tests on that dash run? It says touch_ro, but I'm pretty confident that the unity8 tests won't run without installing the dep. deb?
#ubuntu-ci-eng 2013-10-03
<plars> rsalveti: mediaplayer still crashing: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4525/mediaplayer-app-autopilot/
<rsalveti> plars: that's because we didn't yet merge https://code.launchpad.net/~robru/mediaplayer-app/fix-1231418/+merge/188502, to disable it
<rsalveti> plars: scene selector is not supported at the current version, but the test is still there
<sergiusens> fginther, hey, the message at the end of https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/1850/testReport/junit/mediaplayer_app.tests.test_player_with_video/TestPlayerWithVideo/test_scene_selector_visibility_with_touch_/ feels very strange
<sergiusens> fginther, according to thomi 1.2 was last used on precise
<thomi> fginther: it's *aaaaaages* old :)
<sergiusens> a rerun proved it to be a casual thing, but still brings in some worries
<plars> ah, ok
<rsalveti> sergiusens: https://code.launchpad.net/~sergiusens/phablet-extras/qtmultimedia-touch-quick/+merge/188962 please only add quick for the mir case
<rsalveti> sergiusens: there's another block bellow, mir: {
<rsalveti> with a QT += opengl
<rsalveti> add it there
<sergiusens> rsalveti, rar, ack
<sergiusens> rsalveti, switching channels are we?
<rsalveti> sergiusens: just used the wrong one
<rsalveti> as you were talking here
<rsalveti> too tired as well haha
<sergiusens> rsalveti, I'm everywhere :-P
<sergiusens> rsalveti, being pushed
<sergiusens> rsalveti, pushed
<rsalveti> sergiusens: thanks
<sergiusens> rsalveti, what's the equiv of bzr push --overwrite btw?
<rsalveti> sergiusens: with git?
<sergiusens> rsalveti, yeah
<rsalveti> sergiusens: git push -f
<sergiusens> rsalveti, ty sir
<rsalveti> sergiusens: added your lxc-android-config change to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=0
<rsalveti> sergiusens: now to hope people can agree that this can land tomorrow
<sergiusens> rsalveti, well it avoids races ;-) just add that ;-)
<doanac> veebers: yeah. its a ro image where we enable developer-mode.
<doanac> and then install the unity8-autopilot package
<veebers> doanac: understood, cheers
<fginther> thomi, ping
<thomi> fginther: hey
<fginther> thomi, regarding the 1.2 protocol issue sergiusens brought up. which side is using 1.2?
<thomi> fginther: the backend driver - I guess libautopilot-qt
<thomi> in fact, '1.2' means 'unversioned', since we only started versioning it in 1.3. AP assume that anything unversioned is '1.2'
<fginther> thomi, thanks, I'll see if I can find any evidence along those lines
<rsalveti> starting new build, which should include the regression fix for ringtone/sms notification sound
<thomi> fginther: still awake?
<thomi> is anyone here able to spin us a custom phablet image with new mir, unity-mir and platform-api?
<rsalveti> ogra_: lool: 78 is looking good, it's expected to have at least one failed test with mediaplayer-app, as scene selector is not supported anymore
<rsalveti> we have a pending MR to fix that: https://code.launchpad.net/~robru/mediaplayer-app/fix-1231418/+merge/188502
<didrocks> Mirv: hey, how are you?
<Mirv> didrocks: morning, fine, bit more normal day today
<didrocks> heh ;)
<Mirv> didrocks: ui toolkit is no good at the moment, I'm now testing the qtdeclarative separately
<didrocks> Mirv: ah ok ;) good that you detected this!
<didrocks> Mirv: can you please try to release all the rest that we can?
<didrocks> (if sil2100 gave some instructions)
<didrocks> I think we're going to publish the current image
<Mirv> I haven't received anything from sil2100
<didrocks> and he didn't write anything on the spreadsheet?
 * didrocks checks
<Mirv> to the libusermetrics that there's some AP tests problems he's having, on the unity-scope-home there isn't anything I think
<didrocks> Mirv: can you look at libusermetrics? The tests will take 5 minutes I guess
<Mirv> didrocks: yeah, I can stop this declarative testing for a bit and test it instead
<didrocks> Mirv: thanks, just do in whatever order you want
<jibel> on the dashboard, http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/ what does the build number mean?
<jibel> for example 78:20131003:20131002.1
<jibel> there are 2 build ids in the string
<jibel> ..03 and ...02.1
<didrocks> Mirv: once you are done with the current ones, let's discuss about the Mir thingy (give me a head's up)
<didrocks> jibel: oh interesting, it was always the same ones repeated before
<didrocks> jibel: TBH, I don't know :/
<jibel> didrocks, sorry :) also sometimes people speak with image number (77,...) and sometimes in build number 20131003,... is there a way to know which correspond to what
<didrocks> jibel: oh, for that one, sure
<didrocks> jibel: so basically 20131003 is the ubuntu part
<jibel> for example in media-info I can find the build id but don't know to which image number it corresponds
<didrocks> (containing only the android bits)
<didrocks> when you merge it to the android part (which can change even if you didn't rebuild any ubuntu part), you get the real "id" for the image
<didrocks> which are those numbers, 76, 77â¦
<didrocks> to find them, they are in front in the dashboard
<didrocks> this is how you can spot them :)
<didrocks> 78:20131003:20131002.1 -> image 79
<didrocks> oupss
<didrocks> 78:20131003:20131002.1 -> image 78
<jibel> didrocks, so in summary, when plars sent a message with tests results for image 77, I must go to the dashboard to know that 77 is 02.1, correct?
<didrocks> jibel: right, we should promote this number as well, it's the real uid for the image
<jibel> thanks
<didrocks> jibel: just be warned, you can have 2 images with 02.1
<didrocks> like 77 and 78 can be 02.1
<didrocks> if we just rebuild the android part
<jibel> understood.
<didrocks> jibel: so, we are going to have Mir fixes today
<didrocks> we'll probably need the same round of testing than yesterday
<jibel> didrocks, good, I'm continuing manual testing of MIR anyway
<jibel> and found other issues, like pip not working for pinned app, and details like this
<didrocks> jibel: well, if only we had some "details" to fix like that, I would be happy
 * didrocks just locked his phone again
<jibel> high CPU usage under MIR is a killer. unity8 never goes below 100%
<didrocks> jibel: I put it as a showstopper yesterday but management disagreed
<didrocks> Mirv: FYI, I just prepare (merging, updating config and kick a rebuild) to be ready for the new Mir stack
<Mirv> didrocks: ok, thanks. still takes a bit of time before I'm ready for that.
<didrocks> Mirv: yw! at least, it should be built by then, so less wait :)
<didrocks> Mirv: as upstream don't merge the build-dep bump, everytime I'm doing that myself FYI
<didrocks> (the upstream merger can't merge because the new Mir version isn't there)
<sil2100> Morning!
<sil2100> didrocks: why hud got marked as FAILED? I still see the sync request on the unapproved queue...
<Mirv> didrocks: ok, could you sponsor lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src_5.0.2 ? all tests pass, and I also received separate testing from Chris Wayne / Matthew Fischer that they are very happy with its fix
<didrocks> hey sil2100!
<didrocks> sil2100: hum, but you told that some AP tests were failing, right?
<didrocks> Mirv: \o/
<sil2100> didrocks: yes, but it wasn't because of HUD - as I had the same problems and couldn't really get any solid results when using vanilla 75 ;)
<sil2100> didrocks: all was ok on image 70 with the new hud
<didrocks> sil2100: ah ok, please change the status then
<sil2100> didrocks: I'll try to bisect as ogra_ advised what's wrong that 75 suddenly 'burps'
<didrocks> Mirv: did you start on the home scope?
<Mirv> didrocks: not yet
<Mirv> didrocks: libusermetrics now in archive
<didrocks> sil2100: look at the latest results, all is green, so you should just reflash with that one
<didrocks> Mirv: \o/
<didrocks> ok, so now that sil2100 is here, let's sum up
<sil2100> Mirv, didrocks: wasn't robru supposed to do that?
<Mirv> sil2100: it's marked to you only in the chart at least
<sil2100> didrocks: reflashing then \o/
<didrocks> sil2100: he wasâ¦ apparently, he couldn't get his laptop working and so, he didn't process anything
<robru> sil2100, i cannot access launchpad all day, so I can't install anything from PPAs, so I can't test anything before publishing. I emailed you about this.
<sil2100> Mirv: hum, yesterday it was marked for robru, as I gave it to him since he didn't have any tasks
<didrocks> Mirv: yeah, but I ask robru to coordinate with sil2100 on his end of day
<didrocks> robru: is it better now btw?
<Mirv> I could run the scope-home unity7 tests, although I need to switch to a different machine then for working (which is still ok, I've a spare one)
<sil2100> robru: ah! Ok, didn't open my mail yet ;) ACK
<Mirv> I've at least a known-good unity7 test machine here
<didrocks> or you can't still access to LP?
<didrocks> Mirv: great ;)
<didrocks> so what I propose
<didrocks> Mirv -> home scope
<sil2100> Reflashing the device
<didrocks> sil2100: apparently AP has some fixes, so worth another try
<robru> didrocks, hum, no, still bad. I opened an RT for it, and I'll ping #is in the morning.
<sil2100> didrocks: you mean the new AP?
<didrocks> robru: ok, good luck
<didrocks> sil2100: yeah, new AP /!\ look at your emails, I forwarded to you. There are 2 projects that needs some additional merging
<didrocks> sil2100: ignore the toolkit one anyway (maybe it should just be merged), as Mirv tested, it's not a good shape
<didrocks> Mirv: I think you pinged pustream btw about the sdk?
<didrocks> and then, Mirv -> Mir once built
<Mirv> didrocks: ok, home scope. sdk upstream knows about the issues, yes.
<didrocks> Mirv: have you opened a bug? (some upstream wants paperwork to tack)
<didrocks> track*
<Mirv> didrocks: well hmm, it's more like 'it's all broken' (some mainview issue as indicated by zsombor), but yeah I'll file a bug as well
<didrocks> Mirv: all? waow ;)
<didrocks> ah, I guess sil2100 edited the wrong line
<didrocks> the sdk "FAIL" one instead of the hud
 * didrocks fixes
<Mirv> didrocks: well the toolkit's own tests pass, but apps AP:s break quite badly
<didrocks> interesting
<didrocks> Mirv: anyway, thanks for spotting/testing carefully ;)
<Mirv> sil2100: FYI for your AP problems, please make sure you wait after boot until the nautilus windows pops up for Nexus. at that point the connection breaks so if you started phablet-test-run before, it won't work. also note the home screen unlocking needed mentioned by ogra.
<sil2100> :|
<sil2100> Missed the rows it seems...
<robru> didrocks, sil2100, Mirv: is powersaving still broken in desktop xorg? I remember that being broken ages ago but I just now noticed that my screen has been on all evening after many hours of inactivity...
<sil2100> Mirv: I'm running it clean through SSH, so I'm always unlocked - and the tests were running, but suddenly after a while either unity8 or autopilot itself hangs up on dont-know-what and waits indefinitely
<sil2100> Unable to being properly killed
<didrocks> robru: hum, working here, would worth trying to kill g-s-d and get it restarted
<Mirv> sil2100: you shouldn't run it through SSH but use phabllet-test-run
<didrocks> yeah
<didrocks> phablet-test-run is the way to go
<didrocks> like phablet-test-run -p <app autopilot package name> -n <autopilot test>
<didrocks> (/!\ -p should be before -n)
<Mirv> I tend to run non-unity8 AP:s without -n, and unity8 with -n, seems to work
<sil2100> Mirv: last time people told me not to use phablet-test-run for normal tests
<didrocks> Mirv: yeah, I don't really know about the magic, I just know the infra always use -n from what I heard
<sil2100> Damn, I think my Nexus got bricked?
<didrocks> sil2100: reflash with --no-backup (will erase the whole config)
<Mirv> sil2100: hmm, I've never heard that
<sil2100> didrocks: I tried to use -n always, but most tests were failing then
<didrocks> weird, not the case for me :/
<Mirv> sil2100: phablet-flash ubuntu-system --channel devel-proposed -b
<didrocks> Mirv: with --no-backup
<sil2100> Mirv: will it work when it's stuck on the Google screen?
<didrocks> ah, maybe that's -b
<didrocks> sil2100: if you can adb shell, yeah
<sil2100> Yeah, busybox
<didrocks> ok, -b implies --no-backup
<Mirv> didrocks: bootstrapping (-b) wipes out everything anyway, it's even more powerful than --no-backup
<vila> sil2100: when stuck on the Google screen, the trick I use is to reboot in recovery mode. From there, phablet-flash find its way
<didrocks> yep
<sil2100> ERROR:phablet-flash:Unsupported device, autodetect fails device :o
<sil2100> vila: will try that
<jibel> why would you run app tests with -n, it stops unity8 and running apps without it is not the way users do
<didrocks> sil2100: yeah, you need to specify -d mako then
<jibel> sil2100, add -d <devicename>
<didrocks> (IIRC, you have a mako)
<vila> sil2100: and I don't even use -b nor --no-backup (it's hard enough to retype the contacts I forgot to transfer to the sim before cutting it into a nano sim that I haven't tried hacking to put it back in my other phone, sorry this parenthesized stuff is getting far longer than expected ;o)
<didrocks> jibel: well, seems that upstream design AP tests without the shell running, and that's why you get more failures than the infra does
<didrocks> vila: it's better to do run with --no-backup at least
<didrocks> like you detect more issues
<sil2100> vila: right now I only use it for testing purposes, so I only have the WiFi password on it - so I'll bootstrap it from 0 I guess
<didrocks> like 4 images ago, all the crashes was due to having a fresh user
<didrocks> so it's not the same testing without --no-backup
<jibel> didrocks, you're not doing integration tests then
<vila> didrocks: /me nods
<didrocks> jibel: well, tell that to upstream :)
<didrocks> jibel: I don't deny it at all, just telling what's the current situation
<vila> didrocks: but it's a trade-off, I try to use it as my main phone
<didrocks> I hope you can convince them ;)
<didrocks> vila: yeah, but be aware that's not what we should do in that team as we need to ensure people flashing their device can at least having application starting :p
<didrocks> which wasn't the case if you start fresh in that example
<didrocks> jibel: do you know if anyone apart from lool can promote an image?
<didrocks> (lool will be around later today)
<vila> didrocks: understood, but I know some other people are testing this way, variety is important for testing too
<jibel> didrocks, no idea
<didrocks> vila: yeah, but we at least need some people testing it the "fresh way" as well
<sil2100> didrocks: that's sad, since last time I heard they said they only used -n for the unity8 tests - didn't remember they did it for all of the tests ;) But I might have misunderstood?
<didrocks> vila: I don't think we support migrations yet
<didrocks> sil2100: well, that's what I heard, I didn't look at the utah code
<didrocks> jibel: ok, we'll wait for him I guess
<didrocks> sil2100: flashing working?
<Mirv> didrocks: unity-scope-home seems to require newer libunity as well (libunity-protocol-private0)
<Mirv> diff being http://bazaar.launchpad.net/~unity-team/libunity/trunk/revision/299
<sil2100> didrocks: it seems to proceed this time, phew
<Mirv> I don't see how the protocol-scope-discovery.vala change relates the the commit comment though
<didrocks> Mirv: ok, feel free to test with it (but please do some unity7 testing a little bit more rigourusly then)
<didrocks> hum, 7.1.1
<didrocks> Mirv: don't we have 7.1.2 already?
<didrocks> Mirv: let me look at the home scope code
<Mirv> didrocks: yes, the actual package dependency is protocol-scope-discovery.vala
<Mirv> I mean, >= 7.1.2+13.10.20131002.2
<didrocks> Mirv: oh, you're right
<didrocks> Mirv: ok, please try with both (and only those)
<didrocks> just ensure we don't regress unity7 in particular :)
<didrocks> sil2100: to prepare and test AP, should be stage one version in the ppa or you want to build trunk yourself?
<sil2100> didrocks: I see some autopilot package in the daily-build PPA right now - it's not the trunk version that needs testing?
<didrocks> sil2100: it's the trunk version we want to test (see the email I forwarded to you as well)
<didrocks> + some additional fixes in some packages
 * sil2100 wonders why the merges didn't get top-approved yet
<didrocks> sil2100: I think that they are failing without the new AP
<didrocks> so chicken and egg issue
<didrocks> (or no backward compatibility)
<sil2100> didrocks: I know, but even the autopilot branch didn't get top-approved, and CI only had success on it
<didrocks> argh
<didrocks> veebers: around, do you know why? ^
<sil2100> veebers, thomi: ^? It's approved 2 times but not top-approved, I don't see a reason for that?
<sil2100> https://code.launchpad.net/~veebers/autopilot/fixing_backend_being_none/+merge/188762
<sil2100> didrocks: to test I would have to build this branch locally anyway
<didrocks> sil2100: yeah, please do then, sorry for the additional work :/
<xnox> rsalveti: lool: sorry for the noise, but yeah those changes are correct. (the target was not reliable & relies on internet access which fails on the buildds so I did back that out.)
<xnox> git log, will clearly state that I did intentionally reverted.
<sil2100> didrocks: will take a moment as my armhf building is not top-speed
<didrocks> sil2100: hum, not sure you need to build on armhf
<didrocks> sil2100: for autopilot at least
<didrocks> they are all arch: all, no?
<sil2100> No, autopilot-touch is any
<didrocks> yeah, it's a mistake btw
<didrocks> seems it's just a metapackage
<sil2100> But it's finishing now ;)
<didrocks> ah,but there is a dep
<didrocks> anyway, ok ;)
<didrocks> sil2100: so, I would say: try everything that doesn't need a patch
<didrocks> if they pass, then, try the last 2 ones :)
<didrocks> (I guess sdk and unity)
<ogra_> didrocks, i'm partially around atm, in case you want to have 78 released (after manual call tests)
<ogra_> (for the next hour or longer)
<didrocks> ogra_: oh please please! :)
<didrocks> ogra_: promote it!
<didrocks> (I dogfooded it this morning)
<ogra_> didrocks, did someone do call/sms tests ?
<didrocks> I don't think about that one, popey around? ^
<didrocks> ogra_: I don't have a sim card :/
<ogra_> (incoming calls and sms, do they produce sound ?)
<ogra_> right, so lets wait for popey to do one :)
<popey> ya
<didrocks> (yeah, they are supposed, the fix is in, so I guess it was tested)
<didrocks> popey: hey!
<popey> yo
<ogra_> my maguro battery is dead :(
 * seb128 click update (78), 100M to download, some people have been busy ;-)
<didrocks> popey: so image 78, we just need the call/sms tests
<popey> 09:18:38 < popey> Huzzah! Ringing and sms tones works in image 78
<didrocks> \o/
<popey> :D
<seb128> ogra_, popey just said they do
<popey> timing++
<ogra_> ah, i didnt read the backlog
<didrocks> ;)
<didrocks> ogra_: well, it was at the same minute that we discussed it here
<ogra_> should we just assume they do as well on maguro ?
<didrocks> ogra_: I would assume TBH
 * ogra_ thinks there was no HW specific issue
<ogra_> right
<ogra_> lwets release that thing :)
<didrocks> yeah, it wasn't HW specific
<didrocks> ogra_: \o/
 * popey prepares a mail
<didrocks> ogra_: then, now, enjoy your national holiday :)
<popey> 78 is 20131003 right?
<sil2100> \o/
<popey> wow, was 70 really the last one we pushed?
<popey> time flies
<veebers> sil2100, didrocks: That's odd, I'm sure thomi said he had top approved this: https://code.launchpad.net/~veebers/autopilot/fixing_backend_being_none/+merge/188762
<ogra_> done, give it a few minutes to promote and sync ...
<sil2100> veebers: it seems he just double approved it instead! Let's top-approve it then ;)
<veebers> sil2100, didrocks: Hmm, I think we got our lines crossed, he approved but not top approved :-\
<ogra_> popey, right, 20131003/78
<veebers> sil2100: sounds good to me :-)
<veebers> it also looks like the merge here failed due to network/apt issues: https://code.launchpad.net/~veebers/unity/fixing_ap_tests_for_updated_autopilot/+merge/188969
<sil2100> veebers: thanks for the branch btw.! I'm testing it right now, so far so good
<veebers> sil2100: nw, awesome news
<didrocks> popey: yeah, 2 days ago :)
<popey> 81MB!
<popey> Monster
<didrocks> popey: quite easy (my fiber connection was just updated to 1Gb :p)
<lool> didrocks: I'm here
<lool> didrocks: you wanted to promote an image?
<lool> I guess ogra_ did already
<didrocks> lool: we just did it
<didrocks> (like 9 minutes ago)
<lool> cool
<didrocks> sil2100: joining?
<sil2100> Badum tsss
<Laney> didn't get the /etc/writable fix?
<seb128> hum, the ubuntu-download-manager is doing quite some syslog spamming
<Laney> I guess maybe I need to flash with --no-backup
<popey> http://popey.com/~alan/device-2013-10-03-094053.png
<popey> "Apply update failed: No update has been downloaded"
 * popey tries again
<lool> ogra_: joining HO?
<lool> vila: ?
<popey> better that time
<vila> lool: omw
<lool> ogra_: oh sorry, forgot
<Laney> no, it's still a file with --no-backup
<popey> Mail sent.
<sil2100> Damn, so far so good this new AP
<sil2100> I re-ran notes-app and the test failures were gone, so I guess they were flacky
<seb128> shrug, updates' "retry" seems not work
<seb128> 3 times upgrade fails on network errors and that I need to reboot the device to try again
<vila> seb128: while you're there, try changing your phone orientation and see the retry button covering... (can't remember the labels)
<seb128> vila, bug #1229374
<ubot5> bug 1229374 in ubuntu-system-settings "Update button doesn't work when orientation changes" [Low,Confirmed] https://launchpad.net/bugs/1229374
<vila> seb128: thanks, subscribed
<seb128> yw
<seb128> I wonder why screen rotation stopped working on the n7
<seb128> it used to work there
<vila> seb128: can't remember seeing it working there
<seb128> it was, when I enabled screen rotation in system settings, I first tested on my n7
<vila> ha right, system settings is where I realized rotation was working, but that was on mako
<sil2100> didrocks: all tests passed on my device - I even updated to the uitoolkit branch that veebers prepared, ran UI toolkit tests and it was green
<sil2100> didrocks: but the AP branch didn't get yet merged in, now there was some connection/apt problem on amd64 during autolanding...
<sil2100> didrocks: not sure what to do with the UI Toolkit one, since we don't want to release UI toolkit for now, right
<sil2100> ?
<lool> sil2100: awesome news on new AP  :-)
<didrocks> sil2100: sorry, was discussing with lool
<lool> sil2100: new UI toolkit >> right, I think we want the old UI toolkit to pass with the new autopilot
 * didrocks backlog
 * lool school and lunch 7
<didrocks> sil2100: \o/
 * lool school and lunch &
<didrocks> sil2100: can we backport veeber's fix in the current ui toolkit package?
<didrocks> maybe that would be a way :)
<sil2100> didrocks: I'll check how bad is it with the old UI toolkit - if it's bad, I'll try backporting
<sil2100> But I guess backporting might be needed ;)
<didrocks> sil2100: yeah, so current package + this merge only
<didrocks> let's cross fingers ;)
<didrocks> Mirv: psivaa: jibel: Mir ready in the ppa
<didrocks> so mir + unity-mir + platform-api (+ unity-system-compositor on desktop)
<didrocks> I guess install iamge #79 and running those ^
<psivaa> didrocks: ok, i was just getting http://pastebin.ubuntu.com/6187395/ but may be i am too early?
 * didrocks tests on destkop meanwhile
<didrocks> psivaa: they are at libmirserver5 now!
<psivaa> didrocks: ack, will install that. thanks
<didrocks> yw ;)
<Laney> ABI addicts
<sil2100> Wait, mirserver5 really?
<didrocks> for real!
<didrocks> sil2100: do you think we'll be able to publish autopilot before 12 UTC?
<didrocks> sil2100: oh, we need to rebuild it in the ppa btwâ¦
<sil2100> didrocks: depends on if the merges will get in ;/ I can manually merge them in if needed, but since rebuilds will have to happen I somehow doubt targetting before-12
<didrocks> sil2100: well, ok, let's try to rebuild autopilot meanwhile
<didrocks> sil2100: is the unity patch in? we can rebuild it?
<sil2100> didrocks: it's approved since 1 hour, but still not merged in - I guess CI is building it still
<didrocks> sil2100: ok, let's rebuild autopilot for now
<didrocks> sil2100: keep me posted on the sdk, I can't wait ;)
<didrocks> nice that latest unity7 is fine as well under AP!
<didrocks> sil2100: well, I think if we don't push unity7, it's not that a biggie anyway
<didrocks> (as long as the patch is merged)
<didrocks> sil2100: autopilot rebuilding
<sil2100> \o/
<sil2100> I cherry-picked the fix to ubuntu-ui-toolkit, I'll do a test-build too but anyway propose the change to the packaging branch
<didrocks> excellent!
<sil2100> didrocks: https://code.launchpad.net/~sil2100/ubuntu/saucy/ubuntu-ui-toolkit/manual_merge <- should I do a MR?
<sil2100> And should I change it from UNRELEASED to saucy already?
<sil2100> It's still building here
<sil2100> Actually...
<sil2100> Let me not waste time for building the armhf package
<didrocks> sil2100: I think you don't need to merge that branch, do you?
<didrocks> sil2100: you just need to merge the changelog back to the upstream branch
<sil2100> I'll downgrade to old UI toolkit and just push that modified file directly and check if it works
<didrocks> (once we upload manually)
<didrocks> yeah ;)
<didrocks> sil2100: hum, modified file?
<didrocks> you mean, you push the diff?
<Mirv> didrocks: ok!
<didrocks> (as the file maybe contains more)
<didrocks> Mirv: have you finished libunity + scope-home? (just looking at the unapproved queue)
<sil2100> Yes, I actually meant the file, since I can use the manual_merge branch, and it's the UI toolkit in-archive-source with that diff applied ;) No worries, testing!
<Mirv> didrocks: I needed to start a rerun of the Unity7 tests, some autopilot error happened. I'm testing it manually on another machine as well.
<didrocks> ok
<sil2100> didrocks: oh! I just now noticed the 'UTC' in 12 UTC
<sil2100> didrocks: till 12 UTC I guess we'll make it ;)
<didrocks> sil2100: ok ;)
<ev> apw, infinity: the patch in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147 (inotify support in overlayfs) was determined to not cover some particularly important scenarios, right? Do either of you know if work is being done elsewhere to add this support?
<ubot5> Ubuntu bug 882147 in coreutils (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,In progress]
<Mirv> ok, now had a good run!
<Mirv> publishing libunity + unity-scope-home.
<apw> ev, i have some half baked patches which might cover 'most' of it, but they arn't ready to use, and i know of noone else doing anyting indeed.  plus it is definatly not clear you can close the gap entirely due to a semantic gap
<ev> apw: could we say, "on overlayfs it works, but here are the drawbacks" with your patches? Without looking at them, some support is better than none
<Mirv> didrocks: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Unity/job/cu2d-unity-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.1.2+13.10.20131003-0ubuntu1.diff
<apw> ev, they are not in a state to apply to saucy and upload no
<ev> and it would help us improve provisioning speed
<Mirv> (packaging ack)
<ev> apw: *nods*
<didrocks> Mirv: yeah, sounds good (I approved it upstream in fact ;))
<apw> ev, they last built against raring, and with all this touch work going on we haven't had the time to progress
<Mirv> didrocks: ah, thanks
<didrocks> Mirv: nice on libunity + scope-home \o/
<ev> apw: so would it just be a matter of priority to get done in 14.04?
<sil2100> didrocks: ran the tests 2 times, every time I got 1 failure, but each time a different one - so I guess it's a flacky test
<sil2100> didrocks: so I think +1 for manually uploading that cherry-picked branch
<didrocks> sil2100: ok, please do ping upstream about those, but don't block on that
<didrocks> sil2100: yeah, let's do that \o/
<sil2100> didrocks: should I modify that branch from UNRELEASED to saucy or will you do that when uploading :) ?
<didrocks> sil2100: you do publish autopilot and give me a debdiff for the sdk + merge back the packaging branch upstream?
<sil2100> didrocks: I'll then prepare a merge-back with the changelog
<sil2100> didrocks: ACK
<didrocks> sil2100: want to try to give me a debdiff?
<didrocks> (so that it changes a little bit ;))
<apw> ev, it would need to be a decision we could spend time on it yes
<sil2100> didrocks: http://paste.ubuntu.com/6187531/ <- debdiff, taking care of autopilot
<sil2100> didrocks: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/QA/job/cu2d-qa-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_autopilot_1.3.1+13.10.20131003.1-0ubuntu1.diff ACKed? ;)
<didrocks> sil2100: hum, do you know why this dpkg-dev, build-dep?
<didrocks> "  Add missing dependency to python-autopilot-tests package.
<didrocks> "
<didrocks> doesn't really tell anything
<didrocks> ah, they are running dpkg-query
<didrocks> in their tests
<didrocks> ok, then, +1
<cjwatson> didrocks: Is it a versioned build-dependency?
<didrocks> cjwatson: it's not a build-dep (was caught by the diff, but a dep on their -test package
<cjwatson> Oh, runtime
<cjwatson> But dpkg-query is in dpkg, not dpkg-dev
<cjwatson> And dpkg is Essential
<didrocks> oh indeed, I thought it was in dpkg-dev
<didrocks> sil2100: ok, so let's fix that upstream, making a MP?
<sil2100> didrocks: changing dpkg-dev to dpkg, yes? Or removing it completely?
<didrocks> sil2100: removing as it's part of dpkg which is essential
<didrocks> veebers: thomi: FYI ^
<cjwatson> Where was the original commit for this change?
<didrocks> 12:20:11 didrocks | "  Add missing dependency to python-autopilot-tests package.
<didrocks> 12:20:11 didrocks | "
<didrocks> cjwatson: ^
<didrocks> not really helpful
<cjwatson> x/usr/share/pyshared/autopilot/tests/functional/test_introspection_features.py:107:                    ["dpkg-architecture", "-qDEB_HOST_MULTIARCH"]).strip()
<didrocks> dpkg-architecture
<cjwatson> that would require dpkg-dev
<didrocks> ok, that one
<didrocks> so yeah
<didrocks> sil2100: keep it for dpkg-architecture
 * didrocks would like more helpful commit message (and ping to packagers first for packaging changes)
<didrocks> sil2100: so, is there anything else on your list or you can help on the Mir force? ;)
<didrocks> (nice work btw!)
<sil2100> didrocks: I'll just push the branches, make sure stuff is merged and release thumbnailer quickly so that people can be happy
<didrocks> sil2100: great!
<didrocks> popey: it seems rick is seeing his sms messages getting deleted, do you see that with latest images?
<popey> didrocks: deleted how?
<popey> disappearing?
<didrocks> popey: apparently yeah, but maybe there are just getting mixed when changing TZ
 * popey sends a few 
<didrocks> popey: ok, in fact, it's just an order issue
<didrocks> like if you change you TZ
<didrocks> they appear in the past
<didrocks> so before your latest ones
<popey> ahhh
<popey> will be more pronounced as he's changing fron UTC to UTC minus some hours?
<didrocks> popey: yeah, if you try that and send a sms after switching to the past :)
<popey> heh
<didrocks> I guess the messages are stored with local time, but no TZ information
<didrocks> popey: maybe ubuntu touch can decide that TZ are confusing and we deprecate that? ;)
<popey> YES!
<popey> Lets make everyone use UTC and remove all TZ features
<didrocks> heh ;)
 * didrocks regrets that online music search works (seeing what I have to endure right now and can't stop the music :p)
<popey> :D
<popey> whenever i take screenshots of the music app I always orchestrate them so my leas embarrassing songs are on the screen
<davmor2> popey: yeah you just go for novelty tracks instead, Mr blobby, Postman pat, Agadoo :D
<davmor2> popey: don't worry we all know you love beiber really
<Mirv> didrocks: psivaa: ok my mir results in the chart. notes_app 1-2 failures depending on the run, not being able to run unity8 tests (the mock version doesn't come up). on the upside video/audio works, autopilot works at least partially, full cpu usage always seems gone.
<didrocks> Mirv: waow, excellent news! you didn't test  on desktop, right?
<psivaa> Mirv: didrocks: hmm not sure what i am doing wrong (on maguro) i have 20/23 notes app failures
<psivaa> Mirv: i dont see much difference in the results to yesterday's run with mir enabled
 * didrocks reboots, back shortly
<Mirv> psivaa: for me the main difference in test runs is that yesterday nothing really happened on the device when running phablet-test-run, but now it really runs the tests
<Mirv> psivaa: it might be worse on maguro, but 3 tests succeeding means something got run at least
<psivaa> Mirv: ok, understand :)
<didrocks> Mirv: +1 on the desktop side
<Mirv> didrocks: yeah I just rebooted on the updated desktop as well
<didrocks> Mirv: so, if you want to publish all of them, be my guest (didn't check packaging changes though) ;)
<Mirv> didrocks: ok, I'll check if there are packaging changes. this is an improvement at least.
<didrocks> yeah ;)
<didrocks> psivaa: did you figure out why it's more an issue for you than Mirv?
<didrocks> (as I rebooted, didn't follow the conversation)
<Mirv> didrocks: maybe maguro is worse, but we concluded that at least something got run on maguro at least well, as opposed to yesterday when autopilot didn't work at all
<Mirv> didrocks: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Platform/job/cu2d-platform-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_platform-api_0.19+13.10.20131003-0ubuntu1.diff
<psivaa> didrocks: no.. but apparently Mirv has nearly same results. i was complaining that the pass rate did not improve to me with mir when compared to yesterday
<Mirv> didrocks: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Mir/job/cu2d-mir-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_mir_0.0.13+13.10.20131003-0ubuntu1.diff
<Mirv> didrocks: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Mir/job/cu2d-mir-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-system-compositor_0.0.1+13.10.20131003.1-0ubuntu1.diff
<Mirv> psivaa: so you did get 20/23 also yesterday?
<didrocks> Mirv: +1 on all
<psivaa> Mirv: i got 19/23 yesterday
<Mirv> psivaa: ah ok, I just concluded yesterday that it all fails. maybe maguro improved less then.
<Mirv> didrocks: finally, http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Unity8/job/cu2d-unity8-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-mir_0.1+13.10.20131003.1-0ubuntu1.diff
<psivaa> Mirv: quite possible
<psivaa> Mirv: I think the reason for AP failures is bug #1232054 , which has not been fixed i suppose
<didrocks> Mirv: easy +1 as well :)
<ubot5> bug 1232054 in unity-mir "[mir] Need to expose geometry for autopilot consumption" [Critical,In progress] https://launchpad.net/bugs/1232054
<didrocks> psivaa: hum, this one was supposed to be fixed
<didrocks> psivaa: but it was already in image 75
<psivaa> didrocks: still says in 'In progress'
<didrocks> psivaa: yeah, I think they just didn't reference it in the changelog, I updated it (we have it)
<didrocks> psivaa: so not that one
<didrocks> psivaa: you are going to publish the new results, like yesterday? (with Mirv's one)
<psivaa> didrocks: you mean in the landing plan?
<didrocks> psivaa: hum, no, yesterday, I saw a google doc
<didrocks> with the test results
<psivaa> didrocks: yes, i'll add my results to that one, google doc
<didrocks> excellent, thanks!
<didrocks> psivaa: so unity8 tests are not starting still?
<psivaa> didrocks: left to the last.. still running.
<Mirv> didrocks: ok published mir, unity-system-compositor, platform-api, unity-mir
<didrocks> Mirv: \o/
<Mirv> and "phew", I need to have a break
<didrocks> ;)
<didrocks> well deserved one!
<didrocks> (and thumbnailer in, nice sil2100!)
<ev> didrocks: Did lightdm get switched over to manual publication? Just going back through email missed while I was on holiday.
<didrocks> ev: it's still manually uploaded, we didn't want to stage it in the ppa and decided to wait post V1 to change that
<ev> okay, thanks!
<didrocks> yw ;)
 * didrocks out for some exercise
<cjwatson> Mirv: I don't see the unity-lens-applications part of landing number 88 anywhere in the queue
<cjwatson> accepted the rest
<cjwatson> sil2100: landing number 74 (hud) - I don't quite understand column H, does that mean that this is/isn't OK to accept from unapproved?
<cjwatson> ... never mind, somebody else already did.  certainly doesn't look like it should break tests!
<kgunn> plars: ping
<sil2100> cjwatson: no, it's ok to move it, as I had problems with running tests on my device then - but dogfooding and using earlier images made me publish it
<kgunn> Mirv: thanks for the publishing work!
<lool> == Building click-package stack ==
<lool> this is to pickup a click-update-manager icon bugfix
<lool> hmm why did it disappear from results
<cjwatson> new mir stuff -> inarchive
<cjwatson> new unity-scope-home / libunity -> inproposed, except for above question about whether there's still unity-lens-applications to come
<cjwatson> qtdeclarative -> inproposed though building, dunno if you want to annotate that separately
<cjwatson> and hud debug changes -> inproposed
<Mirv> cjwatson: right, the applications part wasn't released yet. thanls for the rst
<cjwatson> want to note that in the landing plan somehow?
<cjwatson> if we have to have this thing it probably ought to be correct :)
<Mirv> cjwatson: yeah, done, we discussed the home scope and its libunity dependency so much that the small apps lens got sidetracked..
<cjwatson> Mirv: OK - it's not inarchive yet though
<cjwatson> it's waiting for autopkgtests according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<cjwatson> check rmadison before setting to inarchive, otherwise people may think they can run image builds and pick up your change
<Mirv> cjwatson: yeah, I just checked also that still in proposed
<psivaa> jibel: jfunk: is there a reason why the mir testing results for image 78 is removed from https://docs.google.com/a/canonical.com/document/d/1b-X9tN2Q9c_5r39XzA-Ppebbjuin5zVf9SkAGMcdp9Q/edit#
<cjwatson> hud is publishing to release at the moment
<jibel> psivaa, interesting, I don't know who did that. I'll find who and get them back
<psivaa> jibel: i think from rev history it was jfunk :)
<jibel> psivaa, ah, is has been moved to the top of the doc
<jfunk> sorry guys
<jfunk> I am reporting to the UE Leads and have a bit of OCD with these type of things
<jibel> jfunk, np, it's easier to read this way
<psivaa> jibel: jfunk: ahh my bad too.. sorry
<fginther> morning
<ralsina> lool: landing ask row 74 is already landed
<lool> ralsina: thanks, cleared
<lool> didrocks: tested new system-image, seems ok but with some glitches
<lool> didrocks: 2 secs
<lool> didrocks: alright, hinted system-image + lxc-android-config in
<lool> didrocks: so for system-image what I got was: 1) first I saw 100% progress briefly, 2) then I saw 0% progress almost immediately, 3) then it stayed on 0% for a while, but I don't have super good wifi here, moved closer to the AP, 4) after 20 seconds or so, download started, I got progress update, 5) at the end got install & restart
<didrocks> lool: for 1) are you sure it was 100% or indeterminate?
<lool> didrocks: it said 100%
<didrocks> hum, the only thing I can see is that the daemon send UpdateProgress(100, noeta)
<lool> possibly
<lool> didrocks: are there logs?
<didrocks> lool: I think when doing an update, logging the system dbus can be interesting
<didrocks> I don't think there are logs on the UI side
<lool> didrocks: you could also have some logging on the UI side
<lool> right
<lool> I fear that logging all dbus traffic or even just download progress updates might be too much
<didrocks> lool: system bus should be ok, there isn't so much
<lool> we could log everything except progress messages which are not zero and not 100
<plars> kgunn: hi
<didrocks> yeah, a little bit late for that, but I agree
<didrocks> lool: so, are you going to block system-image for next image?
<didrocks> or do you still want it?
<didrocks> plars: nice to see a so green dashboard! (thanks for all the retrials on flacky tests)
<plars> didrocks: that wasn't me on 78, that image came in the midnight hours for me, if anyone retried that it was probably psivaa
<plars> didrocks: I saw though, the results looked really good
<lool> didrocks: I want it
<lool> didrocks: I unblocked it
<didrocks> psivaa: nice! :)
<lool> didrocks: it's strictly better than what we have
<lool> and we're landing 95% of features
<plars> psivaa: were there lots of retries needed, or did things mostly just work?
<didrocks> lool: ok, do you tihnk you want more? everything is nearly here for us, so I would love to see an image kicked soon
<lool> didrocks: can confirm url-dispatcher in a sec
<kgunn> plars: hey, sorry...keep getting interupts :)
<psivaa> plars: didrocks: i only reran mediaplayer tests once in both mako and maguro.. both passed on the retry
<didrocks> Mirv: missing app lens, wdym?
<didrocks> Mirv: oh, you missed that one?
<plars> psivaa: wow, that's not bad
<lool> didrocks: oh what do you think of the click-update-manager icon and the tests in the click-package stack?
<kgunn> plars: anyway, thomi was helping w/ enabling AP testing on mir
<psivaa> plars: the failures before that was due to a mediaplayer crash which did not happen on the retry.. on both devices
<didrocks> lool: it's under testing right, do you have an ETA?
<plars> kgunn: I believe we are still waiting on some autopilot pieces to land, aren't we?
<lool> didrocks: 5 minutes of testing + upload dance
<didrocks> plars: waow, not that bad then!
<plars> didrocks: ? ^ I thought it was supposed to land yesterday but I didn't see a new package
<didrocks> lool: ok, let's get that one in, sound safe enough
<kgunn> plars: yeah...they are in trunk but should be in image 79
<plars> ok, great
<didrocks> plars: kgunn: they are in the archive
<didrocks> so definitively will be in 79
<didrocks> psivaa: did you succeed in running the unity8 tests btw?
<lool> hmmmhmmm UI not coming up
<lool> lightdm start/running, process 1350
<didrocks> lool: for click?
<psivaa> didrocks: no.. 24/24 test failures  with mir enabled
<didrocks> or whole phone?
<lool> unity8 not coming up
<didrocks> psivaa: ok, but at least, you see the tests starting?
<lool> this is with SF
<psivaa> didrocks: yea
<didrocks> psivaa: unlinke yesterday when they even didn't start?
<didrocks> ok ;)
<didrocks> unlike*
<didrocks> lool: what did you install?
<plars> psivaa: was that with the new autopilot?
<lool> didrocks: url-dispatcher
<lool> I have the lxc-android-config stuff too
<lool> but it booted the first time
<didrocks> lool: retry a boot to see if something was flacky
<lool> so I'm tempted to try a reboot
<lool> didrocks: right
<didrocks> plars: the fixes are in mir itself (not autopilot)
<psivaa> plars:  1.3.1+13.10.20131003.1-0ubuntu1 is the autopilot-touch version
<lool> ah crap, load was high, should have checked that first
<lool> to late
<plars> did for some reason I was thinking there was an update to autopilot needed too, maybe not
<didrocks> plars: no, we did one, but unrelated :)
<plars> ack
<didrocks> the mir fixes are for AP
<didrocks> but not in AP ;)
<lool> I wonder if it's MTP with USB cable connected
<lool>   675 system    20   0  7020 1580 1224 S  85.4  0.1   0:38.98 sensorservice
<lool> ah fianlly came up
<lool> didrocks: I wonder whether I was not patient enough
<lool> boot is super slow these days
<didrocks> lool: do you have a .crash file?
<lool> tons
<didrocks> lool: maybe something crashed and you had apport collecting
<didrocks> ah :p
<lool> _usr_bin_maliit-server.32011.crash _usr_bin_unity8.32011.crash _usr_lib_arm-linux-gnueabihf_hud_hud-service.32011.crash _usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash
<didrocks> waow
<didrocks> nice strike!
<lool> but only one is recent
<lool> Hmm
<lool> there is weird timing on some of them
<lool> from this morning, despite having reflashed
<lool> this one is definitely interesting: -rw-r----- 1 phablet whoopsie 12083112 Oct  3 13:27 _usr_bin_unity8.32011.crash
<davmor2> lool: let me guess you have mir enabled
<lool> oh indeed
<lool> stupid me, forgot that this stayed across flashes
<didrocks> sil2100: around?
<sil2100> didrocks: yes!
<lool> davmor2: yeah, that's why it was slow
<davmor2> lool: the upstart-app-launch_zg only shows on mir
<didrocks> sil2100: I think Mirv forgot unity-lens-application from request 88, mind doing it?
<jibel> and maliit and hud crashes too
<didrocks> sil2100: should be quite quick to test (on both desktop and touch)
<didrocks> sil2100: just ensure that you have latest commit built in the ppa
<davmor2> jibel: true although you can get maliit crashes on sf too
<sil2100> didrocks: ACK!
<didrocks> thanks sil2100 ;)
<sil2100> didrocks: picking that up now
<lool> didrocks: ok, tested a bunch of URLs: applications:///, music:///, http://, settings:///, and video:///
<lool> didrocks: all good to go
<didrocks> lool: excellent! :)
<lool> pushing url-dispatcher
<lool> alone
<didrocks> lool: so then, you're on click, sil2100 on lens-apps
<didrocks> and we're good for 79?
<lool> didrocks:  hmm the build parameters seem different for misc stack
<didrocks> sergiusens: rsalveti: if you want something to get in 79, it's now (we are testing/uploading the latest things before kicking the next image)
<didrocks> lool: wdym? Maybe I missed a publish
 * didrocks looks
<lool> didrocks: like the new field to specify packages to act on isn't the same
<didrocks> lool: uno secundo
<didrocks> lool: ah, it seems with the list of deployement I missed one, one sec
<didrocks> lool: are someone redeployed without pulling latest
<didrocks> (which happens sometimes)
<kgunn> hey Mirv just reading landing notes where you say the following....
<kgunn> notes-app AP 1-2 failures depending on the run (notes_app.tests.test_delete.TestDelete.test_slide_to_delete_left+notes_app.tests.test_parts.TestFocus.test_parts_focus). managed to get the mako hanged once (adb shell not working).
<kgunn> unity8 autopilot runs (with -n) seemingly not possible, the mockup unity8 doesn't come up
<lool> didrocks: let's remind everyone to bzr pull latest cu2d later in the call
<kgunn> Mirv: can you elaborate on the unity8 -n, seemingly not possible ?
<didrocks> kgunn: yeah, didn't work for Mirv, seems to have worked (but all tests failed) for psivaa
<didrocks> lool: yeah, let's do that
<didrocks> lool: should be better now
<lool> hmm why did cupstream2distro-config diverge with my branch
<lool> I had pushed this stuff
<didrocks> lool: but definitively, we need to autodeploy when pushing a branch
<sergiusens> didrocks, is qtmultimedia-touch in?
<kgunn> didrocks: Mirv is that b/c it needs apt-get install unity8-fake-env
<didrocks> sergiusens: it's in
<didrocks> sergiusens: since 78
<sergiusens> didrocks, is the request rsalveti made last night in for the races for lxc-android-config?
<didrocks> kgunn: ah, I don't know how he tested, I think he just installed the -autopilot package, that should pull the fake-env, right?
 * didrocks looks
<lool> == Publishing url-dispatcher (misc stack) ==
<didrocks> sergiusens: lool pushed it but blocked it in proposed AFAIK
<lool> sergiusens: that was the one in #77 I think
<kgunn> didrocks: you are right...it _should_ when you install a suite..but good to double check
<lool> didrocks: no that's another one, that's the boot script that I blocked and unblcoked
<didrocks> ah ;)
<psivaa> didrocks: kgunn: http://pastebin.ubuntu.com/6188183/ is what i get for unity8 with mir
<didrocks> kgunn: it's a dep, so yeah, should be there
<didrocks> (just checked)
<sergiusens> lool, didrocks landing ask 95 if I'm reading that correctly
<didrocks> sergiusens: no, this one was just "ok for you to upload" (with both tests that were provided)
<lool> sergiusens: sorry, that's something else; I thought you meant the upstart-file thing from yesterday evening, but that was in android
<lool> sergiusens: do you need lxc-android-config to be staged somewhere for testing, or are you good to test locally and upload?
<sergiusens> lool, they are sort of connected
<lool> didrocks: so the rev that I've lost in the -config was:
<lool>   Add qtdeclarative5-usermetrics0.1, new dependency of camera-app (already in
<lool>   Ubuntu), as this breaks media stack autopilot tests.
<sergiusens> didrocks, I was never asked to provide any tests
<lool> I'm pretty sure I had pushed it a day where you weren't around, like last week-end
<didrocks> lool: I just pulled and push, didn't --overwrite
<lool> but didn't deployed
<lool> didrocks: no idea what happened then
<lool> maybe my pushed failed and I didn't notice, but weird
<sergiusens> lool, I already tested locally, I don't see how the risk is medium though
<lool> sergiusens: just because it might break boot
<didrocks> sergiusens: not providing tests, just testing on the scenarios we wrote
<sergiusens> lool, currently, the system is deleting the socket that the upstart-local-bridge is creating
<lool> sergiusens: you did the testing then, all good  :-)
<didrocks> sergiusens: which seem to be impacted (it's a 10 minute test)
<sil2100> didrocks: testing is fine both on unity7 and unity8, publishiiing!
<lool> sergiusens: would you upload this like now so that it can make it to image?
<didrocks> sergiusens: if you did it on your system, awesome, that's what we were waiting for ;)
<didrocks> sil2100: sweet!
<sergiusens> didrocks, so our team always tests an MR contrary to others
<lool> sergiusens: I think I had added that testing note that this is the type of testing we would like to see, either from uploder or from us, to make sure we don't regress boot with the change
<didrocks> sergiusens: I know that we can trust your team, now worry, we just write so that there is a common rule and no misunderstanding :)
<didrocks> no*
<sergiusens> lool, well I can test a r/w image
<lool> sergiusens: if you think it's an important test, that's welcome
<didrocks> that would be great ;)
<sergiusens> lool, I see no point in it, but give me a second
<lool> I think I had noted mako and maguro as boot tests
<lool> but I don't particularly care in rw vs. ro boot tests
<lool> didrocks:  qtdeclarative5-usermetrics0.1 is only in saucy, not head config
<sergiusens> lool, well we can wait for rsalveti to confirm on mako
<lool> didrocks:  do you try to keep these up-to-date?
<didrocks> lool: better once we start diverging, yeah
<lool> sergiusens: would you upload lxc-android-config right now
<lool> sergiusens: it will be staged in proposed
<lool> sergiusens: rsalveti and/or me can test it on mako from thre
<sergiusens> lool, I can't really
<lool> didrocks: would you mind adding it to head?
<lool> sergiusens: ah how so?
<lool> sergiusens: may I help?
<sergiusens> lool, didrocks if there's another build today, we can wait for rsalveti
<didrocks> lool: can do right
<sergiusens> lool, I'm not a core dev
<lool> sergiusens: gosh!
<lool> sergiusens: where do I sign
<sergiusens> lol
<didrocks> sergiusens: later today or tomorrow morning, depends on the velocity and who will be around to trigger an image, but it's really as you wish, if you prefer waiting for rsalveti
<rsalveti> morning
 * rsalveti reading backlog
<sergiusens> didrocks, I always ACK my MRs too ;-)
<sergiusens> rsalveti, just lxc-android-config
<sergiusens> rsalveti, with the race avoidance
<didrocks> sergiusens: rsalveti: so, if all testing is good, please upload it now for being in 79
<lool> sergiusens: uploaded
<fginther> didrocks, mind if I backout autopilot from the PPA?
<lool> fginther: we're interested in issues you have with it though
<lool> fginther: cause it's supposedly working for us!
<didrocks> fginther: why? this one should be fine
<fginther> :-(
<didrocks> fginther: we got everything passing and it's uploaded to the archive
<lool> rsalveti: morning
<fginther> didrocks, lool https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-vm-saucy/ builds 170 - 179
<didrocks> fginther: does the sdk has the fix merged?
<fginther> these are desktop runs
<didrocks> sil2100: would know ^
<fginther> ahh
<didrocks> fginther: there was a branch (we backported the fix manually to distro) for the sdk
<didrocks> fginther: but we couldn't get it merged
<didrocks> one sec
<didrocks> fginther:  [4] https://code.launchpad.net/~veebers/ubuntu-ui-toolkit/ap-test-fixes-for-updated-autopilot/+merge/188970
<didrocks> you will need that one ^
<fginther> didrocks, much thanks
<didrocks> fginther: manually, on the phone, it pass
<rsalveti> didrocks: lool: I want to land the seek related improvements as well, but guess that can wait for 80
<rsalveti> as it'll take at least another ~2 hours
<lool> rsalveti: yeah
<didrocks> rsalveti: yeah, sounds better for 80 then, just upload the other one
<lool> rsalveti: I've asked on the spreadsheet how we can see the bug / confirm the fix
<psivaa> kgunn: Mirv might have mentioned the failure of launch_unity with with -n .. i also see that with http://pastebin.ubuntu.com/6188183/
<lool> didrocks: updated spreadsheet; testing click packages
<didrocks> grand!
<rsalveti> lool: right, just seek before and after :-)
<didrocks> rsalveti: it's going to fix the slowdown?
<sil2100> didrocks, fginther: I guess this merge will get in once the new autopilot is available, so I think we can again approve this
<Mirv> sil2100: didrocks: thanks, indeed I forgot apps part with all the home scope discussion. it seems to work as well, on both device (unity8 AP) and desktop (manual), plus it's a string change only so should be good.
<fginther> sil2100, right, I just realized that, rerunning the test now that autopilot is there
<rsalveti> lool: but you need to create the android image with latest hybris as we got a change in there as well
<psivaa> kgunn: just making sure that i dont bring any confusion on 'worked but all 24 tests failed'
<Mirv> sil2100: did you publish it yet?
<rsalveti> didrocks: well, seek works after we publish those changes
<rsalveti> currently it can easily lock down the mediaplayer-app if you seek
<didrocks> rsalveti: oh? I did dream it was working for me? I remember trying it
<didrocks> (but it was really laggy)
<Mirv> kgunn: regarding phablet-test-run -n unity8, it seems that the unity8 is just closed (as should be) but the mock version of unity8 that autopilot should use does not come visible. I did not wait for the autopilot to error out.
<rsalveti> right, it's currently laggy as well
<fginther> sil2100, should have results in about 10 minutes
<Mirv> kgunn: the unity8-fake-env is there, and it works without mir
<lool> didrocks: not joining?
<sil2100> fginther: awesome, thanks!
<didrocks> lool: I guess I had the wrong link
<sil2100> Mirv: u-l-a? Yes
<sil2100> ;)
<kgunn> Mirv: psivaa-afk thanks guys...yeah..i understood it correctly...interesting
<didrocks> lool: do you have the link? I end up being alone
<Mirv> sil2100: ok, thanks, cool! seeing it now in queue
<lool> didrocks: see msg
<sil2100> Mirv: np. :)
<Mirv> cjwatson: so, unity-lens-applications now in the queue
<kgunn> Mirv: building local is a nightmare...if i wanted to get one of my engineers on what you and psivaa-afk see....what's the best way to do that in advance of image 79 being available ?
<didrocks> rsalveti: your change is in the version lool uploaded I guess (for req 95), the one blocked in proposed?
<didrocks> kgunn: install image 78, turn in in write mode and apt-get update && apt-get install libmirserver5
<rsalveti> didrocks: for lxc-android-config, yes
<didrocks> then activate mir and be done :)
<didrocks> excellent, so all in transit!
<kgunn> didrocks: thanks for confirming...thot that was the answer
<didrocks> yw
<Mirv> kgunn: as didrocks described ^ reboot, wait for Nautilus window to pop up the mounted share (connection breaks at that moment, takes about 30s after unity8 is visible), run phalet-test-run -n unity8 (after also installing unity8-autopilot)
<cjwatson> Mirv: looking
<cjwatson> Mirv: accepted
<fginther> sil2100, retest with the new autopilot worked. I've re-approved the MP.
<Mirv> cjwatson: thanks!
<fginther> didrocks, ^
<didrocks> fginther: sweeeeeet \o/
 * rsalveti pushing libhybris, will only be used after a respin of the android package
<rsalveti> didrocks: lool: when are you guys starting next image?
<lool> rsalveti: mind testing latest lxc-android-config from proposed on mako?
<lool> boot testing that is
<rsalveti> lool: sure
<lool> rsalveti: in a few, pushing some remaining packags (click) and then waiting for in archive + building
<didrocks> rsalveti: it's the last one we are waiting on, then once published in the release pocket, we kick the image (click should be in beforehand)
<lool> finishing click tests
<lool> click is good
<lool> publishing
<lool> didrocks: I need help to preNEW http://10.97.0.1:8080/job/cu2d-click-package-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_click-update-manager_0.1+13.10.20131003.1-0ubuntu1.diff
<lool> didrocks: click-update-manager-autopilot
<lool> didrocks: what do you do there, or who do I ping to preNEW it?
<didrocks> lool: ok, looking
<lool> didrocks: I review it and then just say it looks good?
<didrocks> well, an archive admin, I'm doing it :)
<didrocks> lool: for the operation to do, you have: https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack
<lool> didrocks: what do I tell the archive admin?
<didrocks> ah, it's a binary new
<lool> yes
<didrocks> well, normally, I just give a look (as if the sync was passing normal binary New)
<didrocks> ah finally click-update-manager arch:all :p
<lool> didrocks: I see the instrucitons in the FAQ actually
<didrocks> lool: ok, using dh_python2, +1 from me
<didrocks> lool: well, there are for source new
<lool> didrocks: it seems I should be doing something in the -config though
<didrocks> lool: hum, not for binary new, if there are AP tests, yeah, you should add them to the config if they can run on desktop
<lool> == Publishing click-package stack ==
<lool> ralsina: ^ FYI
<lool> rsalveti: did the boot go ok?
<rsalveti> lool: rebooting and will check
<rsalveti> did a clean flash
<rsalveti> lool: all fine +1
<lool> cool, also rebooting here
<lool> yep, came up
<lool> unblocked
<didrocks> sweet :)
<lool> now waiting for click + lxc transitions to release + publisher
<lool> so 5:30pm our time perhaps
<didrocks> yeah
<didrocks> (40 minutes for now for other in an insane timezone)
<didrocks> from*
<lool> didrocks: so how do we run the Mir tests on regular AP infrastructure?
<lool> didrocks: I wonder if this is our last SF image
<lool> maybe not
<didrocks> lool: on the regular infra? that would be a plars or doanac's question. I think they just copy the same run, but add an adb shell touch /home/phablet/.display-mir before the reboot
<lool> didrocks: I think that's what olli wanted right?
<didrocks> yeah
<didrocks> we'll discuss that in the meeting with plars I guess
<plars> lool: I'm planning on setting that up once we have all the pieces needed in the image to make it work right
<plars> lool: I'll set up a separate job for it
<plars> didrocks: ^
<didrocks> plars: so just adding the touch in the setup?
<plars> didrocks: for that run, yes
<didrocks> sounds good!
<plars> didrocks: I don't think we want to turn it on as the default yet right (even in the tests)? So it'll just be a one-off job temporarily
<lool> plars: what are the pieces?  the mir + AP fixes?
<plars> lool: yes
<lool> plars: FYI these should be all good now, albeit we're getting different patterns on whethre unity8 tests run or don't run from different folks
<lool> plars: cool
<lool> plars: so I think that would be good to have starting with the next build
<lool> in a few
<plars> lool: that's another thing I'm about to try
<plars> lool: locally that is
<lool> autopkgtest for click-update-manager 0.1+13.10.20131003.1-0ubuntu1: RUNNING (Jenkins: public, private)
<lool> that blocks a couple of click updates from moving right now
<lool> it seems to have passed
<plars> doanac:
<plars> raise click.AppArmorException("Could not find '%s'" % include)
<plars> apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot/apparmor/click.rules'"
<doanac> plars: you sure you have the updated version?
<plars> autopilot-touch:
<plars>   Installed: 1.3.1+13.10.20131003.1-0ubuntu1
<plars> /usr/share/autopilot/apparmor/click.rules seems to be there
<doanac> plars: where did the excepction come from?
<plars> oh wait
<plars> doanac: it's /usr/share/autopilot-touch/apparmor/click.rules
<plars> not /autopilot
<doanac> plars: ah. thanks.
<doanac> i'll update the mp
<plars> doanac: I'll update it locally and retry
<didrocks> plars: yeah, if we can run them in parallel until we turn it on by default (sorry didn't see your ping ;))
<plars> doanac: ok with that change it works for me
<plars> doanac: 5 passes on a click package test :)
<plars> sergiusens: ^
<sergiusens> plars, AWESOME!
<plars> sergiusens: doanac has a mp to put in once 79 lands that should turn dropping-letters tests on at least
<ralsina> lool: ack
<ralsina> lool: I assume you can mark ask #115 as done then
<doanac> plars: branch is updated, and I tested locally also
<lool> lxc is in
<lool> click-update-manager still in proposed
<lool> but valid candidate
<sergiusens> doanac, I was actually going to ask you if we should look at your branches again, going to review now
<lool> it's in
<lool> didrocks: kicking image
<lool> ah no
<lool> click-update-manager is not, weird
<didrocks> right, not yet
<lool> why did clickmanager-plugin transition though
<lool> oh
<lool> arch: all change
<lool> cjwatson: hey
<lool> cjwatson: can you help me understand whether the click-update-manager proposed transition is going ok?
<lool> cjwatson: we switched it from arch: any to arch: all
<lool> rmadison says:
<lool> click-update-manager | 0.1+13.10.20131003.1-0ubuntu1 | saucy/universe | source, all
<lool> click-update-manager | 0.1+13.10.20131003.1-0ubuntu1 | saucy-proposed/universe | all
<lool> so it looks like it's actually in
<lool> but with a copy in -proposed
<lool> there's also an old entry:
<lool> click-update-manager | 0.1+13.10.20130930.1-0ubuntu1 | saucy/universe | amd64, armhf
<cjwatson> lool: That might need archive admin assistance, will check in a sec
<cjwatson> lool: But you don't need to worry about it, it's cruft that's reported on and needs to be cleaned up for release, but shouldn't cause a practical problem
<lool> ok
<lool> didrocks: building an image
<didrocks> \o/
<plars> psivaa: you got the unity8 tests working with an update 77?
<plars> psivaa: and mir enabled?
<psivaa> plars: i tried it with 78, with updates.. but all 24 failed
<plars> psivaa: I meant 78, sorry
<plars> didrocks: so, I'm not having any luck getting things going with autopilot tests either. All the pieces should be there right now if I dist-upgrade though right?
<psivaa> plars: yea with that, this is the result: http://pastebin.ubuntu.com/6188183/
<didrocks> plars: yeah, if you dist-upgrade from the archive, you should be fine
<plars> didrocks: not working it seems, works fine if I don't enable mir though
<didrocks> weird, psivaa got it working (well failing rather :p)
<plars> didrocks: no, he's seeing same as me
<didrocks> ah, nice, so the tests are running?
<didrocks> (but failing)
<plars> didrocks: they don't seem to actually be working at all - I see nothing happening on my screen
<didrocks> but psivaa saw the tests starting, didn't he?
 * didrocks is now confused
<plars> psivaa: were you trying this locally? could you see it actually doing something on the screen?
<psivaa> didrocks: i did not see changes in the device.. sorry i dint know if that's what you meant
<didrocks> so the tests don't even start?
<didrocks> ok, let's see with the real infra
<lool> it looks to me like it cant connect on dbus
<plars> didrocks: there's no difference with how I'm running it here vs. how it would run in the lab
<plars> didrocks: except that I've enabled mir
<didrocks> plars: well, olli wanted to have a run in the "official infra"
<ogra_> did you guys forget -n ?
<didrocks> so let's get that ;)
<plars> and updated the image of course, but it's the same scripts getting called the same way
<plars> ogra_: no
<ogra_> i dont see it stop unity8 in the paste above
<plars> ogra_: I stopped it in mine
<ogra_> manually ?
<plars> ogra_: no, the scripts we run do that
<ogra_> right, it usually prints "stopping unity8"
<plars> even the unlocker doesn't seem to get through here...
<plars> I'm trying friends app
<plars> Setting up friends-app-autopilot (0.92.0+13.10.20131001.1-0ubuntu1) ...
<plars> ----------------------------------------------------------------------
<plars> Stopping Unity
<plars> unity8 stop/waiting
<plars> Unity stopped
<plars> ----------------------------------------------------------------------
<plars> Starting Unity with testability
<plars> and that's as far as I get
<ogra_> ok
<plars> going to retry with just phablet-test-runner and manually unlocking
<psivaa> plars: ogra_ didrocks: so i ran unity8 again. same results (24 failed) i did not see any change in the screen..
<didrocks> ok, so it seems something didn't work at all
<didrocks> kgunn: FYI ^
<plars> ok, so the screen unlocker (which also restarts unity8 with -testability) doesn't seem to work in the ci infrastructure
<didrocks> kgunn: so now all testimonials concurres
<plars> but if I unlock  by hand, I can get other (non-unity8) tests to work
<didrocks> plars: this is already a good news, can you try notes-app?
<didrocks> this one was blocking before
<plars> didrocks: one sec, need to restart. I was trying unity8 with just phablet-test-run and -n again - still nothing
<robru> didrocks, bah! powersaving is still busted for me
<robru> woke up to find both my screens had been on all night
<didrocks> robru: did you talk to seb128 about it? he would maybe have an idea
<plars> didrocks: the notes-app tests can run ok, but only if unlocked by hand - clearly things are going to go badly in the lab with this though
<robru> didrocks, no, not yet
<plars> didrocks: and unity8 plain won't work
<plars> the tests that is
<didrocks> plars: ok, thanks for confirming!
<cjwatson> lool: either somebody else cleaned up click-update-manager or it sorted itself out
<cjwatson> click-update-manager | 0.1+13.10.20131003.1-0ubuntu1 | saucy/universe | source, all
<cjwatson> click-update-manager-autopilot | 0.1+13.10.20131003.1-0ubuntu1 | saucy/universe | all
<cjwatson> It might just be that the copy and the removal spanned two publisher runs or something *shrug*
<didrocks> robru: sil2100: plars: joining the HO?
<robru> didrocks, meeting?
<didrocks> yep ;)
<robru> didrocks, i can't find the link
<plars> didrocks: yes, I was just digging up my headphones :)
<lool> cjwatson: indeed, thanks
<didrocks> robru: https://plus.google.com/hangouts/_/a3ec8b9eafe13514725f4c495d40dbc56771c9ca
<plars> doanac: did you go ahead and regenerate the jobs so that when 79 lands we'll pick up that new test?
<kgunn> didrocks: plars...so this https://code.launchpad.net/~mterry/unity8/load-testability/+merge/188064
<doanac> plars: no. i wanted to double check
<kgunn> is in what was test and didn't work ?
<plars> doanac: we should
<doanac> i guess we can if you want though
<doanac> plars: okay. i'll merge now
<plars> kgunn: it looks like it might have something to do with restarting unity8
<plars> kgunn: running phablet-test-run -n (for unity8) and you see unity8 go off, but never come back.
<plars> kgunn: also, for all ap tests, we have a script that unlocks the screen and restarts unity8 in -testability mode. It doesn't seem to function now either
<doanac> plars: change is pushed. do you want to re-generate? i haven't done it lately and don't want to cause harm
<plars> doanac: sure, will do
<kgunn> plars: is there a bug with these details ? (note...not complaining..i know its fresh)
<plars> kgunn: not yet, this is just the first time trying to get it running with a preview of what should be in the next image
<kgunn> plars: ok...i
<kgunn> am going to alert the team on it
<kgunn> might want to join #ubuntu-mir to listen in
<plars> doanac: oops :) missing a template file for it
<plars> doanac: adding
<plars> doanac: https://code.launchpad.net/~pwlars/ubuntu-test-cases/dropping-letters-template/+merge/189125
<doanac> plars: good catch.
<doanac> +1
<plars> doanac: sorry I didn't spot that in the review
<plars> doanac: it's all pushed and regenerated now though
<doanac> plars: my original branch had it, but i rebased for the merge today and missed that
<lool> livefs image build finished
<lool> 79 imported!
<lool> didrocks: download was much snappier this time around
<lool> the download progress actually seems to slow down download here, maybe just an impression though
<didrocks> lool: you still got the 100% first thing?
<lool> didrocks: it was too fast to tell for sure, but it seemed so
<lool> olli: Image up
<lool> kgunn: ^
<didrocks> well, there is still a glitch to fix
<didrocks> \o/
<didrocks> plars: it's all yours now :)
<didrocks> jfunk: FYI ^
<plars> didrocks: the tests are already running, and I'm installing locally to try the mir stuff again - just in case there's some difference
<didrocks> plars: let's cross fingers ;)
<lool> didrocks: are you sending the update email tonight?
<lool> or should I?
<didrocks> lool: already done :)
<lool> cool, thanks
 * lool lifts the lxc-android-config block
 * jfunk reads
<didrocks> yw!
<robru> didrocks, hmmm, launchpad seems to be loading ok *now*, but it was definitely not working earlier this morning. not sure if it'll stay fixed or if it's going to be intermittently broken...
<didrocks> robru: maybe you can try on a stack like the webcred one?
<didrocks> it's a small one, the window of breakage is smaller ;)
<didrocks> lool: wdyt? ^
<cjwatson> there's no LP maintenance or anything happening, at least not that would affect page loading ...
<lool> didrocks: hmm ok
<lool> robru: yeah, +1 on webcred
<robru> cjwatson, yeah, i guess it's an issue with my ISP.
<robru> ok, i'll take webcred
<lool> bfiller: heya
<cjwatson> (we've been hammering the hell out of the buildds, mind)
<lool> bfiller: so we have a quieter time until tomorrow morning while we wait for SDK fixes or Mir updates; a bunch of apps are staged, as well as phone stack packages; would you want us to try to land them?
<lool> bfiller: waiting for your green to land stacks: apps, phone
<robru> didrocks, lool: which line is webcred in the landing plan? I don't see it
<lool> robru: adding it
<lool> robru: done
<dobey> fginther: any idea why bzr seems to constantly be having trouble in the jenkins amd64 builds?
<lool> robru: near the bottom
<robru> lool, thanks
<bfiller> lool: yes landing apps would be good, let me just double check some of them and get back to you shortly
<lool> bfiller: this is what's currently staged in PPA: http://people.canonical.com/~platform/cu2d/results
<fginther> dobey, a fix/workaround has been deployed, can you point me to a log to make this isn't something new?
<dobey> https://jenkins.qa.ubuntu.com/job/unity-scope-click-saucy-amd64-ci/61/console
<fginther> dobey, thanks for the link, that issue is addressed by the chnage that was deployed about 2 hours ago
<dobey> fginther: ok. can you re-run that failed attempt, if you haven't already? :)
<fginther> doanac, sure
<ev> sorry about that, guys!
<ev> I'll make sure I'm either using the laptop in Bluefin (wfm today) or Firefox next time
 * fginther -> food
<dobey> thanks
<ev> so yeah, the Oakland Client Sprint is a higher level discussion.
<ev> I suspect Alex will be touching on that more next week when he returns
<ev> but don't worry about booking flights with but a few weeks to go, or missing Halloween :)
<lool> plars: hey
<lool> plars: so there is some dbus fixing going on
<lool> plars: it relates to dbus not picking up env vars, and also some connection refused errors
<elopio> hey people. When is dpkg-dev installed on the jenkins phones?
<lool> plars: I suspect it might be related to some issues we were seeing
<lool> plars: you might want to try applying the fix locally to see if it helps
<plars> lool: yes!
<lool> elopio: it should be pulled by package dependencies surely
<plars> lool: where can I find it?
<lool> right now in unapproved
<plars> lool: is this for the mir issues?
<lool> plars: https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=dbus
<lool> plars: *maybe*
<lool> plars: I dont understand what autopilot does to stop/start unity8
<lool> but because it's a race even in user sessions, it is worth trying
<lool> initctl stop unity8 + initctl start unity8
<bfiller> lool: go to go on that list for apps and OSK. e
<lool> so that might just be racy with dbus
<lool> bfiller: so apps stack?
<lool> bfiller: what about phone stack?
<bfiller> lool: apps stack and telephony stack (whatever has dialer, messagin, telephony-service, etc..)
<bfiller> lool: which stack is OSK in?
<lool> bfiller: ubuntu-keyboard is in services
<lool> with content-hub
<lool> that might be a bit much
<bfiller> lool: up to you, OSK ready from my perspective
<lool> bfiller: what's your risk assessment for apps / phone / services stack?
<bfiller> low
<bfiller> fixes a ton of bugs
<bfiller> low risk of regression
<lool> ok
 * bfiller famous last words :)
<lool> bfiller: I know where to find you!  ;-)
<lool> I think I might build another image just to pick up dbus later today
<lool> plars: https://launchpadlibrarian.net/152322007/dbus_1.6.12-0ubuntu5_1.6.12-0ubuntu6.diff.gz
<plars> doanac: correct me if I'm wrong, but it looks like the unity8 tests are now trying to run from /home/phablet/autopilot? is that as a result of the click provisioning stuff?
<robru> Mirv, sil2100: http://10.97.0.1:8080/job/cu2d-webcred-saucy-1.1prepare-libaccounts-glib/55/console i don't understand why this is yellow? it says there's a diff between trunk and ubuntu src, but i just checked it and there's no diff. they're identical.
<doanac> plars checking
<doanac> plars: we've been running with /home/phablet/autopilot in the PYTHONPATH since revno 20
<plars> doanac: right, but now there's a unity8 directory there
<doanac> ah, yes. that would override things
<doanac> plars: shouldn't it be the same code though?
<plars> lool: let me work around this so that I'm sure I'm running the right thing, and try it once again without the changes, then I'll take a look
<plars> doanac: unless someone has landed something since then - right?
<doanac> plars: no - phablet-click-setup is pinned to a version
<plars> looking
<plars> doanac: ah, ok
<lool> /home/phablet/autopilot error was always there
<plars> lool: yeah, it should be gone now
<lool> got to go, will pop by later
<lool> to test initrd update and dbus and roll an image with these
<rsalveti> lool: pushing the seek fixes now
<rsalveti> lool: will bump android, want me to hold for that? or did you get all your init changes in already?
<sergiusens> doanac, plars you just made me think of a potential problem with testing autopilot packages, those are also pinned to a version and we may not actually have the correct unity installed; and given that, since it's a deb, it may install a newer version of unity than what's on the image
<plars> sergiusens: you mean pull a newer branch than what's installed?
<plars> sergiusens: it does (as doanac says) look like it's checking the version of unity8 before pulling
<sergiusens> plars, just to avoid confusions, keep phablet-click-test-setup out of the picture
<plars> sergiusens: well, it's there for now
<plars> sergiusens: we just added it a bit ago
<sergiusens> plars, image is built with unity8-v1 and unity8-autopilot (with depends on v1); while image is building; unity8v2 is published and hence a new unity8-autopilot lands
<sergiusens> plars, so when you do image testing and grab unity8-autopilot you will pull in unity8v2 (when the image originally had unity8v1)
<plars> sergiusens: but in phablet-click-test-setup it looks like fetch_test_base calls get_package_version
<sergiusens> plars, that's what I meant with keep the click stuff out of the picture
<plars> sergiusens: oh, we don't ever apt-get update
<sergiusens> plars, not even to install utah?
<plars> sergiusens: we don't install utah
<sergiusens> plars, great
<sergiusens> plars, well that being said, you can't use what's provided by phablet-click-test-run to test anything but click
<plars> sergiusens: it'll try to use it for testing unity8, does that cause a problem?
<plars> sergiusens: should be the save branch version as what's installed in the package right?
<sergiusens> plars, the unity8 and ui-toolkit autopilot packages have deps that wold need to be installed
<plars> ah, right
<sergiusens> plars, yeah, the test code is good, but all the deps aren't (unity8-fake-mock, python-mock and one more I forget)
<sergiusens> python-gi
<plars> doanac: hmm, so it seems we either need to do special handling for the ui-toolkit and unity8 tests, or we could just install those deps as part of the setup
<rsalveti> lool: pushing
<balloons> are we happy with me pushing fixes for https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1234544 now?
<ubot5> Ubuntu bug 1234544 in Ubuntu UI Toolkit "Several apps have failing tests with 20131003 ui-toolkit" [Critical,In progress]
<plars> unity8 is hitting some cpu spike again - this time after the run: https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-mako-smoke-camera-app-autopilot/120/artifact/clientlogs/top_after.log/*view*/
<plars> and a couple of unity8 failures, which may be related to what sergiusens mentioned earlier... need to investigate
<doanac> plars: just got back from lunch.
<doanac> aren't we already install the unity8 deps?
<doanac> ie: NO_UNLOCK=1 PKGS="unity8-autopilot" prepare-autopilot-test.sh
<plars> doanac: oh right
<plars> so it should be ok I think
<doanac> plars: you know the IP of ashes?
<doanac> or retoaded or rfowler ^^^ ?
<retoaded> 10.97.8.11
<doanac> retoaded: hmm. didn't seem like jenkins was running. could you add me as a local user to that system?
<kgunn> plars: when you test are you on nexus4 or galaxy nexus ?
<plars> kgunn: I was testing on a nexus4, but I have both
<kgunn> thomi: ^
<thomi> ok, so maybe there's a bug somewhere relating to the AP MT device, mir, and the GN
<thomi> the unholy trinity of devices, display server, and test tools
<kgunn> plars: it'd be interesting if you could test on galaxynexus...but if your super busy i understand
<plars> kgunn: I will, at some point today
<kgunn> plars: thanks dude!
<thomi> plars: got a second?
<plars> thomi: what's up?
<thomi> plars: for the unity8 test suite, I suspect that powerd may be blanking the screen mid-way through the tests. To prevent this, I wonder if we should be running 'sudo powerd-cli active'
<thomi> which will block, and will prevent powerd from blanking the screen while it's running
<thomi> so I guess you'd either want to do that in a separate shell, or save the PID or whatever
<plars> thomi: we can take a look, but at what point is it becoming unactive long enough to blank? aren't there always touch events firing off during the run?
<thomi> plars: I think that, because unity8 takes a long time to shut down & start up, that's where the issue lies
<thomi> we'd only need it for that test suite
<plars> thomi: but isn't that just at the very beginning? I think the 2 failures we're seeing are later
<thomi> oh ok
<thomi> well, something to think about anyway. I haven't seen the failures myself, just hearing about them second hand
<plars> thomi: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4539/unity8-autopilot/
<plars> thomi: it's the indicator tests
<thomi> plars: oh, that's now what was described to me at all - I think we're talking about two totally different things
<alesage> thomi, plars, I think those are obsolete, no?
<thomi> that looks to me like someone is passing an integer as a parameter to the launch method
<thomi> alesage: not AFAIK
<plars> alesage: those are on the current image
<alesage> hmpf
<rsalveti> was planning on triggering a new image build in a few, anyone waiting something to land for the next image today still?
<lool> balloons: Pushing fixes to ui-toolkit >> you mean to PPA?
<lool> rsalveti: catching up a bit
<balloons> lool, yes
<rsalveti> lool: ok, let me know when we're able to trigger a new image
<lool> balloons: yes, fixes to PPA very welcome
<lool> balloons: if you could give a heads up to Mirv with the things you're fixing, that would be awesome
<lool> rsalveti: there's a click regression that alecu reported
<lool> in #79
<rsalveti> lool: right, any plans to get the fix in?
<rsalveti> I mean, do we have the fix already? :-)
<ralsina> rsalveti, lool: that's not really a regression once the server-side fix is in
<ralsina> which should be in hours (right beuno?)
<ralsina> ok, beuno is not here :-)
<lool> ralsina: ok, then we're good
<lool> ralsina: why is it specific to #79?
<lool> because we dropped noauth?
<ralsina> lool: exactly
<ralsina> we are using another feature of the server
<lool> oh ok, you had to pass noauth for free packages, if you're logged in it doesn't work?
<lool> alright
<ralsina> and we all tested it with our own accounts which worked
<ralsina> so, fixing the manual testing also
<lool> rsalveti: so before you build an image, could we boot test latest android?
<lool> it has an initramfs script change
<lool> and it has the dbus fix
<lool> I wouldn't want to lock folks out
<rsalveti> lool: sure, can test locally
<kgunn> plars: new priority queue...can you test on Nexus4 AP install-and-boot, sdk, security, default, click_image_tests
<kgunn> olli: ^
<kgunn> plars: and obviously provide some report back
<plars> kgunn: will do, I need to go pick my kids up from school though in just a moment
<plars> kgunn: install-and-boot is done (obviously) and has nothing to do with mir
<kgunn> sure... plars ...me too
<lool> hmm unity8 suicided
<plars> kgunn: click_image_tests just checks that the click packages that are expected to be installed are actually installed
<lool> system-settings was running, and bam
<olli> plars, just want to make sure that the remaining AP test that has issues is u8-autopilot
<lool> black screen
<plars> kgunn: actually none of those are ui related at all
<plars> kgunn: so, the results on the dashboard should be no different than what we see under mir
<lool> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what():  Could not unblank display
<kgunn> plars: willing to back that up with a paycheck ? :)
<plars> kgunn: none of the tests in the list you just gave me use autopilot
<kgunn> plars: for sure...just want to be sure we no breakie something
<plars> kgunn: another interesting thing I'm seeing is that when I try to reboot with mir enabled, it doesn't seem to succeed the first time
<kgunn> plars: in /home/phablet/.cache/upstart/unity8.log does it make reference to unblanking...or not being able to get a display ??
<lool> rsalveti: rebooting to test too
<plars> kgunn: well, I was about to kick off camera and gallery, but I will make my way back to that
<rsalveti> lool: did you build a new android image?
<lool> rsalveti: no, intended to combine your .deb's initrd with my device's boot.img
<kgunn> olli: ^
<rsalveti> lool: right, that should be enough to test the initrd image
<rsalveti> *changes
<kgunn> just pointing out we're redirecting plars to those tests we discussed
<plars> kgunn: camera_app tests all pass with mir + manual unlock
<kgunn> \o/ plars ...
<lool> rsalveti: hmm which one should I take, saucy-android-ramdisk+mako.img or saucy-ramdisk+mako.img?
<rsalveti> saucy-ramdisk+mako.img probably, the other one should be from android
<olli> lool, ^ fyi
<rsalveti> lool: boots fine here
<lool> rsalveti: cool, did you test with dbus?
<rsalveti> lool: checking that bug now, see if it was really fixed
<lool> rsalveti: I'm not sure how to easily reproduce, but I definitely got some url-dispatcher crash files here in the past with dbus connection refused
<lool> rsalveti: I just want to make sure session opens correctly with it
<plars> kgunn: one failure on gallery
<plars> MismatchError: After 10.0 seconds test on TextEditOnClick.text failed: u'Photos' != dbus.String(u'My Photo Album', variant_level=1)
<plars> kgunn: could just be a flaky test - will rerun
<lool> plars: do you have the mir test results up on reports.qa?
<plars> kgunn: but I *really* have to go get my kids now
<plars> lool: no, still not possible to run with mir
<rsalveti> lool: right, had those crashes before as well
<rsalveti> checking now
<plars> lool: you have to unlock by hand
<lool> plars: do we understand what it entails to do it with Mir?
<plars> lool: not yet
<plars> lool: the unity tests and the unlock script both restart unity8 with -testability though, could be the common factor
<plars> lool: I have to run, but will be back in a bit and on/off most of the evening
<plars> kgunn: I'll let you know how the second run of the gallery tests went when I get back
<lool> eh we have dbus-x11 on the image
<lool> rsalveti: rebooting with latest dbus packages here
<lool> plars: ok
<rsalveti> lool: seems fine after reboot
<sergiusens> lool, I just saw the same issue, ran system settings and it even eventyally took out adb
<lool> rsalveti: works well here too
<lool> rsalveti: I can kick an image now if you like
<rsalveti> lool: whatever you prefer :-)
<lool> doing it  :-)
<lool> I actually wanted this dbus fix tonight
<lool> and to test that initrd change (didn't plan the hybris one, that's bonus!)
<lool> rsalveti: running
<lool> rsalveti: ~42 minutes
<lool> sergiusens: ah!
<lool> sergiusens: are you on SF?
<lool> I guess this might be due to the Mir changes regressing SF, not sure whether it's worth fixing
<sergiusens> lool, mir
<lool> sergiusens: ok, then the good news is that it's not SF/Mir specific
<lool> and the bad news is that it's a serious bug
<lool> sergiusens: did you get a crash file?
<rsalveti> lool: great, thanks
<sergiusens> lool, I actually have a bunch of crashes
<sergiusens> lool, none for the settings though, let me reproduce
<lool> sergiusens: check if unity8 crashed though
<lool> sergiusens: I personally look at timestamps in /var/crash
<lool> ls -ltr /var/crash
<sergiusens> lool, it did, but I've been using this for a week and it's an old crash
<lool> ah right
<sergiusens> lool, http://paste.ubuntu.com/6189839/
<sergiusens> lool, the crashes I see aren't that nice though :-)
<sergiusens> lool, those get autouploaded, right?
<lool> sergiusens: no
<lool> you have to touch s/.crash/.upload/
<lool> e.g. touch /var/crash/usr_lib_arm-linux-gnueabihf_hud_hud-service.32011.upload
<lool> then eventually it will be
<lool> sergiusens: all your recent ones are scary   :-(
<sergiusens> lool, ex`actly :-)
<lool> sergiusens: we've just updated hud, we've just updated url-dispatcher
 * sergiusens curses keyboa`rd
<cwayne> sergiusens, i don't suppose we've bundled a bunch of fixes together recently have we? :)
<balloons> fginther, re:ubuntu-app-devel thread.  I know it's late in the day and we're all scrambling, but I don't want our conversation to get lost. Do we need to bring it up with some more folks?
<fginther> balloons, thinking about who to engage...
<lool> sergiusens: what are the steps to trigger the crash when settings is running?
<lool> I tried turning the screen off, and it dind't work
<sergiusens> lool, go to the background settings
<sergiusens> cwayne, I want to include two of doanac's MRs in there as well
<fginther> balloons, let pick it up tomorrow morning
<balloons> fginther, I'll send a mail to say you zoltan and asac?
<balloons> else I will forget
<balloons> :-)
<fginther> balloons, sure
<cwayne> sergiusens, makes sense, any ETA on it?
<lool> thomi: are you looking at the autopilot changes to do the powerd dance and the unlocking on mir?  :-)
<thomi> lool: no, plars seemed to indicate that it wasn't a problem. Besides, you can only use powerd-cli as root, so I think (for now, anyway) this is something that needs to happen on the CI side
<sergiusens> lool, if you do that, you get terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<sergiusens> lool, I think seb128 knows about this though
<lool> seb128: ^ is this something you ou know of?
<lool> sergiusens: I tried the PPA version too, but unity8 crashed instead
<thomi> lool: then again, if you can think of a solution, I'm happy to write the code :)
<lool> thomi: what do you mean on the CI side?
<lool> in the tests?
<thomi> lool: No, I mean as part of the environment setup you guys could run 'powerd-cli active' as root
<seb128> lool, sergiusens: knowing about what?
<thomi> which prevents the screen from blanking while that command is running
<lool> seb128: crash when opening background pane in settings
<sergiusens> seb128, background changes with mir enabled
<lool> thomi: do you know where the piece of code to unlock the screen lives?
<lool> is that utah?
<lool> thomi: and are there other AP issues that you know of on Mir outside of the unlock thing?
<thomi> lool: there's this: https://bugs.launchpad.net/mir/+bug/1234956
<ubot5> Ubuntu bug 1234956 in Mir "mir does not recognise autopilot autopilot input device on maguro" [Critical,Confirmed]
<thomi> lool: which means maguro runs will break right now
<thomi> actually, plars should know about that
<thomi> plars: probably no point doing your maguro test runs for kgunn, since we know it's not going to work
<lool> thomi: thanks
<seb128> lool, sergiusens: https://bugs.launchpad.net/bugs/1234733
<ubot5> Ubuntu bug 1234733 in ubuntu-system-settings "Substituting wallpaper under mir produces blackout" [High,Incomplete]
<seb128> lool, sergiusens: that seems like a toolkit/mir issue, e.g the image crossfading from the toolkit is making mir segfaulting
<lool> seb128: yeah, that's what I was thinking too
<sergiusens> seb128, seems it's a mir bug
<lool> it could be the qtdeclarative update
<lool> sergiusens: I get it on SF
<sergiusens> lool, oh :-/
<sergiusens> lool, what qtdeclarative update?
<lool> rsalveti: image up
<sergiusens> seb128, on the plus side, after rebooting I get my chosen wallpaper :-)
<rsalveti> lool: great, thanks
<seb128> sergiusens, ;-)
<lool> seb128: http://people.canonical.com/~ogra/touch-image-stats/20131003.1.changes
<seb128> sergiusens, ^
<lool> seb128, sergiusens: I dont even get to chose
<lool> just loading the background pane and it crashes here
<seb128> lool, that's what the bug I pointed out describe
<seb128> lool, the preview widget in the setting apps do the crossfading, I guess that's what mir doesn't like
<seb128> lool, can you try the testcase from ken on the bug?
<sergiusens> seb128, I'll give it a shot
<lool> GRR
<lool> why is the new ui-toolkit in the image
<sergiusens> lool, seb128 this is what I get http://paste.ubuntu.com/6189974/
<sergiusens> no crash
<plars> thomi: ack
<lool> seb128, sergiusens: The thing is that this ubuntu-ui-toolkit should NOT be in archive and hence in image
<lool> it had regressions
<lool> and it's likely causing these
<seb128> :-(
<lool> but it looks like a zombie job pushed it, I can't figure what has possibly uploaded it
<seb128> lool, that manual workflow doesn't work, we should just use the normal proposed/blocks/review as the release team is doing for other flavors
<lool> yes, I was about to add a block for this package
<kgunn> plars: it would be super useful if you could document your testing findings here https://docs.google.com/a/canonical.com/document/d/1b-X9tN2Q9c_5r39XzA-Ppebbjuin5zVf9SkAGMcdp9Q/edit#
<kgunn> its from the qa team...and i think your seeing results much better with the manual intervention
 * sergiusens will avoid more opinions on the current process
<plars> kgunn: I'll take a look with this image that just came out later tonight when I get back
<plars> kgunn: until then, the automated tests are running (with surfaceflinger)
<plars> kgunn: is anyone looking at the difference in responsiveness of mir vs. surfaceflinger?
<lool> plars: hey
<kgunn> plars: wrt responsiveness....we'd need data
<plars> lool: hi
<lool> plars: could we sync on the current Mir status
<kgunn> plars: wrt testing... olli was really wanting us to have a (manually produced if required) aggregate view of all the data from what we would normally run on SF...but run no mir
<plars> kgunn: I don't have hard data, just observation from manually unlocking the screen. Is there any way to rig a framerate counter or something?
<olli> no/on
<lool> plars: both on the status of running the Mir tests and the actual number of tests passing
<lool> plars: also, where is the piece of code unlocking the screen that we need to fix?  :-)
<plars> lool: I have to take my son to something in just a few min. but the basic status is that we can only run tests manually for right now because unlocking the screen doesn't seem to work with mir using the methods we used before
<plars> lool: one sec
<plars> lool: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/files/head:/utils/target/ (see the unlock_screen stuff there)
<lool> ok thanks
<lool> thomi: so in lp:~ubuntu-test-case-dev/ubuntu-test-cases/touch there's the piece currently unlocking the screen under utils/target/unlock_screen.py; it's usingthe autopilot input.Touch stuff to unlock; would you know what breaks it on mako?
<lool> with Mir
<thomi> lool: should work fine with mir
<thomi> on mako
<lool> plars: are you testing on mako or maguro?
<plars> lool: usually mako, but I have both
<plars> lool: I really have to run now, will be back later
<lool> see you
<thomi> plars: just to clarify our earlier conversation regarding powerd-cli - that's reuired for mir, since, under mir, unity8 will nto start when the screen is blanked
<thomi> plars: I realise I left that critical piece of information out of my earlier message
<lool> ah
<thomi> so yeah - if we see lots of failures trying to start the unity8 shell, you guys might want to shoehorn that powerd-cli command in somewhere
<lool> thomi: I keep trying to start/stop unity8, it never comes up
<lool> I'm holding a powerd-cli lock
<lool> I do get a crash file though
<thomi> lool: do you have  a stale /tmp/mir_socket?
<thomi> lool: also, what does ~/.cache/upstart/unity8 say?
<lool> thomi: how can I tell?
<thomi> lool: with unity8 stopped, does that file exist?
<lool> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' what():  bind: Address already in use
<thomi> lool: yeah, so check that unity8 isn't already running somewhere
<thomi> and if it's not, rm /tmp/mir_socket
<lool> that helped a bit
<lool> start isn't stuck anymore
<lool> but it's not starting either
<thomi> lool: it takes a while
<thomi> tail -f ~/.cache/upstart/unity8.log
<lool> hmm perhaps I'm not patient enough
<lool> it's indeed starting
<lool> cool
<lool> turning a11y on again
<lool> starting again with a11y
<lool> indeed, it started
<thomi>  \o/
<lool> now trying unlock
<lool> and that worked too
<lool> ok
<lool> so a) add powerd-cli active,  b) rm mir_socket if it's stuck
<lool> thomi: do you know about the bug id for unity8 not coping with screen blanking?
<thomi> lool: no, sorry
<lool> thomi: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235000
<ubot5> Ubuntu bug 1235000 in unity8 (Ubuntu) "Unity8 wont start on Mir when screen is blanked" [Undecided,New]
<lool> kgunn: ^
<thomi> hey guys - I've tracked down the mi-on-maguro problem
<thomi> and the root of it is that "getprop ro.hardware" returns "tuna"
<thomi> when it should return "maguro"
<thomi> any ideas?
<thomi> seems like it should be using ro.product.device
<sergiusens> thomi, that is correct, you want to use what phablet-tools uses
<sergiusens> thomi, ro.product.device
<sergiusens> thomi, ah, didn't read the whole thing
<sergiusens> thomi, also used across the system
<lool> thomi, plars, doanac: https://code.launchpad.net/~lool/ubuntu-test-cases/powerd-lock/+merge/189191
<thomi> sergiusens: cool - thanks
<lool> doanac, plars: Going to bed now, but if you could test this patch and try to run AP tests with it on Mir, that would be great
#ubuntu-ci-eng 2013-10-04
<thomi> I wonder if someone from the CI team could comment on this bug? https://bugs.launchpad.net/autopilot/+bug/1210596 specifically, is this still a problem, or not?
<ubot5> Ubuntu bug 1210596 in Autopilot "Touch broken on nexus4" [Undecided,Incomplete]
<plars> ok, back
<plars> sorry for the delay
<plars> rsalveti: aha, I was wrong there are some places that do adb reboot
<rsalveti> plars: cool
<rsalveti> but noticed sometimes reboot takes quite a bit
<rsalveti> at least I fixed the adb respawn when shutting down
<plars> rsalveti: well, I've had issues when rebooting with adb shell reboot today - at least with mir enabled
<rsalveti> adb shell reboot; adb wait-for-device should work as expected
<rsalveti> hm, right
<plars> thomi: this new unlock change that you and lool discussed earlier doesn't seem to be working for me
<plars> "Starting Unity with testability" is as far as I get, and it just stops there
<thomi> plars: on a mako?
<plars> thomi: yes
 * thomi reads the code
<plars> thomi: haven't tried on maguro yet
<thomi> plars: it won't work on a maguro
<plars> ok
<thomi> it should work tomorrow though
<plars> thomi: what's up with maguro?
<thomi> plars: bug in ubuntu-platform-api
<thomi> fixed already, just need to get it in the image
<thomi> plars: where can I see that unlock code? I'm sure I had it open...
<plars> thomi: look at lool's branch here: https://code.launchpad.net/~lool/ubuntu-test-cases/powerd-lock/+merge/189191
<thomi> what am I searching for? that's a massive diff
<plars> thomi: it's against the wrong branch, just look at the latest change
<thomi> oh, nvm, found it
<thomi> plars: ahh, I think I see the problem
<thomi> or, maybe not
<thomi> hmmm
<plars> thomi: if you have something you want me to try locally, I can do so easily
<thomi> plars: if the 'start' command is failing, it usually means one of two things:
<thomi> 1) The screen is blanked
<thomi> 2) There's a stale /tmp/mir_socket file lying around.
<thomi> In either case, upstart will endlessly try and restart unity
<thomi> and block forever
<thomi> :(
<thomi> so I'd make sure unity8 isn't running
<thomi> then rm /tmp/mir_socket
<thomi> the make sure you have a wakelock with powerd (make sure 'powerd-cli active' is runing somewhere)
<thomi> then start unity8
<thomi> it's all a bit fragile at the moment :-(
<plars> thomi: sounds like
<plars> thomi: seems like unlocking has been a struggle for a long time - any chance of it ever being sane?
<thomi> I had a hangout call with kgunn about it this morning
<thomi> so I'd say "yes", but not for 1.0
<plars> well, rebooting seems to work a little happier now at least
<plars> thomi: there was definitely a stray /tmp/mir_socket lingering around, let me see what I can do about that
<thomi> that'll be the problem
<plars> err
<plars> this isn't good
<plars> when I reboot, I lose the device
<plars> rsalveti: is this related to what you described earlier?
<plars> rsalveti: I don't see it in adb devices anymore
<rsalveti> plars: after the device is fully booted again?
<rsalveti> if so, it might be the issue with adb x mtp
<plars> rsalveti: doesn't look like it, the screen is just black, and device is unresponsive
<rsalveti> plars: right, so it's still rebooting
<rsalveti> plars: that's the issue I noticed today
<plars> rsalveti: had to hard poweroff the device
<plars> ok
<plars> just takes forever?
<rsalveti> plars: yeah, tried on maguro a few minutes ago and it took more than 2 minutes to reboot
<plars> wow
<rsalveti> something is wrong in our shutdown logic
<plars> thomi: ok, so I still can't get the unity8 tests working at all, but at least I can get other tests working *I think*
<thomi> plars: what happens with the unity8 tests?
<plars> thomi: I never see anything on the screen at all
<plars> thomi: and they all fail
<thomi> plars: got a test log I can peek at?
<thomi> even just for one test - I'm curious to see the failure condition
<plars> thomi: http://pastebin.ubuntu.com/6188183/
<thomi> hmmmm
<thomi> ProcessSearchError: Process exited with exit code: -6
<thomi> what's signal 6?
<thomi> SIGABT
<thomi> also, this: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<thomi> what(): display factory cannot create fb display
<veebers> thomi: the error message appears there too
<veebers> heh, beat me to it
<thomi> ahhh
<thomi> plars: can you try running this manually on the phone? 'unity8 -testability -fullscreen' - I bet it'll fail. Veebers, didn't we remove -fullscreen earlier today?
<veebers> thomi: hmm, I wrote the code
<thomi> that may be the problem - mir interprets '-fullscreen' as '-f ullscreen'
<veebers> thomi: ugh, yeah let me push and propose :-\
<veebers> it got lost in the flurry
<thomi> because, you know... programming
<plars> phablet@ubuntu-phablet:~$ unity8 -testability -fullscreen
<plars> __pthread_gettid -2
<plars> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<plars>   what():  Could not unblank display
<plars> Aborted (core dumped)
<plars> thomi: ^
<thomi> plars: now try without -fullscreen :)
<veebers> plars: try it without the'-fullscreen'
<thomi> heh
<veebers> ugh thomi you're too fast
<plars> thomi: oh wait, let me do the powerd thing..
<plars> thomi: ok, with powerd-cli active it seemed to do a bit more
<thomi> ahh
<plars> thomi: yeah, with powerd-cli active running in the background, it worked
<thomi> with -fullscreen'?
<plars> thomi: yes
<thomi> huh, I guess that already got fixed in the image
<thomi> plars: so it still doesn't work for the tests though?
<plars> thomi: well, let me try something
<plars> thomi: the unity8 tests are special
<thomi> yes they are :)
<plars> heh
<veebers> thomi: remind me why we removed -fullscreen earlier? (submitting a bug to attach)
<thomi> veebers: it's not needed on the phone, and it caused problems with mir this morning. They may have patched mir by now though
<veebers> thomi: thanks
<veebers> thomi: are you alright approving it? https://code.launchpad.net/~veebers/unity8/remove_fullscreen_argument/+merge/189207
<thomi> veebers: that's only on the device, right?
<veebers> thomi: yep, otherwise width|height are set to a value
<thomi> approved. I have to step out for a bit, but I'll be back again
<veebers> thomi: cheers
 * thomi is back
<lool> plars: heya
<lool> plars: so reading through the backlog, it seems the issues you were seeing were around boot time / shutdown on one side, and sometimes mir_socket; the powerd-cli active thing is the equivalent of the dbus code I've added, except it's actually easier to do the dbus thing in python than spawning and stopping a subprocess cleanly IMO
<lool> (hey alL!)
<lool> psivaa: hey
<lool> psivaa: did you dive a bit in failing tests on 80?
<psivaa> lool: yes just started a couple of them and watching them
<lool> ok
<lool> psivaa: ok, unity8 is probably the longest but most interesting on es
<lool> *one
<lool> the other ones are relatively isolated and seem to be in apps themselves, not 100% sure though
<lool> psivaa: how's the Mir stuff looking this morning?
<psivaa> lool: ok, ill try unity8 in one device
<ogra_> we lost dbus.log from utah
<ogra_> :/
<psivaa> lool: i am just starting to do the Mir stuff
<lool> psivaa: ok
<lool> psivaa: (how many devices do you have? :-)
<lool> ogra_: ?
<psivaa> lool: locally only one maguro
<lool> hmm that's not much
<lool> psivaa: so you're testing Mir on maguro?
<lool> must not be going well
<psivaa> lool: yes, until yesterday the results were not that good on that
<lool> psivaa: ah but you're running remote tests?
<psivaa> lool: yea
<ogra_> lool, http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4539/unity8-autopilot/ image 79 ... and the same test on image #80 http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4541/unity8-autopilot/
<ogra_> lool, with a dbus change from xnox inbetween, i guess that changed the logging behavior somehow alongside
<lool> ogra_: but I see dbus.log there
<ogra_> lool, in the second link ?
<lool> ah
<ogra_> :)
<lool> indeed, always empty
<lool> hmmm
<ogra_> root@ubuntu-phablet:/# ls /home/phablet/.cache/upstart/dbus.log
<ogra_> ls: cannot access /home/phablet/.cache/upstart/dbus.log: No such file or directory
<ogra_> freshly flashed, first boot
<lool> Poked xnox
<ogra_> i assume just adding a "console log" to the upstart job might help
<ogra_> i did already 30min ago
<lool> ogra_: did it work?
<ogra_> havent tried that
<ogra_> one sec
<ogra_> image isnt writable yet and i want to check some things before doing so
<lool> ok
<lool> sil2100, Mirv: how are things for you guys this morning?
<sil2100> lool: morning! I'm updating my device and will test indicators
<ogra_> yay, the dbus fix helps a good bunch
<ogra_> stopwatched my boot takes 25sec from vibration to unity now
<seb128> ogra_, what sort of issues does it fix? segfaults?
<ogra_> on mako
<Mirv> lool: busy, but ok..
<ogra_> seb128, boot delays
<seb128> ogra_, is the dbus-daemon zombie going away with it?
<ogra_> seb128, i'll check after the landing meeting, need to set up bootchart etc
<seb128> ok
<Mirv> settings in, some qtbase work, ui-toolkit testing (just one commit), now testing unity8
<ogra_> but from the gut feeling it does
<ogra_> boots a lot faster
<ogra_> (excelpt for the first boot where apparmor hogs the device)
 * ogra_ gets coffee
<xnox> ogra_: console log is the default.
<sil2100> lool, Mirv: I'll be back in a moment and join the meeting, need to reboot my modem as it's beeping loudly
<lool> sil2100, vila: Joining
<lool> ok
<sil2100> brb
<vila> lool: omw
<Mirv> lool: I'll do more testing but I'd need packaging acks http://pastebin.ubuntu.com/6191237/ (indicator-network) http://pastebin.ubuntu.com/6191239/ (unity-notifications) http://pastebin.ubuntu.com/6191241/ (unity8)
<ogra_> xnox, well, it would be nice to get the logs back .... the fix helps a lot with boot speed btw !
<Mirv> psivaa: add daily-build PPA and apt-get install unity8-autopilot unity8-fake-env unity8 unity8-private qtdeclarative5-unity-notifications-plugin indicator-network
<psivaa> Mirv: sure, will do
<psivaa> Mirv: what version of autopilot that you are using? .. just to confirm
<Mirv> psivaa: it's the new one, I just checked
<Mirv> 1.3.1+13.10.20131003.1-0ubuntu1
<psivaa> Mirv: ack
<Mirv> ie. I flashed image 80
<lool> Mirv: forgot to ask, what's status on toolkit update?  you had reported some bugs to SDK team, and then they went to fix them, did they come back with fixes in trunk?
<Mirv> lool: balloons was looking at it, apparently path changes that need to be fixed in the apps but is still ongoing, branches linked at https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1234544
<ubot5> Ubuntu bug 1234544 in Ubuntu UI Toolkit "Several apps have failing tests with 20131003 ui-toolkit" [Critical,In progress]
<lool> Mirv: were there other regressions in the toolkit outside of this?
<Mirv> lool: not known, that caused so many errors it was hard to say
<lool> ok
<Mirv> lool: can you look at the packaging acks at :31 ^
<lool> Mirv: so you'd need another round of testing with these fixes in place to find out
<Mirv> lool: plus http://pastebin.ubuntu.com/6191421/, so that I've everything ready ack wise when I've done testing
<Mirv> lool: yes
<lool> Mirv: looking at packaging acks
<lool> Mirv: ok for packaging changes
<lool> Mirv: oh sorry just first one
<lool> Mirv: indicator-network is +1
<lool> Mirv: what do we need to rebuld for unity-notifications change in Provides?
<lool> ah unity8
<Mirv> that, yes
<lool> Mirv: ok for unity8 and unity-notifications
<lool> Mirv: might want to keep an eye on new indicator though
<lool> +  * Added an indicator which is displayed in the search bar whenever a
<lool> +    search is in progress. Added accompanying test in tst_PageHeader.
<lool> Saviq: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235000
<ubot5> Ubuntu bug 1235000 in unity8 (Ubuntu) "Unity8 wont start on Mir when screen is blanked" [Undecided,New]
<Mirv> right
<Saviq> lool, https://bugs.launchpad.net/mir/+bug/1216237
<ubot5> Ubuntu bug 1216237 in mir (Ubuntu) "Mir silently overwrites and reuses /tmp/mir_socket, rendering the previous server useless" [Medium,Fix released]
 * lool &
<sil2100> lool: as for indicators, I'm not sure if we should release indicator-network today, as it requires the new unity8 to be released with it
<Mirv> sil2100: no, that's the item above yours that I'm handling, don't worry about indicator-network :)
<sil2100> Ah! ;)
<Saviq> lool, can you link me the doc? I'll put a ~table of suites to add their "owners" to under mir
<Saviq> lool, http://studio.sketchpad.cc/uRlqdixl3G?
<Saviq> plars, hey can you please point me as to how to run click autopilot suites?
<Saviq> plars, I saw some "click-setup-autopilot-something-fancy-stuff"
<Saviq> but can't find it now
<cjwatson> phablet-click-test-setup isn't it?
<Saviq> cjwatson, thanks!
<psivaa> Mirv: lool: i've run unity8 tests locally with clean 80, 3 times and all the times they passed without failures. Not sure what's causing the 2 failures in the lab..
<psivaa> looking though
<lool> psivaa: Ok, it might also be the unity8 update in the PPA fixing it?
<lool> psivaa: but if they pass for you, it's good
<psivaa> lool: i have not done the update yet though..
<lool> Saviq: thanks, I was about to satrt a google doc spreadsheet actually
<Saviq> lool, whatever you prefer
<lool> Saviq: I'd like to collect results with image numbers, testers, failures etc. (a bit like report.qa. but manually since that's what we have)
<lool> psivaa: ok, don't spend more time on this, it passes locally for you, that's good
<lool> psivaa: move to the update and/or mir stuff  :-)
<Saviq> lool, just let us know where to push our results
<psivaa> lool: yep doing that :)
<lool> Mirv: are you done with indicator-network testing?  otherwise I thought we could try with the NM changes
 * lool is not as efficient as didrocks on thinking this through
<Mirv> lool: yes, the i-n + unity8 + unity-notifications is now published. but now for a late lunch.
<Mirv> the new password prompt was quite neat looking
<lool> Saviq: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0ApRxJIi-SaMddEdtdWtMaXNkMzYtN2puZ2YxdU9MekE#gid=0
<lool> Saviq: just shared read/write now
<lool> Saviq: I've moved most inprogress tests
<lool> psivaa: ^
<lool> psivaa: spreadsheet to track Mir results https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0ApRxJIi-SaMddEdtdWtMaXNkMzYtN2puZ2YxdU9MekE#gid=0
<lool> Mirv: good lunch
 * lool lunches too
<psivaa> lool: ack, will use that
<Saviq> psivaa, if you haven't really started calculator yet... I'm running it
<Saviq> psivaa, sorry - should've added to the spread already, but got calendar and calculator confused...
<psivaa> Saviq: ok, i've just started to run.. let that finish and then ill go to webbrowser
<Mirv> sil2100: regarding your unity7 remark, it always has failing tests so the question is that are there more, and whether they can be manually marked as false alarms (as before)
<Mirv> sil2100: I already released libunity and unity-scope-home yesterday, and on my own machine the tests were fine. so, you can also compare to for example this check run http://localhost:8080/job/autopilot-saucy-daily_release/2311/ <- that's the result, on reality on my own machine I got only 20 FAILs and they were false alarms as well (actual functionality worked)
<Mirv> sil2100: ok forget the last remark, obviously I only tested those components I was about to release, so you can't assume that run as a whole was ok. but anyway, you know the drill, manual work..
<sil2100> Mirv: I know, I was running some AP tests already on unity7, and it looks fine - mostly false positives
<psivaa> balloons: just to confirm, are you dealing with all the core app smoke failures with bug #1234544?
<ubot5> bug 1234544 in Ubuntu UI Toolkit "Several apps have failing tests with 20131003 ui-toolkit" [Critical,In progress] https://launchpad.net/bugs/1234544
<mzanetti> psivaa: hey. I'm struggling running autopilot with mir on the galaxy nexus and was told you see the same
<mzanetti> any solution yet?
<mzanetti> like: there seems no input at all, screen blanks during tests and cannot be woken up again after that
<psivaa>  mzanetti i had packages from unity daily ppa and Saviq said that's not intended
<mzanetti> hmm... I just did a clean flash
<mzanetti> installed the autopilot package and ran tests...
<Saviq> mzanetti, ah no input?
<Saviq> mzanetti, I *think* I read something about that about the galaxy
<Saviq> lool, you aware of what that was â? no input during autopilot on maguro?
<mzanetti> (works fine with SF)
<Mirv> sil2100: ok, sounds good, hopefully that holds.
<thomi> mzanetti: Saviq: re no input on maguro - known issue, fixed, waiting to be landed in the image
<thomi> it's a defect in python-upa
<Saviq> thomi, released yet?
<thomi> already in the landing pipeline SS
<Saviq> thomi, ok, so no
<thomi> Saviq: it's in trunk, I haven't checked since I finished work
<Saviq> mzanetti, you can build python-upa out of lp:python-upa to fix your input
<Saviq> psivaa, â you'll want that too
<Saviq> actually /me builds
 * thomi -> EOW
<Saviq> aaand it rebooted :/
<psivaa> Saviq: ohh ok, thanks. that may explain my first run of webbrowser test failures (34/35 failed) thanks
<lool> Saviq: yes, that's fixed with python-platform-api update I think
<lool> Saviq: the maguro thing was that autopilot/python-platform-api/platform-api are using an unsupported android property; it happens to work on mako, but not on maguro; another property works though
<Saviq> psivaa, will have a fixed package in 5
<Saviq> lool, yup, got it
<lool> Saviq: if you update python-platform-api, it shoudl work though
<Saviq> lool, not released yet
<psivaa> Saviq: thanks
<lool> Saviq: it's being tested, it's in ubuntu-unity/daily-build PPA
<lool> Saviq: see landing spreadsheet
<Saviq> lool, right, I don't trust the daily-build ppa ;P
<Saviq> lool, if it's not released - it's not there!
<lool> Saviq: forgot device in Mir tests; would you add the ones you know?
<lool> I'm assuming mostly mako
<lool> psivaa: ^
<lool> Saviq: haha
<lool> Saviq: it's in flight
<lool> Saviq: this is just to unblock you and to give you status
<lool> Saviq: if it's not in a *PROMOTED IMAGE* it doesn't exist  ;-)
<lool> (we have even harder rules  ;-)
<Saviq> lool, yup :)
<sergiusens> lool, ogra_ can we add upstart into the landing plan? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234898
<ubot5> Ubuntu bug 1234898 in upstart (Ubuntu) "upstart-local-bridge not handling all events sent to it" [Undecided,In progress]
<sergiusens> lool, ogra_ it's a fix for the upstart-local-bridge which is not used by anyone yet, so should be low impact
<Saviq> psivaa, here's the fixed package http://people.canonical.com/~msawicz/papi/
<lool> sergiusens: Yes
<lool> sergiusens: please upload ASAP
<ogra_> sergiusens, yeah
<psivaa> Saviq: thanks, will update
<sergiusens> lool, ogra_ well we need jodh to do that :-)
<ogra_> sergiusens, pinged him in -touch
<lool> I've pinged him in -release
<lool> gah, I'm so late in testing and in sending emails out
<sergiusens> wow, I thought this was an off the radar fix :-)
<lool> I've had an issue with my laptop's saucy, wasted one hour
 * ogra_ still fights with ureadahead today 
<ogra_> system-image breaks it :(
<lool> ogra_: how so?
<ogra_> lool, ureadahead uses /var/lib/ureadahead/debugfs for reading ... to make uredahead work i need to make /var/lib/ureadahead writable so it can store its pack files there ...
<ogra_> making it writable mounts  rw fs over the existing /var/lib/ureadahead and the debugfs mount is hidden
<lool> ogra_: talk to stgraber about best way to handle this I guess
<lool> ogra_: it's not urgent I guess
<ogra_> i can easily work around it by adding a pre-start script to the ureadahead upstart job that remounts /var/lib/ureadahead/debugfs before firing up, but waiting on stgraber, probably system-image stuff can work around this
<ogra_> lool, well, i'd like to have a sane boot by reklease ... its one of many small issues
<lool> ogra_: can you also track the status of the powerd changes?
<lool> ogra_: these are in the spreadsheet for many days now
<ogra_> (not as big as the hud dieing all the time and delaying the boot by 20sec indeed)
<ogra_> lool, yeah, will land it today ... but probably not for 81
<lool> ogra_: can you test the dbus binaries that got uploaded on touch?
<lool> ogra_: I've added a row for you on this one
<ogra_> lool, i tested it before the upload happened :) but will verify it also works with the package
<lool> ogra_: thanks
<sil2100> Mirv: ok, I actually checked all the failing tests - 99% of them are either false positives (so test environment issues), others are AP issues - I'll report those to bregma and release ;)
<psivaa> Saviq: mzanetti: no luck yet even with the upa package above (1.1+13.10.20131001.1-0ubuntu2~sbuild1) on maguro.
<Saviq> psivaa, do you see stuff happening on screen at all?
<Mirv> sil2100: \o/
<psivaa> Saviq: that i see, webbrowser is opening but the tests at some stage are failing
<Saviq> psivaa, but I mean do the test interact with the browser at all?
<Saviq> psivaa, or does it just launch it and sit there
<bregma> sil2100, we track all the failures in the Unity7 builds and already have bugs open on the non-environmental ones
<mzanetti> without that bran it gets launched and sits there. but not waiting for the usual autopilot 10 secs timeout but closing down faster
<psivaa> Saviq: webbrowser launches, opens the localhost web and then it does not do anything more
<psivaa> s/localhost web/web page/
<sil2100> bregma: awesome
<bregma> it would be more awesome if there were no bugs, but we're doing our best
<sil2100> bregma: since I also noticed that there seems to be something wrong with for instance self.assertVisibleWindowStack(), as the visible window stack seems to be OK, but the call still fails as if it was not ;)
<sil2100> bregma: not sure if that's even because of unity, or maybe an autopilot issue itself
<Saviq> psivaa, sounds like your input issue isn't solved indeed
<Saviq> psivaa, can you try with the version from daily-build ppa then?
<psivaa> Saviq: ack, will do. thanks.
 * psivaa -> reboot
<Saviq> lool, btw, for the "unity8 is launching slow" - it's most probably hud-service crashing - and unity8 is blocking on that service with a timeout
<lool>  trying to overwrite '/usr/share/icons/ubuntu-mobile/apps/144/gallery-app.png', which is also in package ubuntu-mobile-icons 13.04+13.10.20130925-0ubuntu1
<lool> Saviq: great discovery
<lool> Saviq: indeed, hud seems quite unhappy
<lool> Saviq: they recently added some debug to see what was going on
<lool> Saviq: generating the crash file will also slow down the device
<Saviq> lool, yup
<lool> Saviq: did you find a crash file for hud and an existing bug report?
<lool> Saviq: could you raise it with ted/whoever worked on this last?
<lool> sergiusens: heya
<lool> sergiusens: we're reading up to switch to Mir
<Saviq> lool, yeah
<lool> sergiusens: not this image, but soon
<Saviq> lool, it's always the same crash
<Saviq> lool, have made apport ignore it for now..
<lool> sergiusens: would you know how to patch the image build to touch .display-mir (or .display_mir I never remember which, I touch both  :-)
<ogra_> lool, Saviq, http://people.canonical.com/~ogra/ubuntu-touch/bootchart-maguro-hud-dbus-hang.png ... watch the dbus zombie ...  vs http://people.canonical.com/~ogra/ubuntu-touch/bootchart-maguro-SF.png
<lool> sergiusens: that way, people could opt out of it and they keep what they had
<sergiusens> lool, .display-mir
<ogra_> seems the HUD gets dbus in a weird state
<ogra_> when it crashes
<lool> sergiusens: if you could prepare that change in a bzr branch, that would be cool
<lool> sergiusens: especially since I might be enabling this over the WE
<Saviq> ogra_, /me no grok those charts ;)
<sergiusens> lool, it's 3 locations currently; we are ramping up a phablet-config tool with doanac and cwayne, i thought I'd just add a switch there to --enable disabel mir
<ogra_> Saviq, it shows that with SF todays image boots in ~30sec ... but with Mir hud-service crashes and tears down dbus with it ... which results in a 50sec boot
<Saviq> ogra_, ught
<ogra_> Saviq, mhr3_, pete-woods and ted are on it since yesterday
<Saviq> good
<ogra_> (probably longer)
<lool> sergiusens: yes, that's useful; we still need a way to enforce the default, and that ought to be in the image
<lool> home/phablet was perhaps a poor choice, but it's all hooked up with this now, so I'd rather we use this rather than doing code changes somewhere else
<fginther> morning
<sergiusens> lool, we talked about it, on ro it was sort of the only choice at the time; location readable and writable by users and system; and to be honest, it was supposed to last a week tops ;-) so creating another writable location for this seems a bit too much
<sergiusens> lool, that said, we can transform it into a property now :-)
<lool> :-)
<lool> fginther: good mooooornnnnniiiiiiiing!
<thostr_1> lool: can you scheudle landing ask line 93 so that we finally get thumbnailing working?
<psivaa> Saviq: i'll enter my maguro results at the bottom of the page if that's ok
<Saviq> psivaa, well... if you don't get input... kind of beats the purpose
<psivaa> Saviq: that's true.. the output is the same, even with upa from the daily ppa: 1.1+13.10.20131004-0ubuntu1
<Saviq> lool,
<Saviq> ââ
<lool> thostr_1: ubuntu-ui-toolkit is not going in soon
<lool> thostr_1: it's pending fixes
<sil2100> lool: are we running ubuntu-keyboard tests now automatically on the image testings?
<lool> thostr_1: so it would kind of pollute the view (much like the open URL stuff staged already, blocked on ui-toolkit)
<lool> thostr_1: also, Mir going in pretty soon
<sil2100> lool: since those are failing badly for the new ubuntu-keyboard right now
<lool> thostr_1: so this will be likely be next week
<thostr_1> lool: ok
<lool> psivaa: do you know about keyboard tests in images?
<lool> sil2100: and if you downgrade?
<lool> sil2100: doesn't look like we are
<mzanetti> Saviq: psivaa: I installed that python-upa thing. Now I get all input twice
<lool> plars, doanac: When you guys come up, can we hangout on status of lab infra for Mir tests?
<plars> lool: I wondered if it should do about the same thing, but for some reason when I tried your code by itself, it didn't work for me. When I added something running powerd-cli active in the background though, it worked
<mzanetti> e.g. dialer_app tests dial 114444 instead of 144
<lool> lol
<psivaa> lool: hmm no.. iirc plars was doing it, let me see if i can get any information about it
<plars> lool: tests are running in the lab now
<plars> lool: you just won't see them on the dashboard
<lool> mzanetti: it allows typing numbers like 0088112244 faster though
<lool> mzanetti: did you reboot?
<mzanetti> yeah... especially if you use autopilot as dialing facility
<ogra_> yeah, pick your friends by the number :)
<mzanetti> lool: yep, did that
<lool> plars: \o/
<plars> lool: I hope to get the keyboard tests added today - there was a period of time where they wouldn't work, but now they should
<lool> plars: what's the dashboard issue?
<psivaa> lool: mzanetti: i ran music and webbrowser tests with the upa from ppa but no improvement on maguro
<plars> lool: it just doesn't know to add the mir tests
<ogra_> it only shows official tests
<plars> lool: it's possible I could just name it something different, need to talk to josepht about it in a bit, he's the expert :)
<lool> psivaa: ok; thanks for the feedback (that's on Mir IIUC); mzanetti seem to be looking at this
<lool> mzanetti: right? ^
<mzanetti> lool: yes, on mir
<lool> mzanetti, thomi: We seem to have issues with python-upa; it's not fixing the input issue on maguro
<psivaa> lool: yea that's with Mir
<Saviq> lool, thomi is EOW
<sil2100> lool: I'll double check, then I'll do dogfooding and release if all is ok
<lool> Saviq: crap
<sil2100> lool: since from what I heard it's a known issue
<lool> Saviq: does someone else understand his code / changes?
<Saviq> lool, dandrader, probably, but he's on a slightly more important thing now
<plars> lool: until then: https://jenkins.qa.ubuntu.com/search/?q=saucy-touch_mir will find the raw jobs for you
<Saviq> lool, but greyback might, too
<lool> plars, doanac: Which one of you could represent lab status best in the standup in 40mn?
<Saviq> plars, lool any idea how to run clicks' autopilot tests? we managed to get the suite installed, but can't get autopilot to find the app
<lool> plars: good
<plars> lool: what kind of lab status are you looking for? If you need someone from the lab, that would be retoaded or rfowler. I'll be happy to be there though
<lool> plars: Adding a view >> we plan to switch on Mir later today / this week-end; what does that mean if we create a view?
<lool> plars: can we keep SF runs by removing the touch .display-mir thing? (rm before running SF)
<lool> plars: Status of running our image AP tests in lab for Mir images
<plars> lool: it means we shouldn't bother creating a view :)
<fginther> ev, ping
<plars> lool: so, despite the issues, we're still going to mir by default now?
<fginther> ev, nevermind
<plars> lool: so, one thing I guess we could do is make sure the touch_mir jobs are on there, and then reverse the logic when it becomes the default - have the touch_ro jobs remove the .display-mir file, and have the touch_mir jobs just run as normal
<lool> plars: we're fighting our way hard to get to Mir as default
<lool> plars: but I think we want the two views
<lool> plars: to keep the rollback to SF option open for at least some days
<lool> sorry for the extra work
<lool> plars: So I'll invite you for lab status
<plars> lool: what kind of lab status are you looking for?
<lool> plars: 15:22 < lool> plars: Status of running our image AP tests in lab for Mir images
<plars> ah, ok
<plars> missed that one :)
<lool> I think you understand this
<lool> even if you're not directly tweaking all the knobs
<plars> lool: yes, I can certainly talk about that
<cjwatson> Huh, we seriously dropped flight mode?
<cjwatson> That's a ... surprising decision
<lool> cjwatson: the UI for it
<lool> cjwatson: but the backend never got done
<cjwatson> Yeah, I know, I'm surprised that's not a hard requirement
<ogra_> you just need to switch off devices individually
<ogra_> the individual settings use the same rfkill commands i think
<ogra_> (as flightmode would)
<plars> lool: I see where to add a view for it I think, pushing a branch now
<lool> psivaa: can you confirm: webbrowser-app tests just output a bunch of broken pipe exceptions after each test, but that's normal, ys?
<plars> lool: yes, that's normal - I talked to someone... osomon maybe? about it a while back and they confirmed it was expected
<psivaa> lool: i have seen broken pipe exceptions once in a while.. not so every time though.. but that does not normally impact the output result
<psivaa> plars beat me :)
<sergiusens> lool, is 78 the latest stable image?
<lool> sergiusens: that seems correct
<sergiusens> lool, thanks
<psivaa> lool: re: the puthon-upa test on maguro.. i have not updated the landing task page with my results.. don't have the permission to edit
<psivaa> lool: task 81 that is
<lool> psivaa: will note them; thanks a lot for testing
<psivaa> lool: yw :)
<lool> psivaa: Could you update bug #1234956 with your findings?
<ubot5> bug 1234956 in python-ubuntu-platform-api (Ubuntu) "Autopilot input device has invalid X & Y axis on maguro" [Undecided,New] https://launchpad.net/bugs/1234956
<lool> mzanetti: ^
<psivaa> lool: ack, will do
<mzanetti> lool: already found it. fixing it
<lool> mzanetti: awesome
<mzanetti> lool: actually it was swapped with manta screensize
<lool> psivaa: ^ new package coming up soon
<psivaa> mzanetti: lool: ack
<lool> mzanetti: please can you ping me when it's happroved?  I think this should be merged by hand if it's trivial enough diff wise
<lool> mzanetti: want to land this yesterday  :-)
<lool> sergiusens: how does it work to update kernels?
<lool> sergiusens: do we have to rebuild android, or is this picked up at image build time?
<sergiusens> lool, I wasn't involved in the re packaging of android; a regular android build pulls in the latest kernel; maybe ogra or xnox decoupled that when doing the packaging
<cjwatson> I have an archive-cleanup upload to a source that generates one binary in the touch image, but it only actually changes a -dev binary not in the image
<cjwatson> Do I need a landing ask for that?
<cjwatson> Specifically http://paste.ubuntu.com/6192290/
<lool> cjwatson: no that's good to upload without landing pipeline
<lool> cjwatson: wont directly affect the image, might just break builds
<lool> cjwatson: but thanks for the heads up
<ogra_> lool, the android pakcage build creates the boot.img, on upgrades that gets flashed
<ogra_> lool, android pulls in the kernel binary packages
<ogra_> during build
<sergiusens> ogra_, so it's not decoupled?
<ogra_> sergiusens, nope
<lool> ogra_: so we do have to rebuild android after each kernel upload
<sergiusens> lool, so new kernel means new android build
<lool> ok
<ogra_> kernel and initrd are fed into the build, out comes a boot.img
<lool> that's what I thought
<lool> new kernels for AA fixes coming up soon
<sergiusens> lool, AA means so many things :-)
<ogra_> lool, can you talk to apw, i asked for a missing patch on mako
<ogra_> might make sense to have that in the same upload
<lool> Mirv, sil2100: Trying to assess time before building an image; what stuff do you guys still have in the pipe for today?
<lool> ogra_: so shutdown is broken too
<lool> I think we don't want to relesae without shutdown
<ogra_> lool, yes
<ogra_> oh wait shutdown ... i didnt test that
<ogra_> only reboot
<lool> I just did
<lool> both are affected sadly
<lool> bah
<ogra_> :(
<sil2100> lool: ubuntu-keyboard is coming right up, it got published so it should be in the pocket soon
<ogra_> the upstart upload we had had only test fixes
<sil2100> Shutdown broken?
<ogra_> the only upstart job change i see is the one from sergiusens ... but that only touches start on stanzas
<ogra_> sil2100, and reboot
<mzanetti> psivaa: lool, Saviq: https://code.launchpad.net/~mzanetti/python-ubuntu-platform-api/fix-resolutions/+merge/189320
<Saviq> mzanetti, \o/
<sergiusens> ogra_, hmm, yeah; I only did start on
<sergiusens> ogra_, lool any estimate on since when it was broken?
<lool> == Published webbrowser-app ==
<lool> Wont publish gallery-app today; AP regressions + file conflicts
<sergiusens> ogra_, afaik rsalveti and plars were discussing this yesterday
<ogra_> rsalveti, chanages adbd to stop on runlevel change ... but that also seems to work fine
<lool> sergiusens: in the last 2 images I'd say
<lool> sergiusens: should be good on #78
<ogra_> sergiusens, worked on 78
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131003.1.changes or http://people.canonical.com/~ogra/touch-image-stats/20131003.2.changes must have the offending change
<lool> Saviq: Diff being trivial, could you land https://code.launchpad.net/~mzanetti/python-ubuntu-platform-api/fix-resolutions/+merge/189320 if it takes more than 30mn to get merged?
<sergiusens> it indeed works on 78
<lool> fginther: if you could bump merging of https://code.launchpad.net/~mzanetti/python-ubuntu-platform-api/fix-resolutions/+merge/189320 to top of queue, much welcome
<Saviq> lool, will do
<cjwatson> lool: done, thanks
<sergiusens> ogra_, lool last time we had this it was ofono holding the shutdown (a fork/daemon miss config in the job)
<lool> sergiusens: seems very likely; BTW we just switched dbus to doing this, maybe that's the issue?
<lool> xnox: ^
<ogra_> sergiusens, well, xnox added a fork, but ot the session dbus ...
<fginther> lool, it's builidng
<sergiusens> ogra_, lool reboot works on 79 as well
<ogra_> but the session dbus should be teared down with the session (theoretically)
<ogra_> yay, thanks for testing that
<ogra_> boils down to http://people.canonical.com/~ogra/touch-image-stats/20131003.2.changes
<sergiusens> ogra_, had that on my manta; I'm upgrading now unless you want me to test something else
<ogra_> nah, go ahead
<apw> ogra_, yep that will likley slide in with teh AA fixes
<ogra_> yay
<ogra_> thanks :)
<doanac> plars: i'm looking at: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/revision/41 specifically the call to "powerd-cli active"
<doanac> is that what we merged for lool here: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/revision/40
<doanac> just via dbus?
<plars> doanac: that's what lool said
<plars> doanac: but thomi was saying I needed it still, sure enough I tried it and it worked (lool's patch alone wasn't working for me though)
<doanac> plars: okay.
 * doanac woke up too late :)
<plars> doanac: I also found that you really do have to have it running in the background
<doanac> that was going to be another question.
<plars> doanac: I didn't believe him at first, because it looked like I could run powerd-cli active and just kill it, and the screen still appears to be on
<plars> doanac: but it didn't work still
<plars> doanac: I had to leave it running
<doanac> works for me.
<plars> doanac: so... it works, and thomi agreed it's pretty hairy to unlock the screen programatically right now, but isn't hopeful for a saner solution until post 1.0
 * doanac wishes we weren't the ones carrying this code around.
<doanac> plars: fginther has a copy of our unlock screen also: lp:~fginther/+junk/autopilot_executer
<doanac> does he need our updates?
<fginther> doanac, possibly, is this specifically for mir
<plars> doanac: he might - fginther yes it's for mir
<doanac> yes
<plars> fginther: which might be the default soon
<plars> fginther: it doesn't work for unity8 though
<fginther> plars, doanac, thanks for the heads up
<doanac> fginther: the two diffs you'd need are:
<doanac> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/revision/40
<doanac> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/revision/41
<fginther> doanac, thanks
<doanac> reading your code paid off! :)
<plars> fginther: I think Saviq is looking at the unity8/mir autopilot issues
<Saviq> plars, fginther, yeah, right now I'm seeing a -fullscreen being passed to unity8 for a reason I can understand
<Saviq> it's gone from our tests...
<fginther> Saviq, was that a recent change (I saw an MP from veebers regarding that I think last night)
<Saviq> fginther, yeah, they removed it
<Saviq> fginther, but it still gets passed to unity8 somehow
<Saviq> FFFFF
<lool> == Building qa stack ==
<lool> (python-upa)
<lool> (not publishing)
<lool> sil2100: shutdown/reboot is fix uploaded
<ogra_> well, there is an improvement
<ogra_> which i'd like to add
<ogra_> just testing it
<lool> ogra_: ?
<lool> what improvement
<ogra_> lool, jodh suggested a slight change to the fix
<lool> popey, ogra_: So given I haven't kicked a build yet, it might be results for 81 will show up only late tonight; do you guys plan to be around late this firday?
<ogra_> with a better syntax for the upstart job
<jdstrand> lool: simple bug fix: may I invoke the lool clause? http://paste.ubuntu.com/6192494/
<popey> lool: sure
<lool> jdstrand: sorry, nothing more going in right now
<ogra_> lool, a bit ... cant predict how long
 * jdstrand adds ask
<popey> wife is out so friday night is playing night
<lool> popey: is that playing at home near the computer, or is that playing outside?  :-)
<popey> outside!?!
<popey> We don't go... outside..
<lool> lol
<popey> do we have a slot for migrating core apps to click packages in the build?
<lool> popey: BTW because of your G+ weekly Lego building posts, I had to buy like 5 of these Lego star wars set
<popey> haha
<lool> mounting one every week too
<popey> excellent
<lool> popey: would you please refrain from posting the next toys though?  thanks
<lool> ;-)
<popey> ok!
<popey> â»
<lool> I've already asked for some mindstorms for my brithday
<lool> seriously
<lool> becoming a kid again
<josepht> lool: awesome!
<popey> lool: the click question above was for you btw â»
<lool> popey: we don't have a slot for it, we've discussed it out of band
<lool> sergiusens: ^ I think it's a next week thing?
<lool> popey: app by app, one by one or so I guess
<lool> sergiusens, popey: I think we can tell upstreams to upload their apps to appstore already
<lool> manually for now
<lool> and setup group permissions
<kenvandine> sil2100, are we able to publish partial stacks now?  i see services was published, but it didn't include content-hub
<sergiusens> lool, we can start including them now fwiw
<sil2100> kenvandine: yes, we're able to do that since a long time! ;D
<sergiusens> lool, we just need to consume from jenkins for the builds instead of the store
<popey> lool: for core apps do _we_ want to upload them so we can update them?
<popey> or the upstream teams?
<sil2100> kenvandine: but in the past we were hacking around to do that, but Didier added proper support for that
<popey> I don't particularly mind either way
<kenvandine> i thought we couldn't publish that way :)
<kenvandine> ah
<sergiusens> popey, lool I asked yesterday and currently the store only allows one login
<sil2100> kenvandine: we do partial-stack-publishing since a few weeks since only certain elements we want to put at once
<jdstrand> lool: fyi, click-apparmor ask on line 127
<kenvandine> sil2100, great :)
<lool> sergiusens: ok, can we coordinate this next week?
<popey> it makes sense to me for us to have one login for doing the core apps
<lool> sergiusens: want to pay attention to the first one getting through, with AP tests etc.
<lool> jdstrand: ok, will review monday
<kenvandine> gallery-app needs content-hub to publish, only change in content-hub is a pkgconfig file added which gallery-app now needs
<jdstrand> lool: thanks
 * kenvandine adds to landing asks
<lool> or earlier if I can
<lool> kenvandine: is there a dep between the two?
<lool> kenvandine: tests were failing for me on gallery-app alone
<lool> deps didnt require new content-hub
<sergiusens> popey, so one login we control and not the individual devs?
<kenvandine> build dep?
<kenvandine> lool, it'll build with what's in daily-build ppa, but not against archive
<lool> kenvandine: oh sorry, just bdep
<lool> right, pkg-config
<lool> kenvandine: good to know
<sergiusens> lool, I thought dropping letters was already enabled with tests
<kenvandine> but the only difference is looking for the pkgconfig file instead of hardcoding
<popey> sergiusens: let me get back to you on that after my next call
<lool> sergiusens: indeed!
<lool> sergiusens: but we do need to flip a switch I guess?
<sergiusens> lool, yeah, we do
<lool> sil2100, Mirv: Did you guys manage to squeeze in some Mir time this PM?
<lool> sil2100, Mirv: How was your experience?  :-)
<ogra_> lool, btw, what was the background behind your kernel/android question before ? if you want to test kernels, we have scripts to flash single zImage files etc
<Mirv> lool: helo, just receiving evening guests in a moment, but I briefly continued testing it but obviously it's the same as I reported yesterday when I released it, ie. I there are no new commits in trunk.
<lool> psivaa: still here?
<lool> psivaa: mind testing python-upa in PPA?
<psivaa> lool: sure
<lool> Mirv: I mean, just in terms of general usefulness of phone with .display-mir enabled
<lool> sergiusens: did you get a chance to find a spot in image build to touch .display-mir?
<Mirv> sil2100: did you mean to release compiz/nux as well? or ido/qmenumodel? I'm just wondering about the whole stacks.
<lool> sergiusens: I might have to land this over the week-end (alone, snif...); I'd rather iron out the change with you before hand
<Mirv> lool: well it starts to be good. as I wrote in the chart, it's not quite as smooth as with flinger, but usable and eg. video works so it starts to be quite ok.
<sil2100> Mirv: no, I just released indicators an unity
<sil2100> *and
<lool> Mirv: right
<sergiusens> lool, an upstart job?
<sergiusens> lool, fastest I can think of
<sergiusens> lool, or a hook in lvecd-rootfs
<lool> sergiusens: how would we preserve removals?
<sergiusens> lool, hooks sounds easier, let me get that
<lool> sergiusens: yes, livecd-rootfs is what I had in mind
<Mirv> sil2100: yeah, it says indicators stack and 'unity 7', ido/qmenumodel belong to the stack at least, not sure if 'unity 7' meant 'unity stack' (as a whole) or justunity
<sergiusens> lool, there's already a create user hook
<lool> plars: You got your branch for the view reviewed (pun intended)?
<sil2100> Mirv: I guess in case of compiz and nux, I think I can publish that as well
<lool> sergiusens: Ok; small preference for livecd-rootfs then
<lool> this is about changing the image default
<sil2100> Mirv: but for the indicator parts - I wouldn't publish without testing more
<sergiusens> lool, I'm prepare an MR and you can review?
<ogra_> lool, new upstart still boots ...
<Mirv> sil2100: right. I'm just thinking that in a few days we should have the to-be-in-release fixes in, so I guess it's good to have currently available fixes in. not sure what's the ido/qmenumodel changes about, but at least nux seems a good performance fix.
<ogra_> lool, what more shoudl i test ?
<lool> ogra_: lxc-android-config?
<Mirv> lool: but with mir trustworthy AP data is of course needed to evaluate it more fully, and performance should be improved so that it wouldn't feel like a regression.
<lool> Mirv: yes; so performance is bad for multiple reasons, one is the number of crashes happening in the background
<lool> Mirv: the AP tests came back pretty good in manual testing
<lool> Mirv: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0ApRxJIi-SaMddEdtdWtMaXNkMzYtN2puZ2YxdU9MekE&usp=drive_web#gid=0
<ogra_> lool, lxc-android-config is already fine
<sil2100> brrr
<Mirv> lool: nice!!
<sil2100> I hate jenkins, it's so easy to click the wrong thing and get stuff running without actually wanting to :|
<Mirv> anyhow, I'm again gone, thanks all for the week
<sil2100> Mirv: see you on Monday!
<lool> Saviq: did you say someone was chasing the input issues for webbrowser?
<Mirv> sil2100: see you!
<sil2100> Have a nice weekend ;)
<psivaa> mzanetti: lool: with the latest upa tests start to pass (dialer 2/2 pass)
<lool> Mirv: bye!
<Saviq> lool, dandrader is
<lool> Mirv: have a good WE
<lool> Saviq: cool
<lool> Mirv: and thanks for all the landings today!  :-)
<ogra_> lool, i think landing 113 and 114 are the same thing
<lool> sil2100: are any indicators still in unapproved?
<lool> ogra_: one is upstart and one is lxc-android-config
<ogra_> lool, oh, no, thats -file-bridge, not -local-bridge
<lool> ogra_: but I guess you tested them together
<sil2100> lool: when I last checked, no
<sil2100> But let me double-check
<ogra_> lool, running here, all fine it seems
<sil2100> lool: all clear
<lool> ogra_: so lxc-android-config and upstart both OK?
<ogra_> yes
<lool> ogra_: shutdown and reboot working?
<ogra_> one sec, reboot is ...
 * ogra_ calls halt and waits 
<ogra_> grmbl
<lool> ogra_: to test shutdown, best to test the user experience of pressing the power button for 2 secs
<mzanetti> psivaa: heh... I used the dialer too for testing
<ogra_> halt causes a reboot
<lool> or something like that
<lool> gah
<lool> ogra_: try the user thing
<lool> psivaa: cool
<lool> psivaa: pushing
<lool> == Uploading qa stack ==
<lool> (python-upa)
<plars> lool: yes, it should be on soon
<ogra_> lool, 2sec powerbutton doesnt do anything
<ogra_> lool, oh, it does shut down now
<psivaa> mzanetti: yea i used dialer to get a quick feedback :).. continuing with the rest
<ogra_> lool, so i'm not sure that was a proper sutdown process, but it clearly shuts down the phone to hold the powerbutton for >3sec
<lool> sil2100: indicators >> cool
<lool> sil2100: and how is keyboard looking?
<sil2100> lool: released!
<sil2100> lool: the tests were failing before as well, and dogfooding revealed no problems
<sil2100> lool: actually, it's in release already
<lool> sil2100: cool
<lool> just waiting on a couple of publication to release pocket
<lool> both going in next publisher run
<lool> sil2100: hmm
<lool> sil2100: any idea about webbrowser-app changelog in cu2d/results?
<lool> sil2100: I've published r367, and there's a r368 upstream, and lots of changes from <= 367 still on the cu2d/results page
<sil2100> Let me check that
<sil2100> lool: could you paste me the link to the results page you have in mind?
<vila> lool: won't be able to attend the HO, got a late reminder that I have conflicting social duties :-}
<cjwatson> lool: we're finished Rick's apps list?!
<lool> cjwatson: well, that's how it looked like
<lool> cjwatson: but eh, still tons of bugs to fix!
<lool> cjwatson: I was as surprized as you when I reviewed it  ;-)
<ogra_> bugs ?
<lool> sil2100: http://people.canonical.com/~platform/cu2d/results
<ogra_> there are no bugs ... its all features
<sil2100> lool: strange, I think these are leftovers - how did you publish webbrowser-app?
<sil2100> lool: and when?
<lool> sil2100: I clicked force publication and listed only this package
<lool> sil2100: when: 15:58 < lool> == Published webbrowser-app ==
<lool> sil2100: I think it's a race
<lool> sil2100: I shoudl have rebuilt it before hand to pick up the new rev, retested it, then published
<lool> sil2100: but I published an "old" (from some hours earlier) rev, and then changelog merging failed
<lool> sil2100: So I guess we need to merge by hand?
<lool> sil2100: do you have commit access?
<lool> I'm not sure I do
<sil2100> I have, but I saw some release commit in trunk
<sil2100> Releasing 0.22+13.10.20131004.1-0ubuntu1 (revision 367 from lp:webbrowser-app).
<sil2100> It's in trunk, hm
<sil2100> lool: I guess that the right thing got released, but cu2d didn't yet pick up the proper changes - let's rebuild that component in that stack and check if it's ok now
<sil2100> lool: doing that
<lool> cyphermox: how is NM?
<lool> cyphermox: would like to kick a build
<cyphermox> lool: it's not in daily release yet, I just need to do an upload
<lool> sil2100: I had rebiult cu2d immediately after upload actualy
<cyphermox> but it would be ready to upload, I think
<lool> sil2100: in fact, that might be why!
<sil2100> lool: right, the merge wasn't in yet then!
<lool> sil2100: I rebuilt because I was showing up as green when some other packages should have it shown as yellow
<sil2100> lool: since it usually takes a few minutes for it to get approved + merged
<lool> I should have given it more time
<lool> right
<lool> didn't think of this
<lool> bad luck with picking up a rev too
<lool> sil2100: thanks for diagnosing this with me  :-)
<lool> cyphermox: if you dont mind, let's take it in 82
<cyphermox> lool: when is that?
<cyphermox> if you can tell me when to upload it would be easiest :)
<lool> cyphermox: 81 will build now
<lool> can be uploaded in 1h
<cyphermox> alright
<cyphermox> It'll be ready then, I'll just run it through sbuild one last time in between
<sergiusens> popey,  lool, I don't feel confident of starting the switch to click on Monday, can't we start today?
<lool> cyphermox: cool; also you want to test the binaries I guess
<lool> cyphermox: I can stage it in -proposed if it helps
<lool> cyphermox: just let me know
<sergiusens> popey, lool they are not being tracked daily, who knows all the issues we will find with autopilot and such
<cyphermox> lool: ack
<lool> sergiusens: ok, can you switch one or two in #82?
<sergiusens> or app armor
<lool> sergiusens: but please let's wait for test results for #81 in case something goes horribly wrong
<lool> ===== HANGOUT =====
<lool> sil2100: joining?
<lool> plars: ^
<lool> vila: ^
<lool> fginther: ^ if you like
<fginther> lool, omw
<vila> lool: <vila> lool: won't be able to attend the HO, got a late reminder that I have conflicting social duties :-}
<vila> lool: /me runs
<sergiusens> lool, ack
<popey> sergiusens: please
<lool> plars: https://launchpad.net/ubuntu/+source/unity8/7.82+13.10.20131004.1-0ubuntu1
<plars> lool: https://code.launchpad.net/~saviq/unity8/fix-mir-autopilot/+merge/189350 is the one we are going to need I think for unity8/mir, but it was just proposed a few min. ago so it won't be there yet
<plars> Saviq: right? ^
<Saviq> plars, that, too
<Saviq> plars, it lest you run tests individually
<plars> Saviq: thats *exactly* how we run them
<Saviq> plars, cool
<Saviq> plars, there's still the unblank & stale socket issue
<Saviq> plars, but since you're doing that
<Saviq> plars, then we should be good
<Saviq> plars, greyback is reviewing that branch now - it's already in landing asks along with the maguro fix in python-upa
<plars> Saviq: I was looking for the -fullscreen fix actually
<plars> Saviq: and saw this from you
<Saviq> plars, that -fullscreen one was just the first step
<Saviq> plars, there's more trickery involved unfortunately
<Saviq> plars, especially with the switching between mir and sf
<sil2100> lool, everyone: good job!
<lool> yeah!
 * lool did a *bad* job of sending the update email this morning
<lool> will do a single one for the day
<ogra_> lool, also to discourse and G+ ?
<lool> discourse?
<lool> gosh I'm not using that yet
<lool> will try G+
 * ogra_ neither
<ogra_> dider just links to it from G+
<lool> yeah
<sergiusens> popey, lets get 3/4 swapped, how about clock, rssreader, weather and filemanager
<sergiusens> ?
<sergiusens> balloons, plars  ^^
<balloons> sergiusens, what about them? :-)
<sergiusens> balloons, swapping to click
<sergiusens> in the image
<balloons> sergiusens, yes everything has click support now
<popey> sergiusens: ok clock, calc, weather, file manager pls?
<lool> crap, I'm seeing apps twice on my desktop
<lool> sorry on the dash of mako
<lool> is anyone seeing this?
<sergiusens> popey, ok, so replace rss with calc? sounds good
<lool> does someone else see the breakage on the home screen?
<sergiusens> lool, dup apps was logged by mhall
<lool> sergiusens: do you have a bug id?
<lool> bummer
<sergiusens> lool, hmm, let me re search for it
<lool> I hope I dont have to roll an #82 for this
<rsalveti> lool: when are we getting a new image? :-)
<lool> rsalveti: it's builtr
<lool> rsalveti: getting published to s-i
<rsalveti> just saw we got tons of changes today
<rsalveti> awesome
<lool> rsalveti: yeah, lots of bug fixes
<lool> rsalveti: trying to get a solid last SF image, with relatively safe changes
<rsalveti> the unity8 changelog is a bit scary
<rsalveti> right
<sergiusens> lool, https://bugs.launchpad.net/ubuntu/+source/unity-lens-applications/+bug/1229827
<ubot5> Ubuntu bug 1229827 in unity-lens-applications (Ubuntu) "Launching click installed apps from the dash runs multiple instances" [Undecided,Confirmed]
<lool> sergiusens: thanks
<sergiusens> lool, fwiw, I saw it with regular apps too
<lool> sergiusens: Yeah
<lool> sergiusens: this is not actually what I'm seeing
<lool> sergiusens: I'm seeing multiple icons
<sergiusens> lool, oh, sorry, I thought it was multiple runnings
<sergiusens> lool, that was an old bug that thing you see
<lool> so where are the other apps coming out?
<lool> these are actually new apps that got added
<lool> WTF
<sergiusens> lool, might be with the move of unity8 to upstart? Might need to figure out how it's generating the icons
<lool> sergiusens: there are TWO different calculator apps here
<ogra_> lool, LOL
<ogra_> HAHAHAHAHA !
<ogra_> lool, i fell into the same trap
<sergiusens> lool, for a minute I freaked out thinking it might of been me http://people.canonical.com/~ubuntu-archive/click_packages/click_list
<sergiusens> but the click list is ok
<ogra_> lool, re-flash ... thats all the fake autopilot apps
<ogra_> the ap tests pull them in ... it is super confusing
<sergiusens> ogra_, that's the potential bug I was telling plars about yesterday
<sergiusens> lool, ogra_ I was told that there was no apt-get update in any of the tests
<sergiusens> ogra_, oh, fake apps
<sergiusens> got it
<ogra_> sergiusens, yeah
<sergiusens> ogra_, unity does that?
<sergiusens> ogra_, it should clean up tbh
<lool> ogra_: oh ok
<ogra_> just the test apps the ap packages ship along
<sergiusens> ogra_, as in the test should clean up after it runs
<ogra_> sergiusens, if you uninstall the ap packages they go away
<ogra_> at least they did a few weeks ago
<ogra_> not sure thats stiull the case :)
<sergiusens> ogra_, hmm, the logic to install these desktop files should be in the test itself though
<ogra_> well, i didnt research where what comes from after all :)
<ogra_> i just re-flashed
<ogra_> you trashed your image already when you made it writable for testing
<ogra_> so i dont think in that case cleanup is needed ... if it also happens once we can fully do ro testing, thats something different
<sergiusens> ogra_, well QA is asking me to support testing with ro images; this needs to be cleaned up first if that's a goal
<ogra_> yeah
<ogra_> for ro it needs that
<lool> so I've freaked out 3 times on today's image being broken already
<lool> I'm reflashing now
<lool> keeping backup
 * ogra_ hands lool a 1l bottle valerian and a beer glas
<sergiusens> lool, if you keep backup you have the potential to freak out again!
<lool> true  :-)
<ogra_> lool, i used 80 on Mir and SF on both devices the whole day ... apart from the endless boot with Mir due to HUD issues it was all fine, dont let people make you panic
<lool> ogra_: speaking of #81!
<ogra_> oh, is it there already ?
<lool> yes!
<lool> popey: ^
<lool> my brain less so
<lool> plars: dashboard going ok?
<lool> :-)
<popey> kk
<plars> lool: was just checking, I would have expected it to roll out at the last hour mark
<plars> josepht: any idea? it looks like the qa-dashboard-production jobs ran ok, and the releaseprocess you pointed me at says it should resync and deploy every hour if there's anything new?
<josepht> plars: there's still one issue I'm tracking down
<plars> josepht: ah, ok
<plars> lool: the jobs are running though
<plars> I'm going to go grab some lunch while I wait for them to get farther
<fginther> lool, would it be possible to remove gallery-app from the daily ppa? it has a broken depenency
<lool> fginther: it will be repushed afterwards, but yes
<lool> fginther: nuke it if you like
<lool> fginther: what's he dep?
<fginther> lool, thanks
<lool> fginther: hold on, what's the issue?
<fginther> lool, one moment
<lool> fginther: the file conflict should be fixed in trunk now
<fginther> lool, the png file?
<fginther> lool, that's the one I'm hitting
<fginther> lool dpkg: error processing /var/cache/apt/archives/gallery-app_0.0.67+13.10.20131004.2-0ubuntu1_armhf.deb (--unpack):
<fginther>  trying to overwrite '/usr/share/icons/ubuntu-mobile/apps/144/gallery-app.png', which is also in package ubuntu-mobile-icons 13.04+13.10.20130925-0ubuntu1
<psivaa> lool: Saviq: filled the mir testing spread sheet with maguro results as much as possible.. did not report any new bugs for the failures..
<fginther> lool, if it's fixed in trunk, great. However, the package in the ppa is breaking the testrunner revert logic
<lool> fginther: that's supposed to be fixed in trunk and uploaded to PPA
<fginther> lool, ack, if the ppa is being fixed, I'll wait
<lool> fginther: I don't see any gallery-app in PPA right now though
<lool> ah sorry wrong one
<ogra_> :(
<fginther> lool, it's here https://launchpad.net/~ubuntu-unity/+archive/daily-build
<ogra_> the dashboard doesnt look so good
<lool> fginther: sorry MP didn't land on this
<lool> let's nuke it
<josepht> plars: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/
<lool> fginther: I can't though
<lool> fginther: can you?
<lool> I don't have power to kill it
<lool> fginther: can you land https://code.launchpad.net/~mfisch/gallery-app/remove-icon-from-package/+merge/189331 and we upload to PPA?
<josepht> lool: ^^
<ogra_> seems HUD service is killing us
<fginther> lool, I'm working it
<ogra_> (on 81)
<fginther> lool, I can't delete either :-(
<ogra_> oh, and sensorservice too
<lool> cjwatson: can you help
<lool> cjwatson: we're trying to nuke gallery-app from ppa:ubuntu-unity/daily-build (saucy)
<lool> cjwatson: to unbreak the autopilot runs for other packages
<Saviq> psivaa-afk, great, thanks
<lool> josepht: awesome!
<lool> josepht, plars: Great job, thanks!
<fginther> mfisch, I disabled the gallery-app tests for a moment until we get the ppa fixed
<fginther> cyphermox, robru, kenvandine, can any of you remove gallery-app from https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages ?
<fginther> it's blocking upstream merger until we get the fix to land
<lool> popey, ogra_: Can you play with #81 and decide if it's good?  :-)
<lool> will wait for test results
<lool> fginther: thanks
<ogra_> lool, dashbvoard doesnt look so good
<popey> lool: am right now.. will let you know
<ogra_> sigh ... my USB died on the chromebook
<lool> fginther: thanks; will care to land the fix ASAP
<lool> plars: who can give back the touch (non-mir) failures?
<lool> will go to dinner, then come back
<lool> plars: in terms of timezone, would be good if someone could keep an eye for a couple of hours on the test runs on touch
<popey> ooh, system settings are centred now?
<popey> http://popey.com/~alan/device-2013-10-04-184248.png
<ogra_> nice
<ogra_> sadly it will still fail in german i guess
<popey> So long as it works in French!
<popey> ooh!
<popey> new wifi dialog
<popey> http://popey.com/~alan/device-2013-10-04-184556.png
<kenvandine> fginther, just delete the package from the PPA?
<fginther> kenvandine, yes please, it has a dependency conflict
<fginther> kenvandine, I new one is one the way, but testing was being screwed up by the one in the ppa
<kenvandine> fginther, done
<fginther> kenvandine, much thanks
<kenvandine> np
<rsalveti> ogra_: seems unity8 and hud are both killing us
<ogra_> yeah
<ogra_> well, unity8 is probably just fallout of the HUD
<rsalveti> yeah
<rsalveti> can't we just kill hud?
<rsalveti> it's broken anyway haha
<rsalveti> and helps us getting a better boot speed
<rsalveti> I can only see good things happening after killing it
<rsalveti> :-)
<plars> lool: it looks like a lot of stuff is having problems today :(
<plars> looking
<ogra_> rsalveti, try and kill it for a test ... your reboots will just fly :)
<rsalveti> ogra_: yeah, amazing
<ogra_> and Mir makes it a lot worse
<plars> lool: unity8 cpu hogging is back
<ogra_> plars, i put my bets on it just being fallout of the hud service
<lool> plars: on Mir?
<ogra_> lool, on 81
<ogra_> see the dashboard
<lool> but on SF or in Mir?
<ogra_> but siot down before
<plars> lool: no, sf
<lool> Saviq: ^
<Saviq> plars, lool, we're on *some* of those
<lool> Saviq: so another SF build tonight with unity8 CPU hogging fix?
<lool> indeed, unity8 is at 50% CPU here
<Saviq> lool, no, not that *on* those
<lool> Actually it's all the time
<Saviq> lool, straight in image 81?
<lool> Saviq: it's broke in #81
<lool> ogra_: so many tests are failing on settle
<ogra_> lool, yeah, the hud, unity and sensorservice
<ogra_> the last one is mako specific
<rsalveti> might be connected though
<lool> Saviq: unity8.log is quiet
<rsalveti> my device is hot here
<rsalveti> haha
<lool> Saviq: strace is doing tons of futex()
<lool> [pid  2091] recv(57, "\2\0\0\0debug.egl.swapinterval\0\0\0\0\0\0"..., 128, 0) = 128
<sergiusens> fginther, hey, can you check this for me? http://91.189.93.70:8080/job/generic-mediumtests/684/?
<ogra_> rsalveti, well, hud and unity are hogging maguro as well ... but sensorservice is mako
<popey> lool: 81 looks good to me so far
 * popey is popping out for 10 mins
<rsalveti> lool: that's because it's rendering all the time
<lool> popey: we have an important CPU hogging issue with it
<popey> unity8 and sf eating some here
<popey>  2415 phablet   20   0  394m 151m  65m S  46.9  8.1  20:09.08 unity8
<popey>  2400 system    20   0  144m 119m 116m S  14.0  6.4   5:01.04 surfaceflinger
<lool> Saviq: I can offer to rollback to previous unity8
<plars> lool, Saviq: those indicator tests are still failing in unity also
<fginther> sergiusens, I don't see anything obviously wrong, I can check back after I get some other things fixed
<ogra_> bah
<ogra_> my phone hangs
<ogra_> UI completely stalled
<sergiusens> fginther, talking to the dev, he's looking; what's odd is that I didn't change anything at all that could be picked up by this
<ogra_> and unity8 at 100% CPU in adb
<fginther> sergiusens, right and I saw that other MPs passed recently, might be a dependency changed
<ogra_> hey, but at least rebooting works
<ogra_> oh man, this is really bad ...
<ogra_> scrolling in the G+ app starts when my finger already reached the edge of the display
<ogra_> (and there is no unity8 heavily hogging the CPU at this moment, i have top running alongside)
 * ogra_ switches to Mir 
<rsalveti> ogra_: yay, reboot is indeed working :-)
<ogra_> bah, not a bit better in Mir
<ogra_> i see unity constantly eating ~25% ...
<plars> maliit-server and hud-service still seem to always crash under mir
<ogra_> but that doesnt seem to spike or anything when the UI is unresponsive
<ogra_> oh, heh, probably because my adb session died
<ogra_> having the cursor blink in the middle of the top output is a good indicator i guess :P
<ogra_> input is super jumpy in Mir
<ogra_> (on maguro that is)
<ogra_> bah
<ogra_> and the Ui died again
<popey> mmmm toasty phone
<ogra_> yeah, here too
<ogra_> unity is at 107.2% CPU !
<ogra_> it is breeding a new core or so i guess ...
 * ogra_ notes that upstart seems to very busy as well 
<ogra_> the session init constantly eats about 10%
<fginther> bfiller, is anyone around who can review this? https://code.launchpad.net/~mfisch/gallery-app/remove-icon-from-package/+merge/189331
<bfiller> fginther: I can
<fginther> bfiller, thanks
<lool> plars: I think these were passing in manual testing though
<plars> lool: those crashes are happening in tests like install, and default - nothing that specifically targets them
<ogra_> lool, hud doesnt work at all on Mir for me
<lool> ogra_: could you file this against hud?
<lool> ogra_: they have been tracking a bunch of hud issues lately
<ogra_> it crashes on boot and tears dbus into a broken state for about 20sec
<ogra_> lool, yes, it is filed since two days
<bfiller> fginther: approved
<fginther> balloons, thanks again
<cjwatson> lool: still need help?
<cjwatson> lool: looks like you got it sorted.  I don't have any relevant superpowers FWIW
<ogra_> yeah, thats what clark kent claims too
 * cjwatson quickly puts his glasses on
<lool> cjwatson: It's still broken there, but we delisted it from the AP tests to run, so not a top issue anymore
<cjwatson> lool: gallery-app isn't shown in https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages any more, and Ken said above that he'd deleted it ...
<lool> ah great
<lool> had missed that
<lool> ogra_: did you confirm the size was large enough on maguro?
<ogra_> lool, we use loop images, the size is set yo 2G for the system one and we use 57% according to stephane
<ogra_> so 40M shouldnt do any harm
<lool> popey, ogra_: So I'm obviously not thinking of promoting #81, you guys will be in bed by the time we get a #82; if you want to give it a run over the week-end and say that it's good, that's helpful, but eh it's week-end and I guess you need to recharge
<lool> ogra_: ok
<ogra_> lool, i can test tomorrow no issue with that
<ogra_> i dont want to keep 81 :)
<ogra_> (and i wont go backwards)
<popey> lool: how late is late?
<popey> lool: happy to hang around to test 82
<lool> I am testing the reverted .debs, then need to uploaded reverted sources
<lool> so guesstimate is image in 2 hours
<lool> win 77
<kenvandine> 77... wow :)
<lool> 110 channels actually  ;-)
<lool> but fortunately that's less than before
<lool> of course I read every line on all of them
<seb128> lol, if anyone wonders why lool doesn't get anything done.. ;-)
 * seb128 hides
<seb128> (sorry, it's friday right?)
<kenvandine> ah, friday trolling, i don't think we've had much of that this cycle
<lool> cjwatson: if you're around and you dont mind, would you bump prio of https://launchpad.net/ubuntu/+source/unity-notifications/0.1.1+13.10.20131004.2-0ubuntu1/+build/5076308 and https://launchpad.net/ubuntu/+source/unity8/7.82+13.10.20131004.2-0ubuntu1/+build/5076299 ?
<lool> both start in 20+mn
<lool> seb128: you're right, I'll remember that and be more careful next time you need to land something!  hint hint
<lool> seb128: maybe you need a special process
<lool> :-P
<seb128> lool, oh, you missed you shot, settings are perfect, I don't need any landing anymore, so that's ok
<seb128> (if only that was true...)
<ogra_> *crunch* *crunch* *crunch*
<ogra_> (that's my popcorn ^)
 * lool goes testing settings and reporting RC bugs
<seb128> doh
 * seb128 sends chocolates to lool
 * lool has an allergy to traces of nuts and chokes
<seb128> can't win :-(
<seb128> lool, btw you should be enjoying your w.e!
<lool> cjwatson: and https://launchpad.net/ubuntu/+source/indicator-network/0.5.1+13.10.20131004.1-0ubuntu1/+build/5076327
 * seb128 is calling a day/week
<lool> ok; I'll be back in a few, when the builds are done
<seb128> have a good w.e everyone!
<lool> transition to release pocket etc.
<lool> seb128: have a good week-end
<seb128> thanks, you too!
 * retoaded announces: 15 minutes until the jenkins instance on psoglav (aka s-jenkins) is put into "Prepare th shutdown" mode.
<lool> oh right
<lool> that's tonight
<lool> of course!
<retoaded> s/th/to
<lool> but it's all good
<lool> retoaded: is it the one driving image testing?
<retoaded> lool, some of it. Some are driven by magners-orchestra. s-jenkins is more merge proposal
<lool> apparently image testing isn't listed there
<lool> we will see I guess  :-)
<retoaded> lool, if everything goes well, it won't be down very long but it will be coming back up on a different IP.
<retoaded> when it comes back up it will be http://10.97.2.26:8080
<fginther> can someone confirm that lp does not publish all binary packages from a source package simultaneously inside a ppa?
<sergiusens> cjwatson, from what retoaded is saying, you might want to update the cron to pull from the new instance
<sergiusens> fginther, confirming
<sergiusens> fginther, that's why we had all those checks in the ppa_copy script
<fginther> sergiusens, know of any good way to workaround this with apt-get?
<fginther> sergiusens, :-)
<lool> retoaded: ok thanks
<sergiusens> fginther, hmmm, but at the apt-get level you should be fine, I thought the bin was copied first and the Packages.gz updated
<sergiusens> fginther, are you checking for one arch and then pulling for another?
<sergiusens> fginther, oh, mirror issues is what you may see
<fginther> sergiusens, so apt is pulling in an "all" package when then depends on an armhf package, the 'all' package appears to be available before the 'armhf'
<fginther> sergiusens, both the all and armhf packages have the same source package
<sergiusens> fginther, so the all depends on the bin and the bin isn't there yet? And all this in apt?
<fginther> yes
<sergiusens> fginther, btw https://code.launchpad.net/~sergiusens/ubuntu-weather-app/click-in/+merge/189381 is failing too
<sergiusens> and I can't reapprove
<fginther> sergiusens, I can
<sergiusens> fginther, ty
<sergiusens> fginther, so wrt to your problem, I'm thinking you want stgraber
<fginther> sergiusens, is there a technical limitation to flashing two devices simultaneously (assuming you had a local copy already downloaded)?
<sergiusens> fginther, I can't think of solving it just at the apt level
<fginther> sergiusens, thanks for the help
<sergiusens> fginther, no, there shouldn't they are on different serial interfaces
<sergiusens> fginther, and locks are in place for the downloads so they don't step on each other
<fginther> sergiusens, so this can be done now?
<fginther> sergiusens, in our flash job, we have a file lock in place to serialize phablet-flash
<sergiusens> fginther, do you have to devices to test this just in case? The last code injected for this did work and I'm almost sure doanac or plars are flashing in parallel
<sergiusens> they came up with the feature in phablet-flash
<lool> sergiusens: BTW, did you manage to prepare a .display-mir branch?  I think Saviq will be around tomorrow to land Mir fixes and then we can enable it
<lool> sergiusens: I'm also thinking we want to keep a copy of the last good SF images somewhere; would you know of a place to do so?
<lool> sergiusens: otherwise I can check with stgraber
<fginther> sergiusens, I don't have two devices, I'll wait for doanac and plars to chime in. When I asked earlier, I understand they don't do it in parallel
<sergiusens> lool, wrt ricmm said it wasn't ready yet
<doanac> fginther: i was confused earlier about what you were asking. I think we allow phablet-flash to be called concurrently.
<doanac> so we run different jobs concurrently (we just don't parrellize a single job)
<fginther> doanac, ahh, that's good to know. I want to flash 8 devices at once, sounds like that safe to do
<fginther> or some combination of overlapping flashings
<lool> sergiusens: where was that?
<sergiusens> lool, our dailies
<lool> sergiusens: I can't connect your points to mine
<lool> it's like we're discussing something else
<plars> fginther: yeah, you should be safe now - at one time it was not safe to overlap them but it is now
<doanac> fginther: not sure if we've done that many before. I know plars used to have to do "flocks" around fastboot commands back at linaro for android devices
<lool> sergiusens: currently I'm holding up mir as default until we get a couple of fixes, input related
<lool> or focus related
<lool> focus as in notification focus
<lool> not bringing apps to the front
<sergiusens> lool, let me circle back and get that MR ready
<lool> sergiusens: but AIUI, Saviq will be fixing these two tomorrow
<lool> and then I'll switch
<lool> sergiusens: thanks for preparing this BTW
<lool> sergiusens: do you have a place for backups of the images?
<cjwatson> lool: sorry, by the time I got to this they were all basically about to build
<cjwatson> sergiusens: sorry, which cron job is that?
<sergiusens> cjwatson, did click-copy one
<lool> cjwatson: np; thanks for checking
<cjwatson> sergiusens: right, that's pulling automatically from your branch anyway ...
<sergiusens> cjwatson, but the IPs are set as arguments
<cjwatson> sergiusens: oh, right
<cjwatson> 11 0,6,12,18 * * *      bzr up -q ~/click_ready && ~/click_ready/click_copy.py https://jenkins.qa.ubuntu.com ~/public_html/click_packages
<cjwatson> tell me what that should be
<cjwatson> fginther: is that all/armhf thing in a PPA?
<sergiusens> cjwatson, starting later tonight according to retoaded it should be http://10.97.2.26:8080
<cjwatson> sergiusens: could you ask IS for a firewall hole from snakefruit to that?
<cjwatson> sergiusens: that might take a while though - would it be horrible for the cron job just not to work for a while?
<popey> lool: how far back in terms of backups?
<sergiusens> retoaded, any chance of keeping the IP?
<cjwatson> lool: well, I bumped two of those a bit, the other is building
<sergiusens> cjwatson, you bring up a good point, lots of things will break, not just our stuff
<lool> cjwatson: thanks
<retoaded> sergiusens, that would be complicated as the new server for s-jenkins is also configured for and already running as the secondary BIND server.
<sergiusens> retoaded, ok, did you replicate all the firewall rules?
<retoaded> I will set up a page on psoglav to redirect people to the new server once it is up and running.
<sergiusens> retoaded, since cjwatson asked me to do that; but it's not the only stuff that will break
<retoaded> The firewall rules are (supposedly) all set up for the SNAT address coming out of m-o.
<sergiusens> retoaded, oem talks to the plum server (forgot the full name)
<cjwatson> retoaded: snakefruit can't talk to 10.97.2.26:8080
<cjwatson> fginther: oh, yeah, you said it was a PPA.  This happens because architecture: all binaries are always built by an i386 builder.  The only way to avoid arch skew is to build in a staging PPA and copy over when it's done (much like saucy-proposed vs. saucy)
<retoaded> cjwatson, that would be an incoming rule then. hmmmm.
<sergiusens> cjwatson, btw, is snakefruit a precise machine and does it have python-oauth installed?
<retoaded> cjwatson, but there isn't anything running to asnwer on http://10.97.2.26:8080 yet.
<retoaded> s/asnwer/answer
<cjwatson> sergiusens: yes and yes
<sergiusens> retoaded, can you setup  a netcat or something for cjwatson to test?
<sergiusens> cjwatson, that's great, make oauth implementation easier :-)
<retoaded> sergiusens, give the nc string you want me to set up
<retoaded> sergiusens, will something like nc -l 10.97.2.26 8080 work for you needs?
<sergiusens> retoaded, more of a cjwatson thing to test, I don't have access to snakefruit as far as I know
<retoaded> cjwatson, will nc -l 10.97.2.26 8080 suit your needs?
<cjwatson> retoaded: sounds right
<retoaded> cjwatson, it's running
<cjwatson> retoaded: you seeing anything on its output?
<retoaded> cjwatson, not yet
<cjwatson> telnet: Unable to connect to remote host: Connection timed out
<cjwatson> so that's a no
<retoaded> hmmmm
<cjwatson> lool: those are all built, some probably still awaiting publication
<sergiusens> fginther, I'm still confused about this failure... http://91.189.93.70:8080/job/generic-mediumtests/687/console
<plars> balloons: weather-app tests are all failing on both devices
<balloons> plars, yes the changes have wreaked havoc on weather
<plars> balloons: so it wasn't from the new weather-app version?
<sergiusens> plars, balloons interesting, my MR is also failing...
<sergiusens> fginther, nvm, I think it will be solved for us
<sergiusens> plars, is calculator also breaking?
<plars> sergiusens: yes http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/81:20131004:20131003.2/4556/ubuntu-calculator-app-autopilot/
<plars> sergiusens: 9 failures on both phones
<plars> (7 of which are ap tests)
<sergiusens> plars, ok, that's sort of good news for me
<sergiusens> plars, but that just means something outside of the tests has changed
<sergiusens> plars, since my MRs are basically like adding READMEs and they fail
<sergiusens> plars, was checking previous MRs and they seem solid
<balloons> sergiusens, which MR? and no, it's not interesting trust me, heh
 * balloons notes that looks like swiss cheese: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/81:20131004:20131003.2/4556/
 * lool whistles
<lool> balloons: system-settle raised the unity8 CPU bug
<plars> balloons: note that a lot of the failures across the tests are system-settle
<plars> right
<plars> but there's plenty of random breakage all over the place too
<balloons> yes, so there is going to be breakage as francis migrates us to merging with the upstream sdk versions
<plars> lool: I'm retrying where it makes sense to do so, but I think some of it just needs to be resolved and/or backed out to make sense of it. it's quite a mess right now
<sergiusens> balloons, https://code.launchpad.net/~sergiusens/ubuntu-calculator-app/clicker/+merge/189392  https://code.launchpad.net/~sergiusens/ubuntu-weather-app/click-in/+merge/189381
<plars> lool: lots of stuff on mir is taking forever and timing out
<balloons> sergiusens, welcome to core apps merging my friend :-)
<plars> lool: the click_image tests just timed out there
<plars> lool: after 30 min. it timed out, for comparison, I would have expected it to take more like 1 min
<sergiusens> balloons, if it were previous time like MWC and had more control I would of used the expedite system that everyone loved
<sergiusens> too much of a gestapo (or nsa) now to do that :-P
<lool> plars: I'll upload another image in a few
 * balloons loses it @ sergiusens 
<balloons> too funny!
<lool> plars: this sounds quite in line with unity8 pegging the CPU
<sergiusens> :-)
<lool> MWC?
<balloons> lool, mobile world congress
<sergiusens> lool, that^
<sergiusens> lool, https://code.launchpad.net/~sergiusens/livecd-rootfs/mir_default/+merge/189429
<lool> I wonder who the gestapo is then
<lool> sergiusens: thanks
<balloons> fginther, are you testing the upstream version of UITK emulator too?
<balloons> fginther, I mean with the apps, are they running the latest version of the emulator? I'm seeing emulator bugs in these runs
<fginther> balloons, only the generic-mediumtests-sdk used the uitk emulator, the main generic-mediumtests job has that bug I mentioned
<balloons> fginther, sorry, I blame the lateness of the hour on friday, but I'm missing what you are saying :-)
<balloons> fginther, ohh wait, got it.. ok, so that's a yes :-)
<fginther> balloons, there are too many things in flight to give a strait yes/no to any question :-)
<balloons> fginther, hahahahah..
<lool> == building an image ==
<lool> ogra_, popey: ETA 45 mn or so, but since the results will take a while, I likely wont promote before tomorrow
<popey> lool: just started watching a film, so will wait and test tonight
<lool> ok thanks
<balloons> offical build number is?
<lool> I couldn't test all pending binaries due to recurring fs issues   :-(
<lool> balloons: latest image is #81, current build is #82, last stable is #78
<balloons> current build is what I was after.. I didn't know if it was 81 or 82 :-)
<dobey> sergiusens: uhm. i just happened upon bug #1111598 which was marked "Fix committed" a month ago, but does not seem to actually be fixed. the keyboard stays around still
<ubot5> bug 1111598 in Ubuntu UX "[osk] Keyboard is too persistent" [Critical,Fix committed] https://launchpad.net/bugs/1111598
<plars> lool: just to make you aware, I'm having trouble with the mako in the lab running the mir tests - it isn't responding, but is visible on adb
<lool> plars: can you reflash it?
<lool> image is being imported right now
<lool> retoaded: is jenkins conversion done?
<lool> retoaded: image import needs the custom tarballs from there apparently
<retoaded> lool, the sync is still ongoing, should be done shortly.
<lool> ok
<lool> stÃ©phane tells me there's a timeout anyway
<lool> ogra_, popey: Image up; took a while due to langpacks
<popey> kk
<plars> lool: I can't do anything with it from here
<lool> plars: adb reboot + fastboot boot <recovery.img>?
<lool> plars: do we have spares?
<plars> lool: no, reboot doesn't ever come back
<plars> lool: checking on spares
<lool> the good news is that CPU pegging is gone
<lool> online music, wow
<plars> \o/
<lool> and it works!
<lool> wow the goto accounts link from click actually works
<lool> video playback in browser is audio only, green overlay
<lool> but tha'ts better than it ws
<lool> cool
<plars> lool: ok, I can work around it
<plars> one sec
<popey> lool: ogra_ 82 seems good here
<popey> on mako
<sergiusens> retoaded, are you going to deal with the firewall rule as well?
<sergiusens> dobey, osk not dismissing is a bug that comes and goes
<sergiusens> dobey, however I don't recall marking that bug fix committed in september
<sergiusens> dobey, oh, I was just marking the project fix committed for it to be consistent with the ubuntu package
<lool> popey: cool
<lool> popey: will wait for ogra's feedback and test results, likely tomorrow
<lool> and then perhaps promote
<popey> ok, groovy
<Saviq> plars, the indicators tests are gone in trunk already
<cjwatson> lool: Can I upload http://paste.ubuntu.com/6194378/ ?  In touch images but this change doesn't really affect them.
<retoaded> sergiusens, I have an RT in with IS on the FW rule. I tried to get vanguard to work it but apparently they EOD'd/EOW'd without even responding to me.
<cjwatson> From my POV they EODed just before you asked
<cjwatson> 21:34 -!- fo0bar changed the topic of #is to: Vanguard: None at present; please use RT or emergency line || Known Issues: Ã¸ || Emergency number: +44 207 630 2499 || RT: rt@admin.canonical.com ||  http://status.admin.canonical.com/
<cjwatson> 21:35 <retoaded> fo0bar, there is currently a fw rule that allows snakefruit to connect to a machine in the magners lab; specifically 10.97.2.10:8080, can a rule be added to also allow it to connect to 10.97.2.26:8080?
<retoaded> cjwatson, it may have been a network issue on the server. see if you can hit http://10.97.0.26:8080 from snakefruit.
<retoaded> btw, the new jenkins is up and running and can be connected to through that URL
<cjwatson> retoaded: Afraid not
<cjwatson> FYI I've arranged for proposed-migration to know about the specific set of things that ubuntu-touch currently depends on from the coreapps PPA
<cjwatson> I'll try to track that as they diminish by way of conversion to click packages
<cjwatson> But this should mean that proposed-migration will prevent the addition of any more out-of-archive dependencies without us explicitly educating it about them, which should be an improvement
<retoaded> cjwatson, ack
<rsalveti> lool: green overlay when playing videos will be fixed once jim fixes the software rendering path in gst, which is the same issue that's causing an invalid thumbnail
#ubuntu-ci-eng 2013-10-05
<plars> things are looking quite a bit better on the automated tests with this one - mir is still pretty rough of course
<Saviq> lool, https://code.launchpad.net/~saviq/unity8/revert-r376/+merge/189455
<lool> cjwatson: gnutls26 >> sure; thanks for the heads up
<lool> Saviq: looking
<lool> rsalveti: ok thanks
<Saviq> lool, I've a package coming up
<Saviq> lool, like in 2 mins
<cjwatson> lool: uploaded, thanks
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt is actually looking almost acceptable now, with the ignorable exception of arm64
<lool> Saviq: cool
<lool> Saviq: should we sync a bit for plan over the week-end?
<lool> I do have some other planned outside activities too  :-)
<lool> Saviq: so right now, we have the reverts in archive, I built an image with them; it's not the highest pass rate ever, but nothing to be too ashamed off and it generally works; most AP fails are in apps, a brightness thing in unity8 AP tests
<lool> generally speaking, I would be happy to promote is and call SF done
<lool> ogra_: ^ your toughts
<lool> *thought
<ogra_> lool, i'm just flashing
<ogra_> (morning etc)
<lool> ogra_: Morgen ! :-)
<Saviq> lool, ogra_ the biggest difference from my PoV is WiFi password input, which is in the indicator in the rolled back unity8, unity-notifications, indicator-network
<lool> Saviq: Now Mirv actually did the testing of the CPU pegging unity8 and was happy with it, so what I'd like is either getting us all these revs into the image with the fix you've identfied
<ogra_> the failures look like many of them are toolbar related
<lool> Saviq: Yes, I rolled back the 3
<Saviq> lool, yeah, I'd rather do that
<ogra_> (from the apps)
<Saviq> lool, http://people.canonical.com/~msawicz/unity8/ here is unity8 trunk + the fix/revert
<lool> Saviq: so we do that on top of what was tested yesterday?  I think you have landed other things in unity8 trunk already
<Saviq> lool, we only have a revert and a test-drop in trunk over what's released currently
<Saviq> lool, so with the "new revert" we'd have two reverts and the test drop, so rather safe
<Saviq> lool, and that's what you have in the packages I put up
<ogra_> bug 1235480
<ubot5> bug 1235480 in upstart "upstart-local-bridge clobbers $PATH with its events" [Undecided,Fix committed] https://launchpad.net/bugs/1235480
<lool> Saviq: looking
<lool> Saviq: right, trunk looks good
<lool> Saviq: I'll take the previous unity-notifications debs to test your unity8 build
<Saviq> lool, so if you confirm the fix/revert helps with CPU - let's merge, release
<Saviq> lool, yeah, it needs the "new" unity-notifications and indicator-client
<Saviq> s/-client/-network/
<Saviq> lool, so full dist-upgrade + my packages should work good
<lool> Saviq: well I just took image 82 + your pcakages + old unity-notifications (qtdeclarative5-unity-notifications-plugin)
<lool> just trying to unmount now
<Saviq> lool, old unity-notifications and indicator-network will conflict with my packages - you need all three upgraded to their latest releases from trunks
<Mirv> lool: yeah I didn't notice the CPU hoggage, it didn't seem bad performance wise as such
<Mirv> maybe the autopilot tests themselves should notice it
<Mirv> "idle, check cpu usage"
<Saviq> lool, that is to say "sure, it'll work, but expect issues with WiFi password entry"
<lool> Saviq: "old" means the one before my revert
<Saviq> lool, ok then - yes :)
<lool> Saviq: yesterday I reverted indicator-network, unity8, and unity-notifications in archive
<lool> so I might get FS corruption, hopefully not
<Saviq> lool, yeah, saw that now
<lool> Saviq: so I have 7.82+13.10.20131004.1-0ubuntu2~sbuild3 installed, and top if quiet  \o/
<lool> *is quiet
<lool> screen of or screen on
<lool> Saviq: so that looks good
<lool> Saviq: let's upload all of this
<Saviq> lool, yay
<Saviq> lool, FYI some kind of SDK weirdness happened there - still need to investigate
<Saviq> lool, the spinner 'caused the CPU usage even when it was, in theory, off and invisible
<Saviq> -'
<lool> Saviq: you mean in the code that you reverted, it should not be using CPU but is due to some SDK bug?
<lool> Saviq: to clarify: are we good with just the revert we tested, or do we need another change for that spinner thing?
<Saviq> lool, yes
<Saviq> lool, we're good
<Saviq> lool, I reverted the change that was broken - and was due to a SDK bug
<Saviq> lool, with my MP unity8 is no-CPU-hogging anymore
<Saviq> lool, but we still need to merge / release it
<lool> Saviq: I've happroved the mp
<Saviq> lool, thanks
<lool> Saviq: I'm preparing the other uploads
<lool> Saviq: will send MPs to resync bzr trunks with changelogs of uploaded reverts
<Saviq> lool, yup, let me know if you need me to approve
<lool> (since nothing sits in trunk, can't ask cu2d to resync somehow)
 * Saviq hates nautilus + gvfs recently
<Saviq> it was working so well last release, but with the new nautilus all kind of flakiness happens
<lool> that reminds me, I've noticed now that mtp coming up kills my adb shell connection for a sec
<lool> then it comes back
<lool> like the connection gets closed, I have to reopen it
<lool> uploaded indicator-network
<lool> it will be blocked in unapproved, then in proposed
<lool> Saviq: https://code.launchpad.net/~lool/indicator-network/resync-indicator-network-changelog/+merge/189458
<Saviq> lool, +1
<Saviq> lool, actually +2 - mtp is flaky for me, too - but that's with android as well
<ogra_> setting a property resets the gadget
<ogra_> when mtp comes up it adds a property to the gadget settings
<lool> Saviq: https://code.launchpad.net/~lool/unity-notifications/resync-indicator-network-changelog/+merge/189459
<lool> ogra_: aha
<lool> ogra_: so it's "by design"
<ogra_> yeah
<Saviq> lool, +1
<lool> Saviq: sadly, indicator-network needs someone from release team to ack
<ogra_> and setting the property persistent would make your gvfs on the desktop freak out
<ogra_> since there is an mtp device but no server attached
<lool> Saviq: and we're saturday, so might take some time
<Saviq> lool, but we can merge the changelog regardless, right?
<lool> I think so
<ogra_> (so gvfs goes into a loop of mount attempts spilling errors)
<lool> Saviq: I've put a block hint in place so that we can upload all 3 and let them in -proposed
<lool> so that we don't get half in unapproved half in archive
<Saviq> lool, oh cool
<Saviq> lool, and then just flip the switch to let through to saucy, got it
<Saviq> lool, thanks!
<lool> Saviq: right, so I can upload unity8 when it's there
<Saviq> lool, granted, the deps should prevent going into an inconsistent state
<Saviq> lool, actually there's one question you might be able to answer
<lool> Saviq: the provides are there, but I didn't update deps for indicator-network
<Saviq> lool, ah right
<Saviq> lool, we had a situation last week when unity-notifcations Provides was already unity-notifications-impl-2 (in the upstream merger's local repo)
<Saviq> lool, but unity8 Depends was still at unity-notifications-impl-1, which was available in saucy
<Saviq> lool, and apt crapped out when trying to install that unity8 version
<lool> which was the goal?
<Saviq> lool, is it not smart enough to install a non-highest version to fulfil the deps?
<lool> ah no
<lool> it will select the highest version
<lool> it's basically a complex scoring mechanism
<lool> which I don't know all the details of
<lool> but a higher version will get lots of point
<Saviq> lool, mhm
<lool> a downgrade wont happen unless your force it
<Saviq> lool, yeah, but it wasn't about a downgrade
<Saviq> lool, it was about installing (new package) a non-highest version
<Saviq> which I was hoping would work
<lool> that I would expect to work
<lool> but then maybe not  :-)
<lool> Saviq: but if you remember the specifics, I guess some APT maintainers could possibly look into it
<Saviq> lool, fortunately we even have a log - 'cause it was on mediumtests
<lool> Saviq: Ok, so we're waiting on a bunch of things right now
<Saviq> lool, yup, all things to merge
<lool> to sum up: a) upstream merger picks up your MP, merges it b) I press the cu2d buttons and get that uploaded c) release team reviews + approves new indicator-network d) we unblock all 3 e) we build animage
<lool> ogra_: what did you think of latest image?
<lool> ogra_: should I promote it?
<lool> ogra_: we might get another SF one EOD
<ogra_> lool, well, just had to reboot trying to send an SMS
<lool> ogra_: but I'd rather we promote this one if you feel it's good enough
<lool> ogra_: what happened?
<ogra_> it hung
<lool> unity8?
<ogra_> not sure
<lool> any crash files?
<ogra_> i made a call, afterwards saved the contact ... (which used some http formatting for the plus sign in +49 ... which in turn couldnt send to that number full of special chars ...)
<lool> Saviq: I dont think we can fix the current SF images much more over the week-end; the original plan was to fix a couple of critical issues and switch to Mir; the critical issues were input in the webbrowser (might be related to volume up / down or not), and input focus on snap decisions
<ogra_> then i edited the contact to have a proper +49 ... got an error that contact saving failed and after that no input was possible anymore
<lool> Saviq: I can't fix the input issues myself, but if they get fixed I can land the "switch the default to Mir" over the WE
<lool> ogra_: fun
<Saviq> lool, nah, let's get back to it on Monday
<lool> ogra_: but is it a _regression_?  :-)
<Saviq> lool, there's no one working on those
<Saviq> lool, let's all have our WE now
<Saviq> or after we fix SF
<lool> ogra_: is this something you experienced successfully in the past?
<lool> ogra_: basically, would this image be more or less substantially better than the previous stable one?
<ogra_> lool, the mangled number definitely is ...
<ogra_> lool, but i'm not sure thats a blocker
<lool> I fear we're running out of runway
<ogra_> right, lets promote it
<ogra_> after reboot there dont seem any issues
 * lool reads ~ogra/README.mark-current
<ogra_> should i ?
<lool> ogra_: so mark-current is for the cdimage part
<ogra_> (if you feel safer with that)
<lool> ogra_: and the second is for system-image?
<ogra_> right, that needs to happen first
<ogra_> yep
<lool> ogra_: Actually, I like to do it because you're around  :-)
<lool> ogra_: build is is 82?
<ogra_> just call both commands in succession with the right numbers
<ogra_> 82 for system image
<lool> ah and for cdimage I need to use the ubuntu version?
<lool> so 20131004.1?
<ogra_> 20131004.1
<ogra_> right
<lool> the second one churns
<lool> I guess deltas
<lool> done
<ogra_> yeah, the second one takes a bit
<lool> ogra_, popey: 82 promoted!
<ogra_> the first one just sets a link
<ogra_> yay
<lool> ogra_, popey: Bulding an 83 tonight with updated 83 and SF, but otherwise leaving it there
<ogra_> popey, thats 82/20131004.1
<popey> sweet!
<lool> might want to promote 83
 * popey mails
<lool> if you guys feel like it
<popey> ok, I'll be around
 * ogra_ cant promise but will help if he is around
<lool> it's mostly what was in 81, with no CPU hogging, so 82 + new unity8
<lool> and indicator-network
<lool> ogra_: yeah if you can't then so be it
<ogra_> dont you need a FFe for that one ?
<lool> we can always promote it monday
<ogra_> indicator-network is a desktop package
<lool> ogra_: it says ubuntu-desktop, but I don't actually see it pulled by ubuntu-desktop
<lool> an dseeded-in-ubuntu also doesn't
<ogra_> intresting
<lool> ogra_: well, I don't understand why it's still in the desktop packageset
<ogra_> i always thought we have it installed
<ogra_> missing meta update ?
<ogra_> or a dep ...
<lool> Saviq: So I'll step away for a bit, possibly only back after lunch + some family activities outside, near 5pm UTC+2
<Saviq> lool, yeah, enjoy
<lool> Saviq: if upstream merger doesn't run or fails, would you merge by hand?
<Saviq> lool, will do
<lool> I might have commit access, not sure
<lool> Saviq: thanks for the fix, will be back in a bit
<Saviq> lool, I'll force-hand generic-land
<Saviq> lool, he has access for sure :)
<popey> ogra_: i dont see changes at http://people.canonical.com/~j-lallement/touch/changes/
<cjwatson> Saviq: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2012-01-29-apt-resolver-bugs.html has some random wittering about how to investigate apt resolver bugs, if it happens to be useful
<Saviq> cjwatson, thanks - I'm not really sure it's a bug, and rather a feature ;)
<Saviq> cjwatson, but will be a useful read anyway
<cjwatson> well, how to investigate the algorithm anyway.  it's a useful though tricky thing to understand
<lool> popey: http://people.canonical.com/~ogra/touch-image-stats/20131004.1.changes has some
<popey> yeah, i have that
<popey> i usually link to the pretty version jibel has
<popey> nvm
<lool> ah
<popey> will link and say it's pending
<popey> given we can guess the url â»
<lool> I guess it's running from jibel's desk!  :-)
<lool> popey: ah you probably want the diff between stbale images
<lool> I forgot where ogra has it
<popey> lool: no, I deal with that
<popey> lool: I manually merge the individual diffs
<lool> ok
<popey> mail sent
<lool> popey: thanks!
<Saviq_> ugh
<Saviq_> ok, so upstream merger is broken - the old IP was hardcoded in the jobs ;(
<lool> gosh, where is it hardcoded?
<popey> I love it when we move stuff to a new IP. Great way to shake out these kinds of issues. #glasshalffull
<Saviq_> popey, yeah, and finally *name it* somehow
<popey> â»
<Saviq_> popey, and whoa! here's an idea - let's provide a DNS server behind the QA VPN!
<popey> Steady on there! â»
<Saviq_> that would be like The Enterprise
 * popey emails /etc/hosts files around to everyone
<popey> ghetto dns
<Saviq_> rotfl
<Saviq_> bugs against ps-qa-tools?
<popey> pass
<lool> actually some other jenkins dep had the great idea to use the public facing jenkins.qa.ubuntu.com to get a stable name  :-)
<lool> I don't remember which cron it was that got pasted here, but because it used jenkins.qa.ubuntu.com instead of 10.x.x.x it was immune to the change  :-)
<lool> Saviq: where's this hardcoded IP you say?
<Saviq_> https://bugs.launchpad.net/ps-qa-tools/+bug/1235621
<ubot5> Error: ubuntu bug 1235621 not found
<Saviq_> lool, so, first of all the links to jobs from history don't work (that, hopefully, is a configuration issue - otherwise only new jobs will have correct jobs cross-links)
<Saviq_> lool, but http://10.97.0.26:8080/job/generic-mediumtests-saucy/4632/console
<Saviq_> downloads artifacts directly from the old IP
<lool> indeed
<jibel> popey, my DSL died after a storm and have limited connectivity. I'll relocate the job that publish changes during the week end
<popey> jibel: ouch!
<popey> jibel: thanks.
<lool> Saviq: I've just checked and don't have permission to fix it
<Saviq> lool, yeah, me neither
<lool> mailing Francis + Larry
<Saviq> fginther, https://bugs.launchpad.net/ps-qa-tools/+bug/1235621 https://bugs.launchpad.net/ps-qa-tools/+bug/1235622
<ubot5> Error: ubuntu bug 1235621 not found
<ubot5> Error: ubuntu bug 1235622 not found
<lool> Saviq: ming merging unity8 by hand?
<lool> Saviq: (I've mailed them now, listing bugs and Cc:ing you)
<Saviq> lool, already there
<Saviq> lool, everything's is merged by now
<lool> let's see if cu2d is still working
<Saviq> lool, it's not been moved (yet), so hopefully yeah
<Saviq> lool, but it'd make sense to solve the above bugs for them *before* they move, yes
<lool> A version (7.82+13.10.20131004.2-0ubuntu1) is available at the destination for that component but is not in trunk which is still at 7.82+13.10.20131004.1-0ubuntu1. Ignoring that component for source: unity8, branch: lp:unity8, series: saucy.
<lool> guess we need to merge the changelog there too
<lool> Saviq: https://code.launchpad.net/~lool/unity8/add-reverts-in-unity8-changelog/+merge/189463
<lool> Saviq: could you hand merge this one if you're ok with it, and then I'll run cu2d again?
<lool> off for lunch
<Saviq> lool, going
<Saviq> lool, it's going to be merged in 30s
<Saviq> lool, if you can kick off cu2d again
<Saviq> lool, ready
<lool> ok
<lool> running
 * ogra_ notes that the session upstart goes wild after some time on 82
 * ogra_ sees a load of 17.08
<ogra_> (using Mir btw)
<fginther> Saviq, the IP has been updated
<Saviq> ogra_, oh, I wonder if it'd be bug #1235190
<ubot5> bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [Critical,Confirmed] https://launchpad.net/bugs/1235190
<ogra_> Saviq, qwll, i suspect it is also  some issue with upstart
<ogra_> i see init consuming a lot of CPU
<Saviq> ogra_, although CPU was idle for us mostly - same for IO and RAM - everything looked fine resource-wise, only display slowed down to a crawl
<Saviq> ogra_, so yeah - not the same - our issue was with idle CPU
<ogra_> root@ubuntu-phablet:/# ls /var/crash/|wc -l
<ogra_> 6
<ogra_> bah
<ogra_> i had cleared it for the last reboot
<ogra_> its only up since a few minutes
<ogra_> seems /usr/lib/arm-linux-gnueabihf/upstart-app-launch/zg-report-app is one of the crashers
<ogra_> hwee
<ogra_> whee even ...
<ogra_> and the session upstart is leaking ram like crazy
<ogra_> seems RES rises by 2M every second while the screen is on
<ogra_> it is at 141M now
 * ogra_ makes the image writable and installs last nights upstart upload
<ogra_> i wonder if that fixes it
<popey> i have one unity crash and one _usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash
<popey> but don't see the memory leak
<ogra_> using Mir ?
<lool> ogra_: it might be when dealing with crash files
<lool> ogra_: there's a file watch on this
<ogra_> lool, does upstart deal with them in the session ?
<lool> hmm no, you're right
<ogra_> i thought thats the system upstart
<lool> ogra_: it could logging
<lool> ogra_: ls -ltr .cache/upstart/ perhaps
<ogra_> well, i installed the ubuntu6 package from the archive
<ogra_> lets see how this behaves
<ogra_> no wilddly growing files in the logdir
<ogra_> the session init is at 27M already
<ogra_> and pumped itself to 32M while i typed the above
<ogra_> 39
<ogra_> 41
<ogra_> 44
<ogra_> it only rises while the screen is on
<ogra_> seems to stay where it is with the screen off
<ogra_> 53M btw
<lool> check initctl list as phablet?
<ogra_> http://paste.ubuntu.com/6196152/
<ogra_> nothing obvious
<lool> gtg
<lool> unity8 is building in cu2d
<lool> didn't pick up bzr the first time, but did the second time
<ogra_> ping once you build a new image
<lool> ok
<popey> ogra_: no, sf
<fginther> Saviq, lool, the jenkins IP problem is resolved
<ogra_> so after ~30min it starts swapping like crazy
<ogra_> http://paste.ubuntu.com/6196223/
<ogra_> which is what i saw initially as UI hangs
 * ogra_ reboots into SF
<ogra_> popey, bug 1235649
<ubot5> bug 1235649 in upstart (Ubuntu) "session upstart leaks massive amounts of memory on Ubuntu Touch" [Critical,New] https://launchpad.net/bugs/1235649
<popey> how do I enable mir?
<ogra_> touch /homa/phablet/.display-mir
<ogra_> and reboot
<popey> k
<popey> apport as soon as I boot
<ogra_> *home (indeed)
<popey> confirmed
<ogra_> thx
<lool> fginther: awesome, thanks
<lool> == Publishing unity8 ==
<lool> in Unapproved
<lool> in -proposed
<lool> I'll lift the blocks in an hour or so, once it's all built
<jdstrand> lool: you mentioned lifting blocks in an hour. is that why I can't upgrade to 82 right now?
<lool> jdstrand: nope
<lool> jdstrand: what's your issue upgrading?
<lool> jdstrand: I'm just about to lift some block hints on 3 packages we want to let out of proposed together
<lool> (lifted)
<ogra_> lool, did you see the above bug ?
<ogra_> pertty much a Mir blocker i think
<lool> ogra_: yeah
<lool> ogra_: it would also explain why it crashes after a while
<ogra_> right
<ogra_> the device seems to start swapping once i hit ~250M ... from then on i can only use the UI every few mins
<lool> ogra_: I'll raise this to jodh
<lool> but I guess only Monday
<ogra_> what i find really odd is that this hasnt occured before to me ... and i actually ran Mir for a day or more beofre
<lool> it's also weird that upstart would have loads of memory
<ogra_> *before
<lool> ogra_: did you see anything pile up in initctl list as ~phablet?
<lool> like, many apps starting
<lool> cause I mean upstart shouldn't have much tracking to do
<ogra_> the amount of lines initrctl list returns doesnt change
<ogra_> the amount of running apps neither
<ogra_> it is somehow related to screen activity ...
<lool> ogra_: I was actually thinking, you might be able to strace this upstart from the user session
<lool> it's not great to see where memory goes, but you might be able to tell what it's doing
<lool> like starting processes, opening fds, writing to files
<lool> ok, pkgs are in release pocket now
<lool> uh no
<lool> looks like if I ever block them once, removing the block isn't enough, I need to unblock them explicitly
<lool> ah no, britney stopped running
<lool> popey, ogra_: No -proposed migration for now until britney/firewall are unstuck; will ping if there is an update
<ogra_> k
<popey> lool: ok
<lool> ogra_, popey: Unstuck, building an image
<popey> great
<ogra_> ok
<lool> popey, ogra_: Image was up; I can't install Clicks from the store anymore; could you do this with 82?  can't remember whether I tested it
<lool> either it was already in #82, or it's an unity8 thing given the list in http://people.canonical.com/~ogra/touch-image-stats/20131005.changes
<popey> lool: pretty sure I installed from store
<popey> let me try now
<lool> with #83, I press Install and nothing happens
<popey> lool: yes, i have ureadit on my 82 image, which i installed from the store
<lool> cool
<popey> want me to try?
<lool> popey: sure
<popey> ok
<popey> just tried again on 82 to make sure it's not a backend issue, and installed something fkine
<lool> popey: important thing for me was confirm #82 wasn't broken in this respect
<popey> *fine
 * popey flashes
<lool> if #83 works for you, then perhaps there's something wrong here I need to figure out
 * popey flashes
<lool> and it's bad for you too, then I guess I can open the unity8 bug early and we know we wont promote it
<popey> ya
<lool> (I actually upgraded, didn't flash)
<lool> [unity-scope-click] - DEBUG: click-scope.vala:253: got details: Akari
<lool> [unity-scope-click] - DEBUG: click-scope.vala:255: getting creds
<lool> [unity-scope-click] - DEBUG: ubuntuone-credentials.vala:35: Using account id: 1
<lool> that's where .cache/unity-scope-click.log stops
<lool> it might be a server side issue too
<lool> in which case you would see this with #82 too
<popey> i happened to install that same app
<popey> just now, on 82
<lool> they were changing stuff recently to cope with authenticated downloads for free apps failing
<lool> popey: and that worked?
<popey> yes
<lool> cool
<popey> and the game runs
<lool> :-)
<popey> lool: installed fine on 83
<lool> popey: apps?
<popey> yes
<lool> ok, in a way it's good news
<popey> hmm
<lool> in another, well
<popey> well. they installed
<lool> I suspect something related to the oauth stuff happening behind the scenes with my U1 account
<popey> but i dont see them in the dash
<lool> I also played for the first time with the download-manager settings in OS updates
<lool> I told it to never automatically download
<lool> but it should not affect downloads of click-scope
<popey> but if i search, i find it and it runs
<lool> popey: oh yeah, that's a known bug, you have to reboot to see them
<popey> ah
<lool> or search forthem
<lool> this has been for weeks
<popey> no, just locking is sufficient
<popey> just locked / unlocked and both apps show up
<lool> ah that's an improvement
<lool> filed https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1235784 for the click thing
<ubot5> Ubuntu bug 1235784 in unity-scope-click (Ubuntu) "Click install stalls; nothing happens when pressing Install button" [Undecided,New]
<lool> if it's only me, then it shouldn't get in the way of promotion; it's probably unrelated to the recent upgrades, just a bad oauth state somewhere I'd guess
<vila> lool, popey: just discovered the lock/unlock in 82, may have work previously I'm not sure, I can't reproduce reliably it may just be that some process needs time so lock/unlock late enough and it seems to reveal the apps ?
<lool> anyway, tests will be running, we can assess promotion on Monday
<lool> vila: what do you mean?
<lool> vila: there's sometimes a window where the lock screen doesn't appear immediately; is that what you meant?
<vila> lool: the lock/unlock trick to reveal click apps already installed
<lool> oh ok
<vila> lool: I was rebooting before more or less randomly to get them back, found them back after a lock/unlock, came here, saw popey mentioning it. Synchronicity ;)
<lool> :-)
<lool> Ok, going off, I don't really expect we can do much more this week-end anyway
<popey> ok
<lool> popey: Thanks a lot for the testing
<popey> np
<lool> popey: if you're playing with #83 and you find it's good, let me know and we can promote early on Monday with ogra's ack
<lool> I'll keep an eye on the tests
<popey> will do
<lool> they just started
#ubuntu-ci-eng 2013-10-06
<jibel> ogra_, I confirmed bug 1235649 with build 82 and attached a small graph that illustrate it. I'll try to collect more accurate mem usage with smap
<ubot5> bug 1235649 in upstart (Ubuntu Saucy) "session upstart leaks massive amounts of memory on Ubuntu Touch" [Critical,Confirmed] https://launchpad.net/bugs/1235649
<ogra_> jibel, great, thanks !
<ogra_> lool, #83 looks okayish, not worse than 82
#ubuntu-ci-eng 2014-09-29
<ogra_> hmm, no psivaa
<brendand> ogra_, sil2100 - was there a bug raised for the welcome screen stats?
<ogra_> yes
<ogra_> bug 1374553
<ubot5> bug 1374553 in livecd-rootfs (Ubuntu RTM) "In image rtm 69 infographics stopped functioning" [Critical,Fix released] https://launchpad.net/bugs/1374553
<sil2100> ogra_: it's fixed now, right? With the outlined fix?
<brendand> ogra_, do you know which package broke it?
<brendand> ogra_, i know it landed in #60 but i couldn't see anything obvious
<ogra_> brendand, see the bug :P
<ogra_> brendand, the switch to a hardcoded password DB gives us non-changing UIDs ... but it also prevents package postinst scripts from creating users ... and thus theor home dirs
<ogra_> *their
<brendand> ogra_, it broke in this image: http://people.canonical.com/~ogra/touch-image-stats/rtm/60.changes
<ogra_> sil2100, right, should be fixed since saturday in all images
<brendand> ogra_, i'm not sure which source package livecd-rootfs is in
<ogra_> brendand, sure ... it broke when the buold system was changed
<brendand> ogra_, ah ok
<ogra_> livecd-rootfs is the source package :)
<brendand> ogra_, so nothing that landed
<sil2100> ogra_: it's not any package from the image :)
<ogra_> right
<sil2100> ogra_: \o/
<sil2100> brendand: how many hands do we have today from QA?
<sil2100> Is it only you?
<ogra_> psivaa, yo !
<sil2100> (in this TZ)
<psivaa> ogra_: hello
<brendand> sil2100, for what purpose? for silo testing we have 2 others
<sil2100> brendand: since this was the primary RTM blocker, it would be nice to have someone doing promotion dogfooding of the latest RTM image on krillin
<ogra_> psivaa, you might see that all app test fail ... https://code.launchpad.net/~ogra/phablet-tools/phablet-test-run-fix-broken-shell/+merge/236252 and silo 002 (ubuntu) have the fix for that
<ogra_> psivaa, i would be very grateful if you could try a run with this
<psivaa> ogra_: ack, thanks for the info. i'll try and see if I can run that
<brendand> sil2100, hmm ok
<ogra_> psivaa, i think pauls concerns on the MP are moot, but i would like that proven first :)
<sil2100> brendand: would you be able to do that?
<ogra_> brendand, btw, i did a lot of AP testing on the weekend ... and i saw a lot black squares where icons should be doing that ...
<ogra_> specifically header icons seemed to be missing
<sil2100> grrr
<ogra_> sil2100, so what happened about that unity8-fake-env addition ? i dont see it dropped anywhere yet
<brendand> ogra_, did you check again if it happens manually?
<ogra_> brendand, "manually" ?
<brendand> ogra_, outside of autopilot i mean
<ogra_> i ran the tests manually with phablet-test-run
<ogra_> well, the apps seems fine when i use them if you mean that
<brendand> ogra_, yeah that's what i mean
<sil2100> ogra_: yeah, didn't seem to get resolved yet, we need to pick it up today as well
<ogra_> brendand, hmpf ... that didnt strike me yet :P
<ogra_> must be AP or the environment ... (and with my luck its the latter :( ... )
<psivaa> ogra_: http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/251/console is running with that patch
 * ogra_ hugs psivaa 
<sil2100> ogra_: piing
<psivaa> :)
<ogra_> sil2100, no harps !!!!
<brendand> popey, https://docs.google.com/a/canonical.com/spreadsheets/d/1Mw46QHRVqmaf_NSL2L-jNcEYNlQzbcsJyaXvhjSgSSY/edit?usp=sharing
<ogra_> hah
<ogra_> psivaa, i see a lot of "OK" scrolling by :)
<brendand> popey, ubuntu-touch/ubuntu-rtm/14.09-proposed
<brendand> popey, should be #72
<brendand> popey, or er, something different on mako
<psivaa> ogra_: yea :). will make a note and approve your MP
<ogra_> \o/
<ogra_> i'll try to catch sergiusens or ricmm for top approval then
<ogra_> so we can land this quickly
<sil2100> brendand: no no, we want popey to test utopic
<sil2100> brendand: you test 14.09 on krillin, I want popey to test utopic on mako, to see if we can promote for the devel channels as well
<popey> gimmie a channel and an image number and I will â»
<sil2100> popey: ubuntu-touch/devel-proposed and image number 261 !
<sil2100> :)
<brendand> popey, sorry - you're right
<brendand> agghh, what's wrong with me this morning :/
<brendand> sil2100, sorry - *you're right* :)
<ogra_> you could indeed try #72 from ubuntu-touch/devel-proposed :)
<ogra_> might come along a little old fashioned though
<sil2100> Damn, I even checked my last 'we promoted an image!' e-mail and everything I wrote there is EXPLICIT about what we promoted to where
<sil2100> I cannot be more explicit, as I was mentioning the series and the channel name all the time, not using even once the term 'RTM image'
<popey> brendand: also, need a spreadsheet
<brendand> popey, gave you a link, and made you a new tab
<popey> so you did!
 * popey hugs brendand 
<popey> sorry, bit slow this morning. spent the weekend at a conference
<ogra_> ricmm, are you around ?
<ogra_> ricmm, i could need a top approval of https://code.launchpad.net/~ogra/phablet-tools/phablet-test-run-fix-broken-shell/+merge/236252
<ricmm> ogra_: done
<ogra_> gracias !
 * ogra_ wonders if someone would be interested in such a phablet-shell feature: http://paste.ubuntu.com/8454250/ 
<ogra_> (being able to run "phablet-shell <commmand>" and phablet-shell "sudo <command>")
<ogra_> (the latter only interactively though)
<ogra_> bzoltan, i'm, landing a change that makes phablet-test-run requite a password for "-p (package)" operations, i think you use that in your script ... please add "-r <password>" to these calls
<ogra_> *require
<bzoltan> ogra_:  thank you
<ogra_> zbenjamin, ^^^ does the SDK use phablet-test-run anywhere ?
<zbenjamin> ogra_: not that i know of
<ogra_> thanks !
<ogra_> psivaa, new phablet-tools should be in the PPA ... would likely make sense to have it upgraded and re-run todays tests
<popey> ogra_: would you expect "adb devices" to work on #261 mako ? I see no devices listed with developer mode on.
<ogra_> i would, yes
<ogra_> try toggling it on/off in the UI and see
<ogra_> popey, note that adbd nowadays starts after lightdm ... (since we need the dbus and upstart environemnt variables set before starting it)
<psivaa> ogra_: not yet there i suppose in the ppa, (Candidate: 1.1+14.10.20140923-0ubuntu1) will try in a bit
<ogra_> ah, most likely one more publisher run needed then
<ogra_> psivaa, argh ... seems it is sitting in uapproved in utopic ... so it isnt even up to date there
<psivaa> ogra_: ack, will wait for it then.
<sil2100> brendand: hey, how's the dogfooding going?
<brendand> sil2100, might have hit a snag
<brendand> sil2100, the camera totally locked up
<sil2100> Oh noes
<sil2100> Any specific steps to reproduce? Is it reproducible?
<ogra_> cameras are overrated ... lets ship a drawing program as fallback and promote ;)
<ogra_> ah, wait, that would also need an image rebuild ...
<sil2100> Let's put GIMP on the images!
<brendand> sil2100, looks like rebooting helped
<sil2100> It has a touch-friendly interface
<brendand> ogra_, you know what's definitely overrated?
<brendand> ogra_, infographics :P
<ogra_> well, they work, dont they ?
<ogra_> (or is there still anything missing)
<nik90> brendand, sil2100: I have had that issue while dogfooding the latest rtm devel-proposed images that sometimes opening the camera app locks up everything...and I am forced to reboot the phone. I did not try to restart unity8, but the problem is there.
<nik90> brendand, sil2100: this was during this weekend
<nik90> on mako
<brendand> nik90, yeah - but i have seen this in the past too, so not sure if it's new
<ahayzen> nik90, i had that as well .. saw some crash logs related to camera/location service around the time...but since i've cleared my crash logs and restarted a few times it appears to be working
<nik90> ahayzen: when I reboot the phone (when camera locked up) and then relaunch camera it asks for location permission and then works as expected.
<nik90> ahayzen: so yeah it could be related to the location service trust prompt'
<ahayzen> nik90, yeah thats what mine did the next time IIRC...and since then it has been 'ok'
<pstolowski> Mirv, hey, could you please help me understand the state of row #52? (i'm unclear what the comment means in practice, and what to do next)
<popey> ogra_: i get no adb on #261 at all, enabled dev mode and rebooted, and waited
<popey> ogra_: mtp works, so not a broken cable/port
<sil2100> nik90: did you see something similar previously?
<sil2100> I saw people reporting it already in the past, so I would assume it was with the last 14.09 promoted image already
<nik90> sil2100: not sure see I only started dogfooding this weekend...but I noticed it 2-3 images back.
<popey> brendand: i cant play videos on 261, but i can't adb in to figure out why
<Mirv> pstolowski: I think that ended up needing consultation from sil2100 on how to proceed in the best way. sil2100: so if we'd like to rebuild that from sources for rtm, what would be the best way? one possible would be to remove the current package in the PPA and then sync with rebuild forced.
<Mirv> ie. the case where binary copy has already been done, but then it's noticed a build from source would be wanted instead
<sil2100> hmmm
<sil2100> Mirv, pstolowski: why a source rebuild is needed for that RTM silo? What's the problem there?
<Mirv> sil2100: I think it was dependency problem because of other packages having the ~rtm version string
<Mirv> and the utopic version depending on >= without ~
<sil2100> Ah, ok, which packages versions are missing?
<sil2100> The best way here is to simply add the packages that cannot be resolved to this sync and release them along with the rest of the silo, so that the ~rtm versions vanish
<Mirv> sil2100: http://irclogs.ubuntu.com/2014/09/26/%23ubuntu-ci-eng.html#t13:13
<sil2100> Mirv: thanks!
<Mirv> so, unity-scopes-api
<pstolowski> sil2100, Mirv i haven't been following that landing, trying to catch up today as pete is on paternity leave
<sil2100> Ok, let's try adding that to the sync
<Mirv> ok, so the plan is to get rid of ~rtm version strings while encountered
<Mirv> sil2100: thanks!
<sil2100> Since the ~rtm versions and the utopic *should* be practically the same by principle, testing of that component can be slightly neglated
<sil2100> So it shouldn't introduce additional overhead :)
<sil2100> And this way we'll clean out the archive state as well
<sil2100> Mirv: yeah, I mean, they're ok when not causing trouble, but if they do the best way is to get rid of them
<sil2100> Since we want to remove the need of source copies
<sil2100> pstolowski: ok, unity-scopes-api is copying to the PPA - could you later check if the silo installs properly there?
<pstolowski> sil2100, will do, thanks
<sil2100> mzanetti: hey!
<mzanetti> hi sil2100
<sil2100> mzanetti: in some of the recent images last week we noticed something disturbing - it seems something in our images started pulling in unity8-fake-env
<mzanetti> hmm
<mzanetti> interesting
<mzanetti> sil2100: will investigate
<sil2100> Most probably unity8-common pulls it in for unknown reasons?
<sil2100> It's in ubuntu-rtm for sure, not sure about ubuntu
<mzanetti> yeah... I'll sort it out. thanks for letting me know
<sil2100> mzanetti: so, maybe there are some problems with resolving unity-application-impl now? I see the last upload bumped it to unity-application-impl-3
<mzanetti> should be 4
<mzanetti> soon will be 5
<mzanetti> but yeah, seems like its that
<mzanetti> sil2100: ok... yeah, will fix
<sil2100> mzanetti: thanks!
<sil2100> popey: hey! How's the mako utopic dogfooding so far?
<popey> sil2100: done. see spreadsheet
<popey> sil2100: two issues. 1) can't play video, 2) can't adb in
<ogra_> popey, OTAing my mako ...
<popey> i can play video in browser, but cannot launch from the video scope
<popey> ogra_: fwiw this was a clean / wipe install
<ogra_> yeah, but i dont think that matters
<popey> k
<popey> just data for you â»
<ogra_> popey, hmm, works fine here
<ogra_> popey, cna you check if adbd is running from the terminal-app
<popey> ya
<ogra_> and also if "android-gadget-service status adb" reportis it running
<popey> it isnt
<popey> "adb disabled"
<ogra_> but the UI shows it enabled ?
<ogra_> thats weird, i had fixed that
 * ogra_ notes that Laney seems ot have changed his developer mode code on top though ... 
<ogra_> i wonder if that landed yet
 * ogra_ checks
<popey> well this is odd
<popey> it says developer mode disabled
<popey> but I _did_ enable it!
<ogra_> did you change the password after you enabled it ?
<popey> no
<ogra_> (that will disable it again)
<popey> set password in wizard
<ogra_> hmm, yeah, Laney's changes landed on wed it seems ... so i would expect to heard earlier of issues if it would have caused any
<popey> wonder why it disabled it
<ogra_> me too
<popey> maybe i swiped across from right to switch apps and that got caught by the switch
<popey> and turned it off
<ogra_> does it work now after you enabled it ?
<popey> yes
<ogra_> psivaa, i just got the updated phablet-tools from the trusty PPA ... seems ot be there now
<psivaa> ogra_: ack, will update
<sil2100> popey: can you try getting the video problem confirmed by someone?
<popey> ogra_: ^^ can you laucnh videos from the video scope?
<popey> (local ones)
<ogra_> let me copy one
<ogra_> popey, nope, doesnt start
<ogra_> popey, fyi, works fine on krillin RTM 72
<ogra_> (phew, so it isnt my dbus changes like jhodapp claimed on friday :P )
<popey> sil2100: ^^
<sil2100> popey: thanks!
<sil2100> So, it seems no promotion for utopic until that's fixed
<Mirv> psivaa: I'm kicking rtm 004 a bit for you, as the utopic already landed
<Mirv> unping psivaa
<Mirv> pstolowski not here, doh
<psivaa> Mirv: ack :)
<psivaa> ogra_: plars: http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/ is running the tests with the new phablet-tools
<psivaa> i;m going to pop out for  a brief lunch.
<ogra_> psivaa, awesome, thanks !
<plars> psivaa++
 * ogra_ hopes this was really everything now 
<plars> ogra_: sorry, didn't notice that the -r in that MP was only relevant if you were also calling -p
<ogra_> plars, yeah ... np
<sil2100> \o/
<plars> ogra_: as usual, you've thought of everything already :)
<ogra_> heh, as usual i'm sure new issues will pop up :)
<ogra_> (which i *didnt* think of indeed)
<ogra_> ;)
<cjwatson> sil2100: Can I have a silo for 73 (click)?  I'd like it binary-synced to RTM too.
<sil2100> cjwatson: ACK!
<cjwatson> ta
<pstolowski> Mirv, sil2100 following our earlier conversation, when can i retry silo-18 (row #52)?
<sil2100> pstolowski: hey! You can try it almost instantly, as it's a binary copy so the packages should be available instantly ;) Sorry for not mentioning that
<pstolowski> sil2100, ah, thanks!
<Mirv> pstolowski: it looks ok now. I also fixed/prepared rtm-004 for you.
<pstolowski> Mirv, sil2100 thanks!
<sil2100> brendand: hey!
<sil2100> brendand: so, any final verdict on the RTM image?
<ogra_> it is shiny :)
<brendand> sil2100, i wanted to reserve judgement until the landing meeting
<om26er> retoaded, do you know whats wrong with this build http://ci.ubuntu.com/smokeng/utopic/touch/mako/261:20140929:20140923.1/10738/ ?
<om26er> looks like most of the tests didn;t run
<retoaded> om26er, I'll take a look
<retoaded> om26er, It might be related to the move of the devices to a new host, I will need to check with plars
<om26er> retoaded, thanks
<ogra_> om26er, fixes are in
<ogra_> om26er, see my mail to phablet@
<plars> om26er: there was some fix in phablet-tools that I think just got updated for us a bit ago this morning
<ogra_> right
<plars> yeah, that^ :)
<ogra_> :)
<plars> I wasn't on the morning call so I don't have all the juicy details
<ogra_> there was a "sudo -u phablet -i /bin/sh -c" wrapped around everything
<ogra_> in the now properly functioning dev mode this does exactly what you tell it (unlike before) and drops the complete environment to whatever /bin/sh has by default
<ogra_> (so you lose connection to dbus and upstart ...)
* plars changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: plars | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: queuebot has gone crazy, temporarily disabled
<sil2100> mzanetti: hey, so you found the final reason why we pulled in -fake-env in the end?
<mzanetti> sil2100: no, not yet. testing silo 6 now hoping it disappeard (as we bumped those dependencies once again)
<sil2100> mzanetti: ACK
<brendand> mzanetti, which silo is splash screen stuff meant to be in?
<mzanetti> brendand: rtm/19
<mzanetti> brendand: not sure though why it says "can't build" now...
<mzanetti> I tested this on friday
<brendand> mzanetti, yes i was about to say - it's not in our queue
<mzanetti> brendand: a bit puzzled now. do you know what to do with this?
<ogra_> sil2100, ^^
<sil2100> o>
<mzanetti> I can't rebuild it because the qtmir package would get a new version and so the qtmir-gles package would need to be changed. but then this is rtm and not real branches attached afaiu
<mzanetti> brendand: but afaics we could just test it and merge it... the packages in there are still valid I think
<mzanetti> brendand: did I miss something to push it to your queue?
<brendand> mzanetti, you didn't, but until citrain confirms that it needs QA signoff, it won't go to the queue
<brendand> mzanetti, so sil2100 might be able to help you fix that
<sil2100> hmm
<sil2100> mzanetti: let me take a look
<sil2100> mzanetti: ok, so it seems it didn't sync up the qtubuntu-gles package
<mzanetti> oh
<mzanetti> does that have one too
<mzanetti> gotta jump to a meeting... back in a bit
<sil2100> mzanetti: ok, let me sync up that one then
<sil2100> mzanetti: ok, qtubuntu-gles syncing up
<brendand> cjwatson, can you respond to balloons_ in https://code.launchpad.net/~nskaggs/phablet-tools/fix-1371241/+merge/235213
<brendand> cjwatson, i think that issue is causing ci a lot of pain recently
<sil2100> brendand: hey! Meeting!
<cjwatson> brendand: commented
<plars> fginther: mterry: I'm thinking we should probably merge that patch for unlock. It's really hard to test without bypassing a lot of things, and we don't have a reliable way to reproduce. fginther were you ever able to try anything with it?
<mterry> plars, I filed an MP for it
<plars> mterry: oh awesome
<brendand> cjwatson, i *think* you approve?
<cjwatson> brendand: no, the second half makes sense now but I remain unconvinced by the first half
<cjwatson> see the bit where I say "*not*"
<brendand> cjwatson, so why do we care about a package already in the image?
<cjwatson> that's the question I asked
<brendand> cjwatson, we want to get the tarball of autopilot tests which match that version
<cjwatson> brendand: That makes sense for get_source_package_tests.  What about get_python_binary_package?
<cjwatson> There are two quite different functions being changed here.
<cjwatson> get_python_binary_package does not nominate a specific version, so there is clearly no version-matching going on.
<cjwatson> It looks to me as though get_python_binary_package just wants basically the latest published thing that apt would give you.  If that's correct then removing these restrictions is wrong.
<fginther> plars, mterry, I hacked together a test case to use the updated version of the unlock logic. It worked in my very limited testing (on mako-04 I saw it retry the unlock multiple times and it worked on another device).
<plars> great
<brendand> cjwatson, i wasn't expecting get_python_binary_package to be changed so i overlooked that
<cjwatson> (Because it's possible for a newer version to be removed and then deleted; or for a version to be in -proposed that hasn't yet made it to the release pocket because it fails autopkgtests or something; or ...)
<brendand> cjwatson, perhaps balloons_ can comment on that
<cjwatson> I'll copy and paste this into the MP to clarify
<ogra_> given that our image is always built from existing packages i dont think you need to worry about -proposed (since the version is handed over, no ?)
<balloons_> cjwatson, you are correct. get_python_binary_package needs the latest version as apt would give
<cjwatson> ogra_: we certainly do for --depends
<ogra_> oh, ok, didnt think of that
<cjwatson> Specifically phablet-click-test-setup --depends foo should surely not take a version of foo from -proposed
<cjwatson> Or a deleted one
<cjwatson> (In the former case, perhaps unless you specifically ask for it)
<ogra_> yeah
<balloons_> cjwatson, I'll remove the change from get_python_binary_package.
<cjwatson> Cool, thanks
<cjwatson> balloons_: I can imagine cases where you do want -proposed (though it would still need to be Published or maybe Pending), so a new switch might be appropriate
<cjwatson> (I don't know this script well enough to pronounce on that)
<balloons_> cjwatson, yea, the --depends is kind of a hack really as phablet-tools is not really reading depends from the manifest or trying to match a version
<balloons_> cjwatson, so I think just pulling what's in apt should be anough. If for some reason you need --proposed, you can handle that manually
<cjwatson> balloons_: *nod*
<popey> sil2100: brendand https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1375349
<ubot5> Ubuntu bug 1375349 in unity8 (Ubuntu) "Can't launch videos on mako utopic #261" [Undecided,New]
<cjwatson> balloons_: (would approve but merge conflict)
<balloons_> cjwatson, yea, I repulled and made the change against trunk, one sec
<balloons_> cjwatson, new mp: https://code.launchpad.net/~nskaggs/phablet-tools/fix-1371241-try2/+merge/236385
<cjwatson> balloons_: *blink*, in general you don't need a new MP
<cjwatson> just push over the top of the previous branch
<cjwatson> but well, too late :)
<balloons_> cjwatson, yea, that branch go diverged and I commited to it before pulling and merge from trunk.. perhaps I could have salvaged it
<balloons_> for a 1 line change, I didn't try ;-)
<ogra_> balloons_, sorry, did i land it pre-maturely ? the MP was signed off and tested
 * ogra_ assumes that was https://launchpad.net/ubuntu/utopic/+source/phablet-tools/1.1+14.10.20140918-0ubuntu1
<balloons_> ogra_, we were speaking about: https://code.launchpad.net/~nskaggs/phablet-tools/fix-1371241-try2/+merge/236385
<ogra_> oh, ok
<balloons_> the original mp got conflicted because phablet-tool changes landed; yes I believe it was your changes, but :-)
<ogra_> well,  phablet-click-test-setup only had one change from you that i pulled in
<ogra_> (because it was sitting for so long already and was tested and approved)
<ogra_> balloons_, that was https://wiki.ubuntu.com/Touch/Testing in case you didnt catch it in the hangout
<balloons_> ogra_, ack ty
<ogra_> :)
<brendand> sil2100, the issue with dialer-app is that the call button is disabled
<sil2100> Uh, why?
<brendand> sil2100, but this isn't the case outside the AP tests
<brendand> sil2100, could be to do with ofono-phonesim
<sil2100> Ah, ok, so no possible issues from the user side
<brendand> sil2100, i need to go for a bit, but i'll raise a bug about it later
<sil2100> ogra_: can you promote #72 and all the related ones? :)
* plars changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: queuebot has gone crazy, temporarily disabled
<ogra_> sil2100, will do (breakfas^Wdinner now)
* retoaded changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: retoaded | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: queuebot has gone crazy, temporarily disabled
<Ursinha> robru: I think we can remove the queuebot issue from topic, unless it's crazy again
<robru> Ursinha: oh right
* robru changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: retoaded | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<sil2100> ogra_: thanks! :)
<sergiusens> robru: can I have a silo for line 61?
<sergiusens> robru: err 71
<robru> sergiusens: ok you got 20
<robru> brb
<sil2100> popey: thanks for the bug :)
<sil2100> plars, ogra_: btw. since I either missed that or it wasn't moved, but what's up with utopic image results for mako?
<sil2100> plars: btw.2 I guess we can bring back unity8 to the test results now ;)
<ogra_> === Image RTM #3 promoted ===
<sil2100> ogra_: yaaay
<sil2100> :)
<ogra_> (this is: krillin 72, mako 63 and generic/_x86 59)
<ogra_> sil2100, hmm so looking at rtm silo 009, do i have to copy-package lxc-android-config or will the build button do that automatically when i hit build (with the sync: line in the spreadsheet)
<ogra_> (all my former silos simply had the package magicaally in them, did you then copy them in ?)
<sil2100> ogra_: it will do it automatically :)
<ogra_> s/silos/sync silos/
<ogra_> oh, cool
<sil2100> It will do a binary copy
<ogra_> magic !
<ogra_> :)
 * sil2100 is a mage
<ogra_> :)
<cjwatson> Is the emulator known-broken today on devel-proposed?  Black screen for me.
 * ogra_ hasnt heard anything 
<cjwatson> unity8 not running
<ogra_> hmm, did you genereate ir afresh ?
<ogra_> or was that upgraded
<ogra_> i wonder if the transition of the dbus file is actually dist-upgrade safe
<cjwatson> Fresh
<cjwatson> "sudo ubuntu-emulator create --channel=ubuntu-touch/devel-proposed click"
<ogra_> yeah, then i dont think that is related
<popey> brendand: do you know who is responsible for the change which caused bug 1374474 ?
<ubot5> bug 1374474 in Ubuntu File Manager App "Files don't open in external applications due to url-dispatcher change" [Undecided,Confirmed] https://launchpad.net/bugs/1374474
<popey> (a bug you filed last week)
<popey> aha, ted
<cjwatson> "initctl: Event failed" in ~phablet/.cache/upstart/xsession-init.log
<ogra_> why is that triggered at all ?
<racarr> can someone give me write access to the spreadsheet?
<cjwatson> "start on startup"
<cjwatson> I don't think it really means X
<ogra_> no, but it only gets executed if  [ "$SESSIONTYPE" = "gnome-session" ]
<ogra_> sounds like something is wrong with lightdm ?
<cjwatson> Not true
<brendand> popey, i just landed that change in RTM too - it's completely intentional
<cjwatson> pre-start only bails out if [ -z "$DESKTOP_SESSION" ], and DESKTOP_SESSION=ubuntu-touch
<brendand> landed/signed-off
<racarr> robru: Can you give me write access to the spreadsheet?
<popey> brendand: right, but it breaks apps...
* retoaded changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<popey> how are we landing stuff which intentionally breaks apps and then telling the app authors _after_?
<popey> this seems broken
<brendand> popey, ted told them a while ago
<popey> where?
<popey> aha, found it
<popey> your bug is basically a dupe of bug 1366217
<ubot5> bug 1366217 in Ubuntu File Manager App "Filemanager sending out file:/// URLs" [Undecided,New] https://launchpad.net/bugs/1366217
<popey> gah
<robru> popey: hey what was that bug reference for the mediascanner scope? i didn't see it
<popey> bug 1375349
<ubot5> bug 1375349 in unity8 (Ubuntu) "Can't launch videos on mako utopic #261" [Undecided,New] https://launchpad.net/bugs/1375349
<brendand> popey, yeah essentially - i just wanted to make sure first
<robru> popey: thanks
<popey> â¹
<robru> racarr: oh yeah, hang on
<racarr> robru: Yay, thanks
<robru> racarr: you're welcome!
<racarr> robru: Ok now I actually need a silo! for row 80...
<racarr> and I need to land it to RTM too...with a sync
<robru> racarr: please mark column J as 'Yes'
<racarr> robru: :) done
<kenvandine> robru, i'm getting an exception trying to reconfigure a silo, utopic silo 2
<kenvandine> https://ci-train.ubuntu.com/job/ubuntu-landing-002-0-reconfigure/4/console
<kenvandine> robru, ^^
<robru> ugh
<robru> oh I broke the spreadsheet
<robru> kenvandine: ok try again
<plars> sil2100: ok, I'll turn it back on
<robru> racarr: your landing conflicts with silo 8, but that one's just about free so hang on
<ogra_> yay
<robru> don't worry this is just temporary
<plars> whoa
<kenvandine> robru, thx, that looks better :)
<robru> kenvandine: you're welcome
<kenvandine> robru, how do i reconfigure a silo which adds a package?
<racarr> robru: Ok. Thanks.
<kenvandine> it failed for me... but i see no options to twiddle
<robru> kenvandine: you need to use the prepare job, not the reconfigure job. click 'Prepare' in the dashboard
<kenvandine> oh...
<robru> kenvandine: "reconfigure" is the limited one that we let the plebs use
<kenvandine> haha :)
<robru> can't add packages. just for adding new MPs to same packages
<ted> popey, Back from lunch, did you get enough info?
<robru> kenvandine: are you going to build a silo soon? let me know if anything explodes, I'm experimenting a bit (sorry)
<kenvandine> barry, building in silo 2
<kenvandine> robru, i just clicked build :)
<barry> kenvandine: excellent.  let's see if si builds the first time around :/
<robru> kenvandine: hm, now I wonder if my changes landed in production in time for your build... ;-)
<robru> racarr: bah! qtubuntu conflicts with silo 7. please coordinate with mzanetti, kgunn, greyback (can your landings be merged? who should go first? etc)
<racarr> robru: we just merged our landings :)
<robru> racarr: excellent!
<robru> i'll reconfig then
<racarr> robru: Thanks
<robru> racarr: kgunn: so what happened? did you put all the MPs from line 55 into line 80? can you do it the other way around since line 55 is already assigned?
<racarr> robru: Oh...from line 55...
<racarr> Lol...there was already another landing
<racarr> forming below mine
<racarr> so thats the one we consolidated
<robru> guys...
<robru> kgunn: what are you doing on line 55? you have a silo assigned and never build it
<kenvandine> barry, can you look at the failure in silo 2?
<kenvandine> barry, i think it's because you have a changelog entry ?
<kenvandine> barry, https://ci-train.ubuntu.com/job/ubuntu-landing-002-1-build/71/console
<robru> kenvandine: barry: yeah if you guys touch debian/changelog in your MPs, then citrain can't mangle the changelog for you. you need to either revert your debian/changelog entries in your MPs or go all the way, doing debian/changelog in all of them
<kgunn> robru: ok, we'll use 55
<robru> and it has to be UNRELEASED
<kenvandine> robru, yeah, thought so
<robru> kgunn: ok let me know once you have all the MPs in line 55 the way you want
<kenvandine> barry please fix :)
<barry> robru: :(
<barry> robru: i want a changelog entry
<barry> i can fix it to be UNRELEASED though
<kenvandine> barry, you'll get one automagically
<kenvandine> ok
<robru> barry: don't touch debian/changelog, just set the commit message on your MP and it gets created for you with the right versions and everything
<barry> robru: this way has worked so far, but maybe it's because i've always put si in its own silo
<robru> hm
<kgunn> robru: thanks for the catch, mind a quick reconfig on utopic-silo 7
<barry> robru, kenvandine re-pushed with UNRELEASED.  is that enough?
<kenvandine> barry, trying again
<kenvandine> the error message made it sound like UNRELEASED is enough
<robru> i think so, been a while since i saw one of those though. we usually discourage touching debian/changelog by hand
<robru> kgunn: ok silo 7 is go for build
<barry> robru: i'm trying to be different just to keep your life interesting
<kenvandine> :)
<brendand> sil2100, you forgot to mention what we talked about in the meeting
<robru> barry: yeah that's what I need, life to be more interesting ;-)
<barry> robru: :)
<kenvandine> robru, great quote "My dreams of escaping bash have been dashed."
<sil2100> brendand: there will be a separate e-mail for that
<sil2100> brendand: it doesn't make sense to include it, as I'm afraid many people don't read that
<sil2100> So there will be an announcement
<robru> hahah
<kenvandine> sil2100, depends on how many replies
<sil2100> kenvandine: ;)
<kenvandine> if i don't catch the emails before it gets a few replies... i might skip it with the thought i'll come back when i have more time
<kenvandine> and never do :)
<kenvandine> robru, there is no *escaping* bash :)
<robru> kenvandine: lol
<robru> kgunn: https://ci-train.ubuntu.com/job/ubuntu-landing-007-1-build/44/console looks like you got some messed up MPs, seems somebody is trying to merge gles into trunk?
<kgunn> ah hell
<kgunn> robru: ok, one more reconfig, sorry...going too fast
<robru> kgunn: no worries
<robru> kgunn: ok give it a shot
<kgunn> ta
<sil2100> robru: btw. will it break queuebot or the dashboard if I append something to the 'N/A' selection in the 'QA sign-off needed' column?
<sil2100> robru: e.g. 'N/A (nickname)'? I hope you're not doing a compare of string equals anywhere for that, right?
<robru> sil2100: uh
<robru> sil2100: I think the compare only cares about 'Granted' or 'Required', the N/A isn't tested
<sil2100> robru: ok, that's what I wanted to know
<sil2100> Awesome
<ogra_> rsalveti, the roll back of ubuntu-touch-meta is stuck in proposed due to some unity-scope-click adt failure
<rsalveti> argh
<ogra_>  dpkg-source --after-build unity-scope-click-0.1.1+14.10.20140915
<ogra_> dpkg-buildpackage: binary-only upload (no source included)
<ogra_> tar: Unexpected EOF in archive
<ogra_> tar: Unexpected EOF in archive
<ogra_> tar: Error is not recoverable: exiting now
<ogra_> hmpf
<dobey> robru: hey, i just saw sil2100's mail, and trying to change the field to "N/A (dobey)" but spreadsheet just changes it back to "N/A (nickname)" :(
<robru> uh
<robru> ok, it's that cell validation, hang on
<robru> dobey: ok should be good
<dobey> robru: ok, thanks. and i see you already set it, thanks for that too :)
<robru> dobey: you're welcome!
<robru> cjwatson: hey do you have any time today to poke around a bit with copy2distro on snakefruit? https://code.launchpad.net/~robru/cupstream2distro/fix-copy2distro/+merge/236234 i have a branch that cleans up copy2distro and resurrects all the missing bits, should be good to go but needs a bit of babysitting to make sure it doesn't explode
<bfiller> fginther: is there a way to get the click package for this MR? not seeing the link.. https://code.launchpad.net/~renatofilho/ubuntu-calendar-app/fix-1373566/+merge/236038
<bfiller> robru: can I have RTM silos for lines 78+79 please
<robru> bfiller: ok rtm 10 and 11
<bfiller> robru: thanks
<robru> bfiller: you're welcome
<camako> trainsguards, can I get a silo for row 84 please?
<robru> camako: https://ci-train.ubuntu.com/job/prepare-silo/2417/console yeah you got some conflicts here
<camako> robru, ok yeah I'm aware of those landings.. We'll have to serialize at some point
<robru> camako: if you want the silo i can give it to you, but you have to be sure that the other ones get rebuilt after one of them lands
<camako> robru, yes sir.. that's well understood... Landings invalidate our tests and we restart..
<robru> camako: ok so did you still want it then?
<camako> robru, yes but I lemme double-check what this is "WARNING Project name (qtmir) doesn't align with the source package name (qtmir-gles)".. Will ping you back in a minute
<robru> camako: oh that's fine, it used to be a hard requirement that the lp:projectname match the source package name, but we loosened that restriction a while back and the -gles stuff is a mess anyway. ideally you guys would register lp:qtmir-gles but instead you're doing lp:qtmir/gles and it's not the worst thing in the world
<robru> but still there's a warning about it ;-)
<camako> robru, ok just wanted to make sure I didn't push to the wrong branch... Yes a silo 'd be nice please
<robru> camako: ok, rtm20
<camako> robru, thanks
<cjwatson> robru: ok, new branch is in place
<cjwatson> (old one is in ~ubuntu-archive/cu2d/cupstream2distro.rtm, should anyone need to move it back)
<cjwatson> robru: but I'm not around for a whole lot longer, so if you have anything you can test it with sooner rather than later, that'd be nice
<robru> cjwatson: hm i don't see anything ready to publish
<robru> cjwatson: who has access to snakefruit if I need somebody to revert?
<cjwatson> robru: ~ubuntu-archive intersect ~canonical
<cjwatson> robru: or SMS my UK mobile number in the directory
<cjwatson> robru: Steve L or Adam C would be reasonable contacts this time of day
<robru> cjwatson: ok thanks
<robru> cjwatson: and if I say something like "I need you to go into the citrain bits on snakefruit" they'll know where to find that stuff on snakefruit?
<cjwatson> robru: copy and paste the thing I said above
<cjwatson> 22:37 <cjwatson> (old one is in ~ubuntu-archive/cu2d/cupstream2distro.rtm, should anyone need to move it back)
<cjwatson> it just needs to be pivoted with what's currently ~ubuntu-archive/cu2d/cupstream2distro
<cjwatson> they should be able to work it out given that
<robru> cjwatson: so ~ubuntu-archive/cu2d/cupstream2distro contains https://code.launchpad.net/~robru/cupstream2distro/fix-copy2distro and not trunk, right?
<cjwatson> robru: Correct
<cjwatson> r763
<robru> cjwatson: right, ok, thanks a bunch. if I see publishes succeeding over the next day I'll merge that branch to trunk.
<robru> cjwatson: perfect
<cjwatson> And .../cupstream2distro.rtm has lp:~sil2100/cupstream2distro/cu2d-rtm r676
<robru> oh, interesting.
<robru> i'm surprised that wasn't trunk. we'll definitely want it to *be* trunk once we confirm trunk is fixed.
<cjwatson> robru: Sure.  It wasn't trunk because we needed a branch for the RTM work, and nobody ever asked to have it switched back.
<robru> cjwatson: ok no worries, thanks
<robru> man, that landed-landings-become-new-landing-requests bug is getting worse
<ToyKeeper> mzanetti, greyback, kgunn: The rotation/splash screen silo looks good, but the test plan still needs to be updated with tests for the new behavior.
<camako> robru, do you know what this error is about? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-020-1-build/15/console
<camako> robru, do I just restart the build?
<robru> ugh
<robru> hang on
<robru> camako: no don't rebuild, everything built fine, that's just a weird error, not sure what caused that
<camako> robru, ok
<robru> camako: I'll start on a fix for that right now...
<camako> robru, sounds good
<robru> sergiusens: alright! you get to be the first guinea pig on the new publish logic ;-)
<sergiusens> should I be happy? :-P
<robru> sergiusens: probably not ;-)
<robru> sergiusens: just keep an eye on your landing. if it stays in "no known spacetime" for longer than usual it means I broke some stuff
<sergiusens> robru: what's new here?
<robru> sergiusens: just some code refactoring and removing some vestigial stuff. it shouldn't really be any different at all, but there's always a risk I can make a typo and break everything
<sergiusens> robru: joys of python I don't miss :-)
<robru> sergiusens: oh, other languages are immune to typos are they? :-P
<sergiusens> robru: at least the annoying ones in python ;-)
<imgbot> === trainguards: IMAGE 262 building (started: 20140929 22:50) ===
<rsalveti> ^ requested by me
<cjwatson> robru: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/+publishinghistory looks good at least
<sergiusens> robru: so far so good
<robru> sergiusens: excellent
<robru> cjwatson: thanks for keeping an eye. I wanna see one more then I'll merge ;-)
<cjwatson> robru: I want to see at least one in ubuntu-rtm
<cjwatson> Just in case
<robru> cjwatson: good call
<robru> cjwatson: everything's just waiting for qa
<robru> oooooh
<robru> hmmmm, that signoff is suspiciiously absent from the trello board
<robru> ToyKeeper: ^ ?
<ToyKeeper> robru: I was in the middle of doing that...  just needed to finish a message.
<robru> ok
<ToyKeeper> It has test plan issues, but is getting passed before fixing those because it's kind of getting fast-tracked.
<robru> bregma: you got utopic 8
<bregma> wow, speedy
<robru> bregma: amazing hwat happens when silos are available and the bot is functioning ;-)
<bregma> doesn't make _me_ work any faster
<robru> bregma: oh, in that case I can take the silo back... ;-)
<robru> cjwatson: ok published rtm19, fingers crossed!
<ToyKeeper> tvoss, cyphermox_, lool: Got a test plan for silo rtm-012 (network-manager)?  If the silo's new behavior isn't saved into a published test plan somewhere, it's an automatic fail.
<cjwatson> robru: https://launchpad.net/ubuntu-rtm/+source/platform-api/+publishinghistory and https://launchpad.net/ubuntu-rtm/+source/qtmir/+publishinghistory LGTM
<robru> cjwatson: ^^ woop woop! looks good!
<cjwatson> ToyKeeper: Uh, every landing has to update a test plan?
<ToyKeeper> cjwatson: Pretty much.  Any new behavior, bug fixes, etc, needs a test added to prevent future regressions.  Otherwise we get things breaking later and nobody notices.
<ToyKeeper> That's kind of the reason why QA is reviewing every rtm silo.
<cjwatson> ToyKeeper: A test, fine, but requiring it in the test *plan* sounds like a recipe for unbounded growth of manual human (and thus unscalable) testing
<cjwatson> I'm not going to update my test plans to say "you must run the new versions of my automated tests" every time :-)
<ToyKeeper> cjwatson: It doesn't have to be in a manual test plan...  automated tests are preferred.  Just as long as some form of lasting check is created.
<cjwatson> OK, that's a relief, when people say "test plan" around here I assume they mean the TestPlan wiki pages
<ToyKeeper> Test plan, autopilot test suite, unit test, whatever is most appropriate.
<cjwatson> Thanks
<ToyKeeper> It's often easiest to add a manual test first, then use the manual test plan as a list of things to automate.
<robru> camako: hey next time you run a build in your silo, please enable the DEBUG flag.
<robru> camako: that traceback really makes no sense. You must have triggered your build at the exact moment I was doing a deploy, so you got some inconsistent state happening or something. the only way that could get called that way would be if an environment variable is unset, but the build job clearly sets the environment variable. you must have had newer trunk
<robru> code which expects that variable just a moment before the build job was updated to set that variable or something. really weird
<robru> I do have a fix for the "__init__() takes at least 2 arguments (1 given)" bit but that's not the main problem there really...
<cjwatson> robru: So do you want me to flip to trunk now that your branch is merged?
<robru> cjwatson: yes please!
<robru> cjwatson: and you can delete that old .rtm one
<robru> cjwatson: thanks!
<cjwatson> Yeah I'm going to leave it around for a while just in case :-)
<cjwatson> Does no harm
<cjwatson> Deployed code on snakefruit is now lp:~cupstream2distro-maintainers/cupstream2distro/trunk r765
<cjwatson> robru: I wouldn't be totally opposed to auto-pulling this code in ~/cu2d/run.sh if you folks are happy with that
<cjwatson> Might make it easier to tell when problems happened
<robru> cjwatson: I like it. it terrified me to know that ancient code was just sitting around there rotting
<robru> cjwatson: I'll try to write some unit tests for that file one day.
<cjwatson> robru: OK, that's done now too
<robru> cjwatson: speaking of run.sh, you can drop that commented out block, and also drop the --no-filter arg from the active block, because that behavior is now the default
<cjwatson> (Added 'bzr pull -q -d "$BINDIR"')
<robru> cjwatson: sounds good, thanks a bunch
<cjwatson> robru: Done.  I also dropped || true from copy2distro and the pointless cd - at the end
<cjwatson> And moved the shell flags from the #! to a separate 'set' command
<robru> cjwatson: haha
<cjwatson> http://paste.ubuntu.com/8462156/
<robru> cjwatson: so is run.sh called from cron or something?
<cjwatson> yep
<cjwatson> */5 * * * *             ~/cu2d/run.sh > ~/public_html/cicopy.log 2>&1
<robru> cjwatson: oh sweet. where is that log published to?
<cjwatson> http://people.canonical.com/~ubuntu-archive/cicopy.log
<cjwatson> But that's only the most recent run
<robru> cjwatson: right. but if there's some kind of explosion that'll be helpful to have.
<robru> cjwatson: now I wanna fill that with logging so we can see what's going on, will make it easier to maintain that code
<cjwatson> I should extend that and logrotate or something ...
<cjwatson> But effort
<cjwatson> Certainly feel free to log more stuff
#ubuntu-ci-eng 2014-09-30
<imgbot> === trainguards: IMAGE 262 DONE (finished: 20140930 00:45) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/262.changes ===
<imgbot> === trainguards: IMAGE 263 building (started: 20140930 02:10) ===
<imgbot> === trainguards: RTM IMAGE 73 building (started: 20140930 03:10) ===
<Mirv> morning
<imgbot> === trainguards: IMAGE 263 DONE (finished: 20140930 03:45) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/263.changes ===
<rsalveti> cjwatson: ogra_: bug https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1375555
<ubot5> Ubuntu bug 1375555 in qtmir (Ubuntu) "[regression] qtmir landing for image mako 256 (emulator 255) broke the x86 emulator" [Undecided,New]
<rsalveti> jdstrand: ^ as you're always using the emulator (just heads up)
<imgbot> === trainguards: RTM IMAGE 73 DONE (finished: 20140930 04:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/73.changes ===
<robru> camako: thanks for hitting the DEBUG flag, output clearly shows SILONAME being set, so yeah, you must have hit some kind of transient error during the deployment. everything looks fine on this end (well, except your build failing, but that's a separate issue. ;-)
 * Mirv archived landed landings
<lool> ToyKeeper: I dont know what network manager usually uses as test plan; what cyphermox_ told me to test is noted in the spreadsheet: that you see as many wifis around before and after the change
* vila changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: vila | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<ogra_> cjwatson, bah, i messed up with ubuntu-touch-meta again, i copied it to rtm-proposed (had forgotten about the desktop deps) ... is it enough if i copy again but to the rtm archive or does it need archive admin action ?
<Mirv> ^ that's the one-liner for bug #1373807
<ubot5> bug 1373807 in unity-scopes-shell "Unity8 freeze (caused by shell plugin) after performing OA workflow" [Critical,Fix released] https://launchpad.net/bugs/1373807
<popey> Mirv: could yuou please upload http://s-jenkins.ubuntu-ci:8080/job/rssreader-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.shorts_0.2.330_all.click to the store
<cjwatson> ogra_: what no!  don't copy directly to rtm
<cjwatson> you can't anyway :)
<ogra_> didnt we do that the last time ?
<cjwatson> no
<ogra_> and i think i see pitti do it all the time
<cjwatson> pitti needs to stop that :)
<ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-September/000410.html
<ogra_> and steve too :)
<cjwatson> I've asked him not to
<ogra_> k
<ogra_> can you push it through then
<cjwatson> yes, the correct thing to do here is to tell proposed-migration to do it
<cjwatson> pitti and slangasek can do that because they're archive admins, but shouldn't (may be accidental)
<ogra_> right, so i did mindlessly the right thing, great :)
<cjwatson> you can't because you're not
<ogra_> ah, k
<cjwatson> ogra_: you know what, I'd rather not force this, I'd rather finish my job of copying the dependencies
<ogra_> ok, nothing urgent in there iirc
<ogra_> cjwatson, oh, wait ... looking at the excuses page, the notes-app should actually be removed from desktop
<cjwatson> *shrug*
<cjwatson> copying it isn't a problem though
<ogra_> indeed, but we want desktop to match touch
<cjwatson> not my problem for now
<ogra_> no, but one dep less for you
<cjwatson> too late anyway
<ogra_> heh, k
<cjwatson> ok, all of rtm update_excuses should clear shortly
<cjwatson> and ubuntu-touch-meta shouldn't be a problem in the future, at least until more desktop deps are added
<cjwatson> ogra_: also pitti has said he stopped doing that ages ago after the last time I asked him :)
<ogra_> ah, k
<ogra_> i just saw the uploads on the changes ML
<ogra_> sil2100, any idea what happened to the content of rtm-007 ?
<ogra_> (i know it was there yesterday, now the PPA is empty)
<bzoltan2> cjwatson: I have tested the new click with the named chroots. Fixed the QtCreator Ubuntu plugin for it https://code.launchpad.net/~bzoltan/qtcreator-plugin-ubuntu/support_named_chroots/+merge/236245
<bzoltan2> cjwatson: Thank you for that feature. It enabled the automatic functional testing of the SDK tools.
<sil2100> ogra_: let me take a look
<ogra_> the dashboard still says "packages built"
<sil2100> ogra_: ugh
<sil2100> :o
<cjwatson> bzoltan2: Great, thanks for the confirmation.  I've yet to be able to test click properly otherwise because of the emulator being broken at the moment.
<ogra_> i have no prob starting over ... but i thought you might want to investigate :)
<sil2100> ogra_: I have no idea what happened! I'll look into what's up, but you'll probably have to press build and list 'android-tools' there now to get those back in
* vila_ changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<bzoltan2> cjwatson: Yeps, I started my day with the broken emulator. Indeed it is more important.
<ogra_> sil2100, no prob
<ogra_> heh
<cjwatson> bzoltan2: It's not my wheelhouse, but having a look at it to see if I can track down the broken object
<Mirv> popey: shorts uploaded.
<popey> thanks Mirv
<t1mp> is there a problem with the makos (or something else) in CI?
<t1mp> In this MR I get a different (seemingly unrelated) failure for every CI/autolanding run https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977
<t1mp> cihelp ^
<popey> Mirv: could you please upload calendar 484 to the store. http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.calendar_0.4.484_all.click
<sil2100> camako: hey! You want me to perform a rebuild of i386 mir in rtm/20 ?
<t1mp> elopio: do you have an idea what can cause the failures in https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977
<mzanetti> trainguards: please reconfig silo 6 for me
<sil2100> mzanetti: ACK!
<mzanetti> thanks!
<sil2100> mzanetti: ugh, this is taking awfully long
<mzanetti> sil2100: there are quite a few branches in there
<sil2100> mzanetti: ok, done, but just so you know:
<sil2100> mzanetti: WARNING ubuntu-system-settings is already prepared for the same serie and destination in ubuntu/landing-002
<sil2100> and
<sil2100> WARNING qtmir is already prepared for the same serie and destination in ubuntu/landing-007
<mzanetti> hmm
 * mzanetti looks
<sil2100> Please coordinate accordingly
<mzanetti> sil2100: ok. not a problem for landing-007. but indeed need to coordinate with landing-002. thanks for the hint!
<sil2100> yw :)
<mzanetti> *boom*
<bzoltan2> trainguards: I could use a Utopic silo for the  line 70
<Mirv> bzoltan2: ok
<cjwatson> emulator investigations have taken me to http://www.akkadia.org/drepper/tls.pdf .  if I do not emerge in a few hours then please send a search party
<ogra_> lol
<ogra_> cjwatson, i think rsalveti chnaged some TLS bits initially to make the emulator work at all ... not sure that was ever changed back
<cjwatson> ogra_: well we should be able to track down and destroy the libraries that are using static TLS, since in general libraries shouldn't be
<ogra_> ah, i think thats what he did back then
<ogra_> cjwatson, hmm ... http://people.canonical.com/~ogra/touch-image-stats/256.changes ... not sue if you really want the fake-env installed, that came in with the last qtmir landing (by accident it seems)
<ogra_> (some broken "or" dependency )
<cjwatson> not installed on my test system
<ogra_> hmm
<ogra_> how did that end up in the changelog at all ... i dont see it in any of the manifests either
 * cjwatson is walking through debugging steps from https://bugzilla.redhat.com/show_bug.cgi?id=1124987
<ubot5> bugzilla.redhat.com bug 1124987 in calibre "Fix static TLS usage in Fedora shared libraries." [Unspecified,Closed: errata]
<cjwatson> wonder if this libc patch from RH would fix it
<cwayne> sil2100: btw we'll likely need QA to do a pass over a custom tarball today in conjunction with a landing from jdstrand
<sil2100> cwayne: oh, ok, since we're also waiting for test results for the new device tarball
<cwayne> sil2100: ah, ok, cool, how much testing is left to do there?
<sil2100> cwayne: not sure
<sil2100> brendand, john-mcaleely: any news on the device tarball?
<sil2100> kgunn: ping
<kgunn> sil2100: hey
<sil2100> kgunn: hey! So you mentioned that the utopic issue with videos not launching from the scope is related to media-hub - do you know if that landed in utopic already?
<kgunn> sil2100: landed in utopic yes, but not on rtm...was waiting on qa as of last night
<sil2100> Ok, well, it was basically a problem in utopic, so in this case it's good to know it's fixed
<kgunn> sil2100: so you've confirmed those mediahub branches were in the image tested ?
<brendand> kgunn, i just signed off 26
<john-mcaleely> sil2100, none yet. been a morning of distractions
* cprov changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cprov | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<cjwatson> building a test glibc with Carlos's DTV_SURPLUS patch from RH to see if that fixes the emulator
<jdstrand> rsalveti: thanks for the heads up! (I do love the emulator)
<cjwatson> jdstrand: could you have a look over my proposal at the end of bug 1371574?
<ubot5> bug 1371574 in click (Ubuntu) "After installing clicks to /custom/click, /usr/share/click/preinstalled version are still preferred" [Critical,In progress] https://launchpad.net/bugs/1371574
<cwayne> john-mcaleely: sil2100: would it make sense to do a custom + device check? or do they need to be separate
<john-mcaleely> cwayne, I think we should keep them separate
<cwayne> probably makes the most sense
<jdstrand> cjwatson: yes, I was getting through all me other irc pings so I could focus on yours :)
<jdstrand> my*
<cjwatson> heh
<dbarth> hi trainguard, on line 51 i have finished testing the silo
<sil2100> dbarth: you need a sync for RTM now, right?
<dbarth> it's marked as "needs building", but of oxide was binary copied in the silo
<sil2100> dbarth: ah, ACK
<dbarth> sil2100: just next, yes; the line exists, but i still need to repeat the test on my rtm phone now
<dbarth> sil2100: but to test from an rtm silo, i need the sync i guess ;)
<dbarth> do a bin. copy if at all possible, otherwise, it's 5h at best
<sil2100> dbarth: in theory, yes ;) Doing that anyway now
<sil2100> All is a binary copy now
<sil2100> So no worries ;)
<dbarth> nice
<john-mcaleely> sil2100, ogra_ brendand New device tarball
<ogra_> you mean it passed and is released ?
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20140929-d974fdc.tar.xz
<ogra_> cool !
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20140929-d974fdc.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20140929-d974fdc.ods
<sil2100> brendand: ^ o/
<john-mcaleely> I think it now needs your QA signoff
<ogra_> ah
<sil2100> john-mcaleely: thanks :)
<brendand> john-mcaleely, can't access that file
<john-mcaleely> note that at least one test was not performed because I lack the kit (a locked SIM(
<brendand> john-mcaleely, the .ods file
<john-mcaleely> brendand, doh. please try again :-)
<Mirv> sil2100: I wonder how/if Oxide can be landed to utopic, since it's not in bug #1371635 list and is a new version
<ubot5> bug 1371635 in Ubuntu "[FFe] standing freeze exception in utopic for Ubuntu Touch-specific packages" [Undecided,Triaged] https://launchpad.net/bugs/1371635
<sil2100> Mirv: true, depends if this is a bugfix or not
<Mirv> or maybe that is really small(ish) bugfix releae
<Mirv> with oxide, I kind of assumed "huge things changing", but that doesn't look too bad
<sil2100> From the changelog I see that there are many bugfixes there, but only bugfixes
<sil2100> So this could be feasible for a release
<jdstrand> rsalveti: hey, for preinstalled apps on the device (specifically not custom), where do the precached profiles live, in the device tarball? the rootfs?
<Mirv> wget:ing and debdiff:ing two 300MB sources (compressed) makes one appreciated network, cpu and ssd speeds
<ogra_> jdstrand, rootfs
<jdstrand> ok, thanks
<cjwatson> ha!  libc fix is enough
<ogra_> jdstrand, iirc there is a hook for pre-generation in the livecd-rootfs package
<Mirv> sil2100: did you add the oxide rtm line?
<Mirv> I just fixed its fields so that status is correctly shown
<sil2100> Mirv: yeah, I added it some time ago, what happened?
<Mirv> sil2100: adding the rtm silo like that straight beneath the utopic silo is nice (I always do that), but you need to copy-paste C and N columns' special equation from another line
<sil2100> uh?
<sil2100> Mirv: but the line was there
<sil2100> Mirv: I just assigned the silo for that
<Mirv> sil2100: ah, ok, then it was someone else who added the newline originally
<sil2100> Ah, maybe dbarth copied it that way, I didn't check if the formulas were like that
<Mirv> anyway, FYI oxide debdiff (omitting chromium) http://pastebin.ubuntu.com/8466001/
<sil2100> I just changed the sources list to a "sync:" and assigned :)
<thostr_> Mirv: could we get a silo again for line 8?
<fginther> t1mp, added comment on https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977
<t1mp> fginther: thank you!
<t1mp> fginther: so the solution, for now, is to wait for the fix in [1] to land in the image that is used for testing?
<t1mp> fginther: ^ how can I know that the fix is in?
<fginther> t1mp, the fix for [1] landed yesterday, but it did impact all of those results.
<fginther> t1mp, the system-settle problem is new. Was trying to track down if this is being seen elsewhere
<ogra_> fginther, t1mp, note that we see settle_after issues in image smoketesting too ... usually due to unity8-dash not settling properly
<fginther> ogra_, thanks for that info
<ogra_> :)
<ogra_> there was also a bug for the dash about it leaking a lot of memory
<ogra_> might be related
<t1mp> ok, I'll do an empty commit to trigger CI again
<fginther> t1mp, just re-approve the MP
<t1mp> zsombi: ^ can you happrove https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977 again?
<zsombi> t1mp: nope :)
<t1mp> zsombi: this is serious. No time for jokes ;)
<zsombi> t1mp: nope :)
<brendand> john-mcaleely, just getting started with the tarball - i was finishing a silo
<john-mcaleely> brendand, great!
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: fginther | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<sil2100> ogra_: btw. since it's Tuesday again, could you lead the evening meeting? :)
<ogra_> sil2100, since it's Tuesday again, indeed :)
<sil2100> Thanks!
<Laney> IT'S TUESDAY?!?!?!
<ogra_> Laney, didnt they tell you ?
<Laney> nobody tells me anything!
<ogra_> evil !
<thostr_> sil2100: can I get a silo again for line 8
<sil2100> thostr_: sure :)
<sil2100> thostr_: hmm, there are at least 2 silos with u-s-s right now
<thostr_> sil2100: right, we'll sync once we now how it tests
<sil2100> Ok
<ogra_> hmm, the indicators look weird in the latest utopic image
<cjwatson> ogra_,rsalveti,jdstrand: emulator should be unbusted in the next image build after glibc publishes
<popey> Mirv: still about? can you upload that calendar click?
<ogra_> cjwatson, cool, i'll make sure we get a build then
<sil2100> ogra_: didn't we land that indicator-display thing in utopic?
<ogra_> "that indicator-display thing" ?
<ogra_> can you be more specific ?
<ogra_> indicator-display is in both archives afaik
<ogra_> and now also seeded in both images
<jdstrand> cjwatson: cool, thanks!
<ogra_> (with the next rtm build)
<cjwatson> ogra_: glibc takes ~3h to build on armhf, and it'll presumably trigger All The Autopkgtests, so might just end up being tomorrow morning's run
<ogra_> oh, yeah, sounds like it :)
<jdstrand> cjwatson: and you now have a response to bug #1371574
<ubot5> bug 1371574 in click (Ubuntu) "After installing clicks to /custom/click, /usr/share/click/preinstalled version are still preferred" [Critical,In progress] https://launchpad.net/bugs/1371574
<cjwatson> ta
<jdstrand> np
<jdstrand> stepping into a meeting now, so won't be terribly responsive for a bit
<cjwatson> jdstrand: will ponder, and likewise
<jdstrand> k
<brendand> ogra_, for silo 7 did you just test that the bugfix works?
<ogra_> brendand, i did everything i described
<ogra_> (see the spreadsheet)
<cjwatson> ogra_: I guess if everything works tomorrow we should sync glibc through a silo into rtm; I can't point to a single change that caused this, it was a limit we tipped over, and we could tip over it in rtm at any time
<ogra_> ok
<brendand> ogra_, so it's not worth repeating any of the same tests i ran for the last android-tools-adbd landing?
<ogra_> brendand, i only left QA signoff checked because the package has more than one fix included :)
<jhodapp> sil2100, line 25 in the spreadsheet (silo 13) is ready to publish
<ogra_> brendand, not really ... juust verifying the two bugs are fixed should be fine i think
<sil2100> jhodapp: thank you!
<jhodapp> sil2100, np! :)
<Mirv> popey: sure
<Mirv> thostr_: seems you've got it now
<Mirv> popey: hmm, have I missed some link? my Debian hosting irssi crashed earlier today and I restarted
<popey> Mirv: ah okay... yes
<Mirv> popey: oh, yes I have!
<Mirv> popey: found
<popey> thanks
<Mirv> done
<rsalveti> cjwatson: thanks for fixing glibc
<rsalveti> jdstrand: there are only two possible paths for preinstalled apps, either custom or rootfs
<rsalveti> jdstrand: at least atm we're not shipping any app in the device tarball
 * ogra_ hopes we'll (they*ll) never do 
<ogra_> robru, meeting ?
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<jdstrand> rsalveti: ack, thanks
<brendand> john-mcaleely, actually just hold on a little bit before pushing it
<john-mcaleely> ogra_, sil2100 new device tarball pushed
<john-mcaleely> brendand, ah
<ogra_> merci !
<brendand> john-mcaleely, give me 15-20 minutes more
<john-mcaleely> brendand, sorry. I thought I could push, and I have
<cwayne> sil2100: do you guys have time for a QA custom then?
<brendand> john-mcaleely, ok well the thing i had trouble with is something you guys tested, so i expect it might be something else causing me trouble
<john-mcaleely> brendand, ah, what?
<brendand> john-mcaleely, anyway if we get bitten then we can always improve the test plan
<brendand> john-mcaleely, video playback - yes i too don't see how the tarball could break that
<john-mcaleely> brendand, that's super flaky, so some files are definately still broken
<AlbertA2> trainguards: utopic landing-013 is ready to publish
<brendand> john-mcaleely, it's one that worked earlier in the day
<john-mcaleely> brendand, and we can break it in the device tarball, but I don't think this one has changes there.
<john-mcaleely> brendand, hrm. not so good
<john-mcaleely> brendand, +1 on iterating the test plan
<brendand> john-mcaleely, in the worst case scenario are tarballs revertable?
<john-mcaleely> brendand, yes, and I'd be happy to do that drill.
<john-mcaleely> brendand, it's good practice :-)
<brendand> john-mcaleely, ok phew - it's not the tarball but something that landed in #73
<john-mcaleely> brendand, phew!
<john-mcaleely> brendand, ah, there's a bug in the test plan. no slot for which build I tested against...
<john-mcaleely> brendand, your master is view-only for me. can you revise it?
<brendand> john-mcaleely, done. and i made a new tab - can you complete the name and copy the contents of the ods file in there?
<john-mcaleely> brendand, sure
<brendand> john-mcaleely, actually i was going to say my preference would be for you just to create new tabs in that doc for each test run
<john-mcaleely> brendand, ok. I'll save each tab as an ods - otherwise I'm not publishing them :-)
<brendand> john-mcaleely, i'll ignore that
<john-mcaleely> brendand, fine by me
<robru> pstolowski: ok you got utopic 24
<pstolowski> robru, thank you
<robru> pstolowski: you're welcome!
<robru> kgunn: not sure what's going on in utopic-6 there. let me know if you need me to delete qtmir/u-s-s
<mzanetti> trainguards: need another reconf of silo6 please
<popey> fginther: did you see pings about music remix 2.0 needing to be added to jenkins?
<robru> mzanetti: really a reconf, or do you just wan me to delete qtmir and u-s-s? (eg did you add MPs?)
<cwayne> sil2100: brendand: heya, would you guys be able to test a custom tarball for release today? or would we need to wait for davmor2?
<mzanetti> robru: yeah, that would be enough. I removed some mps
<brendand> cwayne, i don't think it will happen today
<robru> mzanetti: ok, clicked delete, that takes a few minutes to take effect.
<mzanetti> robru: thanks
<robru> mzanetti: you're welcome
<jhodapp> robru, what does the status on utopic silo 13 mean exactly?
<jhodapp> robru, I want to get that published
<robru> jhodapp: it means it's in the proposed pocket ;-)
<robru> jhodapp: it means it's been publish it's just not done yet
<jhodapp> robru, ah, I guess I was referring more to the one package at least is not available in the destination message
<robru> jhodapp: right, that's because one package at least is not available in the destination ;-)
<jhodapp> robru, lol, ok...confusing me because there only being 1 package in my silo
<jhodapp> robru, but I guess it's a generic message
<robru> jhodapp: if it stays like that for more than an hour or two, you can click on the package name (the one where it says "in the proposed pocket", not the one in the upper list), and it'll show you the proposed migration page that might explain if there's any problems with the migration
<jhodapp> robru, ok cool, thanks
<robru> jhodapp: yeah it's a generic message, the one package you're publishing just isn't in release pocket yet, it's in proposed.
<jhodapp> robru, ok, thanks for humoring my question :)
<robru> jhodapp: you're welcome!
<plars> mterry: did that unlock loop fix land yet?
<mterry> plars, no but it did get approved
<fginther> popey, yes. I'm just now getting to that
<popey> fginther: awesome, thanks
<robru> hehe
<robru> That's odd, both my laptops lost Wi-Fi at the same time, but my phone is working fine
<fginther> balloons, can you provide a review for: https://code.launchpad.net/~fginther/cupstream2distro-config/add-music-remix/+merge/236586
<balloons> fginther, is the hook_source outdated now? I was noticing it on reminders
<fginther> balloons, no, the special version of the pep8 pyflakes checker for reminders is still in that branch
<balloons> fginther, ahh right.. to ignore the other plugins, gotcha
<balloons> I approved, thanks
<fginther> balloons, much thanks
<sergiusens> robru: hey, can I get a silo for line 57? Not all MPs are approved, but I need to do some test builds
<sergiusens> thanks
<robru> sergiusens: you're welcome!
<sil2100> Ok, now that was intense
<sil2100> brendand, ogra_, cwayne: so the custom tarball sign-off has been moved to tomorrow? Or did someone else got assigned to the sign-off
<cwayne> sil2100: sounds like it
<sil2100> cwayne: maybe we could ask ToyKeeper? Or can you wait for tomorrow indeed?
<ToyKeeper> Hmm?
<ToyKeeper> If that's what I think it is, it's probably going to be 8+ hours of testing to cover all the click apps, and even then will probably have significant gaps.
<cwayne> 8+ hours? davmor usually does it in like 2-ish..
<sil2100> cwayne, ToyKeeper: I guess you would have to poke davmor or brendand about that
<cyphermox_> sil2100, could you please sync urfkill from Silo ubuntu 11 to RTM 24? I think you have some Jenkins job to do that or is it purely juste the build job?
<sil2100> cyphermox_: CI Train does it easily, let me take a look
<brendand> cwayne, what's the urgency?
<sil2100> cyphermox_: yeah, so I see all is configured properly - just press the build job and input 'urfkill' in the list of packages to rebuild
<cwayne> brendand: no huge urgency except it'll pre-seed the aggregators as favorites, and it will go with jdstrand landing apparmor-easyprof
<sil2100> It'll sync it up if a sync is needed
<brendand> cwayne, so you won't die if it lands tomorrow :)
<ToyKeeper> cwayne: I'm estimating 5+ hours for the AP tests, and a few more for manual exploration, plus extra time to check whether the bugs also existed before the change.
<cwayne> brendand: I didn't even ask again to do it today sil2100 asked if it was going to happen today, calm down :)
<sergiusens> cjwatson: robru the rtm silos only build for the 3 popular arches, right? Means a binary copy from rtm silos to ubuntu ones are not desirable, or am I overthinking here?
<ToyKeeper> (depending on what actually changed, that is...  any unchanged click apps can skip the AP tests and get reduced manual testing, which speeds things up a lot)
<brendand> cwayne, you calm down...
<robru> sergiusens: you're right, it's better to binary copy from utopic to rtm
<brendand> cwayne, i'm sure davmor2 will be happy to look at it
<cwayne> brendand: that's fine, I'm not even trying to push for it today anymore! i accepted earlier when you said it probably wouldn't be today
<cyphermox_> Sil2100 thanks
<sergiusens> robru: so I'll tick "only copy source" since I'm doing it the other way around; not sure if the missing arches would be rebuilt (I think they are); but would be better if they are built from one place together
<robru> sergiusens: right, I think the better solution is to start in utopic. there's some changes in the pipeline that'll make it easier to build in utopic first and then just publish to utopic and rtm simultaneously without even needing two different silos.
<sergiusens> robru: well the big blockers (time wise) have to be at the beginning of the pipe and not end; qa signoff is one of those
<robru> sergiusens: right, but everything will be faster if you only have one silo to test & publish rather than needing two.
<sergiusens> robru: well if that is made irrelevant, the where to push is too as we only have one :-P
<sergiusens> robru: and that's good news if true
<robru> sergiusens: yep, sil2100 is working on it, hopefully should land soon-ish
<sil2100> o/
<robru> heh
<sil2100> Oh uh!
<robru> sil2100: quick, let's push it to production!
<robru> ;-)
<cjwatson> sergiusens: Yes, but it would work out - a binary copy from ubuntu-rtm to ubuntu would copy the binaries have have been built and rebuild the rest
<cjwatson> sergiusens: Which doesn't really seem worse than rebuilding everything
<cjwatson> *that have been built
<cjwatson> robru: That sounds reasonable, indeed, if I'm guessing the implementation correctly
<sil2100> ogra_, cjwatson: is the emulator in a fixed state right now?
<cjwatson> sil2100: Fix is only in -proposed right now, pending doing something about autopkgtest failures
<robru> cjwatson: yeah, basically the publish job just also does a binary copy
<cjwatson> robru: Well, two binary copies rather than just one, presumably
<robru> cjwatson: right, well, the publish job doesn't really do a binary copy, it just makes that rsync file so snakefruit can do a binary copy, but yeah
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: fginther | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<cjwatson> robru: It should probably have snakefruit do both
<cjwatson> The reasons for that would be the same either way ...
<robru> cjwatson: makes sense.
<robru> sil2100: ^^ sounds like you need to be hacking on copy2distro ;-)
<sil2100> No no
<sil2100> No hacking needed
<cjwatson> sil2100: The autopkgtest queue is way too full right now for it to be worth me looking at it for a bit.  If you desperately need the emulator to work, then you can boot it once, adb shell, grab the libc6/libc-bin/multiarch-support i386 binaries from LP utopic-proposed, dpkg -i, reboot
<sil2100> What we'll do is simply the publish job will write 2 entries to the rsync file and we're done ;)
<robru> sil2100: oh, can it be that easy? dear god
<dbarth> robru: hey, do i need to make a special request to get the new language-pack into rtm?
<dbarth> robru: i need 1:14.10+20140923 or superior to fix the accept-language headers with oxide
<robru> dbarth: well if nobody requests it, it doesn't happen automatically, so... yes
<dbarth> i can add a silo dependency for ex?
<robru> dbarth: just make a regular landing request, and in source packages put 'sync:ubuntu,utopic language-pack' (or whatever the source package name is)
<dbarth> adding an oxide dep update is a bit of a pain
<dbarth> ok, perfect
<dbarth> i'll put that in silo 18
<robru> dbarth: ok you're going to want it to say 'sync:ubuntu,utopic oxide-qt language-pack' then and then you'll have to wait for oxide-qt to fully land in utopic, thenreconfigure and rebuild the rtm silo
<dbarth> robru: rebuild? oxide is a binary copy (given the time it takes)
<robru> dbarth: yeah but the build job will need to re run in order to do the binary copy for language-pack
<dbarth> robru: ok
<dbarth> robru: i copied your line in the cell, hope it's fine this way now
<robru> dbarth: right, is 'language-pack' the source package name? i don't actually know
<dbarth> checking
<dbarth> robru: uh, there is a source package for each language:
<dbarth> like https://launchpad.net/ubuntu/+source/language-pack-touch-de
<dbarth> it's language-pack-touch-{...}
<robru> dbarth: right so you need to list the source package names in that spreadsheet cell. it only works on source package names.
<dbarth> uh ok, i need to find an example with the right list
<robru> dbarth: but in the case of language-pack-touch-de it looks like the rtm version is actually newer than the utopic version so I'm not sure what you're trying to accomplish exactly
<dbarth> robru: i just noticed that the problem with oxide accept-lang headers is fixed in utopic
<dbarth> (it takes a langpack update techically)
<dbarth> whereas it's still not fixed in rtm
<dbarth> hmm
<robru> dbarth: perhaps some other source package is responsible
<robru> i don't actually know much about langpacks.
<dbarth> not fixed in rtm #74
<dbarth> so maybe i'm not on the right rtm channel
<dbarth> robru: so i put it back to sync:16 for now
<dbarth> will clarify tomorrow morning with pitti how to handle safely
<robru> dbarth: ok no worries
<robru> brb, lunch
<ted> robru, I need a silo for integration work with mterry, line 77. Should that be "ready" or just not ready as it's actually not ready? :-)
<robru> ted: "ready" means "give me a silo"
 * ted doubles down on readiness
<ted> robru, Ready! :-)
<robru> ted: ok, 13
<ted> robru, Great, thanks!
<robru> ted: you're welcome!
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<bfiller> robru: silo 1 in ubuntu not showing up correctly in spreadsheet
<robru> bfiller: what row?
<robru> bfiller: i don't understand the state the spreadsheet is in. address-book-service seems landed?
<robru> but the silo is there
<barry> robru: finally got si 2.5 built in landing-002!  i am a good monkey
 * robru gives barry a banana
<barry> oo oo aa aa
<camako> why are our CI mahines using kernels from 2012? Kind of old for an OS company...
<robru> camako: because they're probably running precise, because it's an LTS, because any company would desire stability from a server?
<camako> Robru, I have code that requires kernel >= 3.11.. and the unit tests are failing. What do I do?
<robru> camako: uh, fix your code?
<robru> i dunno
<robru> camako: like make your unit tests conditional on the right kernel being present or something
<camako> robru, lol... this was the "fix"
<barry> camako: ping infinity (i think) or stgraber tomorrow and see if one of them can help you
 * camako was hoping you'd say we can build/run on a newer kernel
<robru> camako: i don't have any power over what system the buildfarm uses.
<robru> camako: like you're talking about a PPA build right? that's not even part of the citrain system that I'm maintaining, that's into lp itself.
<camako> robru, understood...
 * camako goes back to revert the offending "fix"
* robru changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<robru> rsalveti: anpok_: kgunn: mzanetti: Mirv: poke because you guys have silos that are "Ready to build". any chance we could kick some of those builds off?
#ubuntu-ci-eng 2014-10-01
<bfiller> robru: I need rtm silos for line 81,82, and 83 when you have a chance
<bfiller> robru: scratch that, 80, 81, and 82 I mean
<robru> bfiller: oh goodies
<robru> bfiller: well, let's do everything in 3's today! You got silos 6, 9, and 12.
<bfiller> I love threes :)
<robru> bfiller: i landed some changes to the build job today, let me know if anything explodes (should be good, I tested it all day before landing)
<bfiller> robru: will do
<robru> bfiller: thanks
<robru> oooh
<bzoltan> trainguards: I have flipped the "tested" switch for the silo17 with the QtC plugin. It has changes in the debian/ folder as it provides the new -autopilot package. This change was one of the main target of the 14.10 SDK tools.
<Mirv> robru: mine has many builds (=manual uploads), but it's a preparation silo that will stay there for a good while so the status is not very useful to have updated
<robru> Mirv: OK no worries, just wanted to test the newly-refactored build job, but bill built a bunch, looks good.
<Mirv> bzoltan: I'm worrying slightly more about the autopilot tests being a new feature and there being no FFe
<Mirv> (than the packaging changes as such)
<bzoltan> Mirv:  the package change is that it introduces a new package
<bzoltan> Mirv:  Well, the autopilot package is not pulled by any dependency and does nothing special than tests the QtC plugin.
<Mirv> bzoltan: yeah, it's nothing special, but because it's a new package it will stop at archive admins' hands anyway so I'm just wondering before-hand what they'd think about it
<Mirv> adding tests of course sounds of course always welcome, and the click support additions are more like bug fixes themselves, so maybe it's alright
<Mirv> bzoltan: couldn't you do the debian/rules file installations from the qmake files instead of hand-copying so many files?
<Mirv> not that it would be completely wrong, but ideally there wouldn't be any need for dh_override_auto_install
<bzoltan> Mirv:  I  lost the net, I am not sure if you have seen my last two lines.
<Mirv> alright, no I didn't, but I see them now in msg
<bzoltan2> Mirv:  I made two new lines with the UITK landings... both RTM and Utopic... whichever can land first. Obviously RTM is the priority. It has 4 RTM bugs fixed.
<brendand> ogra_, i'm testing silo 7 now - i guess it will require me to go through all the recovery mode dance etc, etc?
<tsdgeos> is jenkins qa down?
<tsdgeos> jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-utopic/1444 doesn't load here
<tsdgeos> and obviously it came back after 5 minutes the moment i mentioned it here :D
<Mirv> bzoltan2: ok. rtm first I'd say
<bzoltan2> Mirv: Yes, I agree
<Mirv> bzoltan2: sorry, took a while, assigned and kicked a build
<bzoltan2> Mirv:  no hurry :) thanks
<Mirv> (and rekicked)
<Mirv> the build job has been reimplemented by robert, that first error sounds a bit like something might be a amiss. forcing (ignore step) + ignore dual works though.
<davmor2> Morning all
<brendand> davmor2, do you know where to get the custom tarball?
<davmor2> brendand: yes from the channel
<brendand> davmor2, ok
<Mirv> pstolowski: thostr_: ^ both your unity-scope-mediascanner2 and mediascanner2 landings how now rtm silo and are building, so should be ready for testing soon.
<pstolowski> Mirv, thanks
<Mirv> pstolowski: in your scopes-shell landing, the MP URL is not MP URL but branch
<Mirv> the fix-delete-later one
<pstolowski> Mirv, ah, sorry, fixed
<Mirv> thanks!
<mzanetti> trainguards: silo utopic/006 tested. ready to go.
<mzanetti> hmm... seems its not mirrored yet to a rtm silo.
<mzanetti> we might want to do that first I guess
<Mirv> kgunn: mzanetti there's unbuilt and untested unity 8 rtm-011 landing "Unity8 indicator polish fixes ("
<Mirv> mzanetti: it's enough the sync silo is synced before the utopic one is cleaned
<mzanetti> Mirv: oh... I thought kgunn tested the indicators polish for rtm already
<mzanetti> Mirv: I can test that now
<Mirv> mzanetti: ok. build it first, though :)
<mzanetti> ack, building
<mzanetti> Mirv: hmm... what does that mean? (silo rtm/11)
<Mirv> mzanetti: err.. I don't know
<Mirv> as usual, I'll workaround instead of trying to understand the error since it's beyond me
<mzanetti> :D
<mzanetti> that's you get the job done
<ogra_> mzanetti, yo ...
<mzanetti> ogra_: :)
<ogra_> mzanetti, we seem to see unity8 crashes in app tests with the last utopic image
<Mirv> mzanetti: ok the packages are binary copied now manually, just needs maybe 10-20mins so that they are Published instead of Pending
<Mirv> as seen at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-011/+packages
<mzanetti> Mirv: so I can already start testing that ppa now, right?
<mzanetti> ogra_: have some more details?
<ogra_> mzanetti, if you scroll to the bottom of http://ci.ubuntu.com/smokeng/utopic/touch/mako/264:20141001:20140929.1/10758/ubuntu_calculator_app/
<Mirv> robru: possibly interesting build failure https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-011-1-build/40/console (workarounded now by manually copying packages)
<ogra_> there is a .crash file
<ogra_> unity8 itself also seems to have a bunch of errors doing its own tests in utopic http://ci.ubuntu.com/smokeng/utopic/touch/mako/264:20141001:20140929.1/10758/unity8/
<ogra_> mzanetti, it seems rtm is fine ... so i think it would be good to find the issues before something migrates over
<mzanetti> ogra_: that's a race condition... we're investigating into that
<ogra_> cool, thanks !!
<mzanetti> ogra_: but I think its in rtm too... just not happening always
<ogra_> ah
<mzanetti> ogra_: not sure what's up with the calculator tests yet... will check out
<mzanetti> ogra_: do you know how I get the calculator tests on my device?
<ogra_> https://wiki.ubuntu.com/Touch/Testing
<ogra_> under "Running click tests"
<mzanetti> ogra_: hmm... seems to fail with an exception
<mzanetti> list index out of range
<ogra_> do you have the patest phablet-tools ?
<ogra_> *latest
<dbarth> hi trainguards; silo rtm 16 ready to land now
<mzanetti> ogra_: I didn't have that. now I upgraded. still happening though
<ogra_> weird
<mzanetti> well... let me upgrade everything... might take a bit
<Mirv> mzanetti: yes, now ready
<mzanetti> Mirv: thanks
<Mirv> dbarth: you probably mean rtm 018? it's goind for QA signoff now.
<ogra_> mzanetti, hmm i cant reproduce the unity8 crash when running the calculator tests here ...
 * ogra_ re-runs again 
<mzanetti> ogra_: phablet-test-setup still not working for me
<ogra_> mzanetti, did you run "phablet-config autopilot --dbus-probe enable" first ?
<ogra_> thats what i do ...
<ogra_> and then:
<ogra_> phablet-click-test-setup --click com.ubuntu.calculator;  phablet-test-run ubuntu_calculator_app
<cjwatson> bzoltan2: That new version of click is in utopic now, by the way.  Not RTM yet - need to test that today and put through QA.
<ogra_> runs fine here
<mzanetti> ogra_: hmm.. no... didn't run that... from that wiki page I understood that's to be ran after installing the click packages... will try
<cjwatson> camako,robru: Which specific builds are you talking about here?  All the virtualised builders in the Launchpad build farm are on trusty nowadays, but it's true that the devirtualised farm is still on precise.
<cjwatson> (Mostly.  Being devirtualised it's not totally homogeneous, especially across architectures.)
<ogra_> mzanetti, "phablet-click-test-setup" standalone would just install all click tests ..
<ogra_> (no need for that)
<mzanetti> ogra_: yeah... I tried with adding --click ...
<cjwatson> camako,robru: The problem with upgrading the devirtualised build farm has historically been concerns about what effect it's going to have on building security updates for older but still-supported distributions (say, lucid-security or precise-security).  Possibly we can get over that ...
<lool> (about to publish this one, any reason not to?)
<lool> then will need a rtm silo  :-)
<dbarth> Mirv: indeed rtm 18
<bzoltan2> cjwatson: All right, the SDK counterpart has landed too few hours ago. Good job :) thank you.
<Mirv> lool: oh, you're our tvoss now? how about testing rtm-001 with location-service?
<Mirv> (the previous version, already in utopic)
<lool> Mirv: hmm pretty sure that wont work
<lool> or rather, that it needs a coordinated landing
<Mirv> lool: anyhow, that ^ can't make it into rtm before the previous landing, since ^ already includes the previous landing (that landed together with dbus-cpp) also.
<Mirv> either the 001 should be combined into the upcoming location-service rtm silo, or 001 should be landed first.
<lool> Mirv: right; what I believe is that 001 or anything subsequent needs a coordinated update of the custom tarball
<lool> it might be less effort for QA etc. to do a single location-service landing with everything I guess
<Mirv> ok. added some notes to both landings in the spreadsheet for now.
<Mirv> combining might be as easy as updating rtm-001 description and resyncing the location-service from utopic. but it's up to you to decide. certainly it'd mean less QA work.
<Mirv> interestingly, the dbus-cpp change already landed together with media-hub
<bzoltan2> Mirv:  do you know who is the LP guru/jedi I could ask to change the UITK project setup?
<cjwatson> What do you need changing?  (I probably don't have relevant permissions, but I expect I could figure out who does)
<Mirv> bzoltan2: ^ same question
<Mirv> mzanetti: stop breaking the good train! :)
<mzanetti> Mirv: :D
<mzanetti> I don't even know what I'm doing to break it
<Mirv> mzanetti: the -gles branch's watch file is wrong, should point to 007
<mzanetti> ah right.... that's the other one...
<mzanetti> will update
<mzanetti> thanks
<bzoltan2> cjwatson: I would need to add new milestones
<bzoltan2> cjwatson: and it seems that only Kaleo could do that, but he is nor really working on the project anymore
<cjwatson> bzoltan2: What have you tried?  The project driver should be able to do that.
<cjwatson> (= ~ubuntu-sdk-team)
<Mirv> bzoltan2: you seem to be admin of both https://launchpad.net/~pspmteam/+members and https://launchpad.net/~ubuntu-sdk-team/+members , so I cannot immediately see why you couldn't have "Create milestone" button on https://launchpad.net/ubuntu-ui-toolkit/trunk
<cjwatson> bzoltan2: If you don't, then I can (due to being in ~registry), but I believe you should be able to do it yourself.
<bzoltan2> cjwatson: \o/ cool... Me idiot I was looking for that button on the milestones page
<Mirv> psivaa: first .crash retraced https://bugs.launchpad.net/ubuntu/+source/mediascanner2/+bug/1376219
<ubot5> Ubuntu bug 1376219 in mediascanner2 (Ubuntu) "qmlscene crashed with SIGABRT in raise() in music_app" [Undecided,New]
 * Mirv afk, back later
<ogra_> brendand, what happened to the fix of phablet-click-test-setup ? would it be ready ?
<ogra_> (i just ran into it with the patest unity8 landing ... cant run the tests on latest utopic anymore)
<ogra_> *latest
<asac> sil off today?
<ogra_> asac, ge cracked his wrist
<ogra_> *he
<brendand> ogra_, it hasn't been merged yet: https://code.launchpad.net/~nskaggs/phablet-tools/fix-1371241-try2/+merge/236385
<asac> ogra_: ouch
<ogra_> brendand, yes, i was planning to do a clean up of the phablet-tools backlogs today (there are phablet-shell and demos-setup fixes too that could land together)
<bfiller> Mirv: ubuntu silo 1 and silo 9 are ready to be released, but they are not in sync with rows in spreadsheet. In fact there is no row in spreadsheet for silo 1 at all
<ogra_> brendand, heh, i think thats the wrong one :P
<brendand> ogra_, i wasn't aware of any other
<cjwatson> brendand: do you have an opinion on whether https://launchpad.net/ubuntu/+source/glibc/2.19-10ubuntu2 would need QA testing for ubuntu-rtm as well as dev testing?  The emulator doesn't seem to be broken on RTM right now, but it's a potential time-bomb that could be tripped by fairly innocent changes to other packages
<cjwatson> and grr, looks like I still need to poke at autopkgtests there
<ogra_> cjwatson, how hard would a rollback be ? we could just land it, have a full smoke tests and if needed roll it back
<cjwatson> ogra_: probably relatively straightforward at least if I'm around to do the right removes/copies
<ogra_> well, i'd do it that way then ... just let the automation catch potential issues and be prepared to roll back
<ogra_> but thats indeed time consuming
<cjwatson> I didn't think "just land and roll back if needed" was the approved philosophy for RTM though :P
<brendand> ogra_, what other change to phablet-click-test-setup?
* cprov changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cprov | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<ogra_> brendand, hmm, might actually be the right one ... i'm a bit irritated that everything is yellow on that page
<ogra_> brendand, yeah, applying that here helps ... i'll try to land it then
<brendand> cjwatson, yeah i think so
<bzoltan2> Mirv:  We have a cool UX fix in the line 88. It will take an hour or two to release it.
<om26er> cprov, Hi! the dashboard have results for calendar app, while its removed from the image. Is there a reason not to remove that from the dasboard ?
<cprov> om26er: perhaps there is a stray line in the spreadsheet, let me check
<cprov> om26er: do you mean the silo 9, right ?
<om26er> cprov, I didn't see the silo. I am talking about this dashboard http://ci.ubuntu.com/smokeng/utopic/touch/mako/264:20141001:20140929.1/10758/
<om26er> weather app is no longer in the image but its results are still there.
<cprov> om26er: oh, sorry, I was thinking about the train dashboard (biased, sorry).
<om26er> ;)
<cprov> om26er: let me check why it is still listed, I will come back to you.
<om26er> cprov, alright, thanks
<cprov> om26er: ubuntu_weather_app is a click package and is tested from the click-store based on a jenkins configuration file we control.
<cprov> om26er: that explains why it is being tested, even if it is not included in the image.
<popey> since when was it removed from the image?
<om26er> popey, last week I believe.
<popey> wat, no. calendar was removed.
<om26er> cprov, ok, I will talk to plars on that and see what we can do.
<cprov> om26er: np
<popey> om26er: http://people.canonical.com/~ogra/touch-image-stats/258.changes 258 had an update, i see no removal.
<om26er> popey, I don't see it on my phone
<popey> om26er: what device / channel / version ?
<om26er> I noticed it when the 'Upcoming event' menu stopped opening the calendar, first I thought that was a bug
<om26er> popey, image 264 - utopic-proposed
<popey> om26er: wait, you said _weather_
<popey> now you mention calendar.
<popey> I know calendar was removed. I'm asking about weather.
<om26er> I said calendar above.
<popey> 13:23:05 < om26er> weather app is no longer in the image but its results are still there.
<popey> no, you said weather
<om26er> popey, <om26er> cprov, Hi! the dashboard have results for calendar app, while its removed from the image. Is there a reason not to remove that from the dasboard ?
<om26er> seems the second time, even I forgot to call it calendar :D
<popey> heh
<popey> lolz â»
<cprov> om26er: oh, okay then
<ogra_> sergiusens, i'd like a top approval for https://code.launchpad.net/~ogra/phablet-tools/fix-phablet-shell-without-local-key/+merge/236696
<pstolowski> Mirv, hey, if it's not too late, can I squeeze one more MP for same project  into line #86, rather than create a new request?
<ycheng> trainguards help needed for landing
<dbarth> trainguards can i get a silo reconfig on utopic 14?
<dbarth> extra polish, but comes in 2 new branches
<ycheng> trainguards I have no permission for the spreadsheet, and jhodapp has help me to use silos 003
<ycheng> trainguards aha, I don't have the revision that I test it on.
<ycheng> trainguards maybe I should get the version and comes back
<pstolowski> trainguards, Mirv may I ask for reconfig of silo-004 (#86) - one more MP added?
 * Mirv back
* Ursinha changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: Ursinha | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<jhodapp> Mirv, what is ycheng-afk missing for landing utopic silo 3?
<ogra_> brendand, it is in line 90 ... just waiting for a signoff from sergiusens for one branch there
<Mirv> bfiller: 001 looks line line 39 with spreadsheet having lost the id.
<Mirv> bfiller: I've restored the id now
<Mirv> bfiller: so you an set it as tested as usual
<bfiller> Mirv: ok, line 63 marked as tested but not showing up as ready to publish
<Mirv> 009 funnily doesn't reflect the correct status in the spreadsheet
<Mirv> bfiller: yeah, we've had that before, no idea what's it's related to. thanks for pinging about that.
<Mirv> robru: another example: 1. assign silo 2. build 3. get https://ci-train.ubuntu.com/job/ubuntu-landing-006-1-build/52/console
<Mirv> bzoltan2: building at https://ci-train.ubuntu.com/job/ubuntu-landing-006-1-build/53/console
<Mirv> pstolowski: sure you can
<Mirv> pstolowski: you just need to ask for a reconfig after you've added it
<pstolowski> Mirv, great, thanks. yeah, i updated and asked a few irc lines later ;)
<Mirv> pstolowski: I'm just getting there :)
<Mirv> pstolowski: dbarth: reconfig requests done.
<Mirv> ycheng-afk: jhodapp: so qtubuntu-camera on utopic?
<jhodapp> Mirv, yeah
<Mirv> ycheng-afk: jhodapp: I'm not sure how, but there's the silo, and no line for it whatsoever
<jhodapp> Mirv, yeah me neither...it landed in RTM already
<jhodapp> Mirv, we just need it to sync and land in utopic now
<pstolowski> Mirv, grr, i think i hit ctrl+z one time too many and removed that change a few minutes ago; just added it back, sorry for that :(
<Mirv> ycheng-afk: jhodapp: the silo 003 has version 20140918 of qtubuntu-camera, while both utopic and rtm already have 20140924. so at the very least, the current contents of silo 003 seem obsolete and the silo should be freed, plus a new line added for any new landing
<dbarth> thank you sir!
<dbarth> :)
<sergiusens> ogra_: what is it waiting for me again?
<pstolowski> Mirv, can you re-config one more time please?
<sergiusens> ogra_: ssh key and shell
<sergiusens> ?
<ycheng> Mirv: jhodapp I have no permission for the spreadsheet, what I should do now ?
<jhodapp> Mirv, sounds reasonable
<Mirv> pstolowski: done!
<jhodapp> Mirv, do we need a new empty MR then or something?
<ogra_> sergiusens, yeah
<sergiusens> ogra_: if I run that twice, won't it fail to check properly?
<pstolowski> Mirv, thanks!
<Mirv> ycheng: jhodapp: so just to be precise, the current silo comments are what landed in rtm at https://lists.canonical.com/archives/rtm-14.09-changes/2014-September/000438.html and to utopic as part of the _next_ upload (from trunk) at https://lists.canonical.com/archives/utopic-changes/2014-September/010654.html
<sergiusens> ogra_: as you have an mkdir in there
<ogra_> sergiusens, not if you did what it asked for
<Mirv> ycheng: jhodapp: if you are only worried about the silo contents getting to utopic + rtm, there's nothing to be done
<ogra_> sergiusens, yes, because known_hosts needs to exist
<sergiusens> ogra_: well, consider that you run lots of phablet-shell instances and miss the first notice
<jhodapp> Mirv, oh so both already have the MR then is what you're saying?
<Mirv> ycheng: jhodapp: so what happened is that your utopic landing didn't happen, but the next landing did and it included both the "fix bug on use the lowest resolution instead of highest one" and the "Ensure androidControl is valid before using it to change exposure settings" since it was built from https://code.launchpad.net/~phablet-team/qtubuntu-camera/trunk
<Mirv> jhodapp: yes.
<ogra_> sergiusens, i wouldnt call that the typical use case (i would also not expect a developer to not own a ssh key indeed)
<Mirv> so, I'll just free up that silo
<ogra_> sergiusens, if you run it a second time it wuill fail with a key error
<jhodapp> Mirv, oh excellent, so this can just be freed then and ycheng's landing is done
<ogra_> sergiusens, but at least it tells you the first time what to do
<jhodapp> ycheng, seems there's nothing for you to do now :)
<Mirv> ycheng: all done already, thank you! ;)
<jhodapp> thanks Mirv
<sergiusens> ogra_: exit 1 then I guess would be better, wouldn't it?
<ycheng> Mirv, jhodapp: I'll de-assign me on that issue, thanks !
<ycheng> Mirv, jhodapp: hmm, I can wait for it's landing and then de-assigned myself.
<ogra_> sergiusens, well, if anyone checks the exist status i assume yes :)
<ogra_> let me fix that
<jhodapp> ycheng, it has already landed, you don't have to do anything
<Mirv> ycheng: the silo ^ was freed, it has landed and nothing more needs to be done
<ycheng> jhodapp: aha, ack, thanks
<jhodapp> ycheng, Mirv will remove the line from the spreadsheet
<Mirv> jhodapp: thanks
<ycheng> jhodapp: Mirv got it.
<ogra_> sergiusens, exit 1 pushed
<thostr_> Mirv: what is now with line 69?
<thostr_> Mirv: I don't see the conflict as the "conflict" is said to have landed?
<Mirv> bregma: ^ ignore. triggered wrong silo, aborted, running watch_only build to get the existing status back.
<Mirv> thostr_: it was a conflict, not anymore, now assigning a silo
<thostr_> Mirv: thanks
 * Mirv reaches EODish soon, sil2100 is away today and robert will be here in 2h. I've some errands to run.
<ogra_> sergiusens, i changed the MP a bit more now ... please take another look if you have time
<thostr_> Mirv: was the package in rtm silo 22 actually built? or just the utopic one copied because build was hit too quickly?
<cwayne> jdstrand: it just occurred to me, the cache is going to appear broken until we have an rtm rootfs with the new apparmor-easyprof
<jdstrand> cwayne: I don't understand
<jdstrand> cwayne: do you mean apparmor-easyprof-ubuntu? (apparmor-easyprof is a different package)
<jdstrand> cwayne: assuming you meant apparmor-easyprof-ubuntu, yes, you would not want to push your custom tarball until the krillin image has 1.2.30
<jdstrand> s/krillin image/krillin rootfs/
<jdstrand> (which is what I was getting at earlier on deferring to you on the timing of server side stuff)
<cwayne> right, sorry, I know they're different packages, I'm just lazy I guess
<cwayne> jdstrand: right, well it's that + we needed it in the archive to build the new custom tarball anyway
<jdstrand> right, and you need it in the archive to build the rootfs
<mzanetti> trainguards: please reconfig silo 7 once more
<mzanetti> had to add a qtubuntu-gles-sync
<cwayne> ogra_: any idea when we might expect a new rtm rootfs?
<ogra_> cwayne, 3am UTC
<cwayne> :/
<cwayne> davmor2: so i guess custom is off again til tomorrow :)
<ogra_> cwayne, well, if needed we can indeed just build one
<cwayne> ogra_: is there anything else that would prevent us from doing a build?  it's not super-duper-critical, but it'd definitely be good to have this in today
<rsalveti> cjwatson: is there anything we can do to unblock glibc from proposed?
<rsalveti> it seems the failed test cases were always failing
<ogra_> cwayne, well, we just need to make sure everything is in the archive before we start the build
<cjwatson> rsalveti: yes I'm working on it, no they weren't always failing
<ogra_> theer are two new ones
<rsalveti> at least from the jenkins jobs most of them had failures before that, but might be my impression
<rsalveti> cjwatson: but cool, thanks
<ogra_> most of them are overridden though
<cjwatson> the two remaining started failing quite recently
<cjwatson> I need to make sure they have nothing to do with glibc before forcing anything
<rsalveti> yeah
<cwayne> ogra_: ack, the only thing needed from my end would be apparmor-easyprof-ubuntu version 1.2.30
<ogra_> cwayne, ok, rmadison says it is in both archives
<ogra_> i'm in a meeting atm but will trigger an image then
<cwayne> ogra_: thanks
<cwayne> davmor2: would you be able to test custom after that ^ or would it be too late
<davmor2> cwayne: yeap sure
* plars changed the topic of #ubuntu-ci-eng to:  Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: plars | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<balloons> ogra_, can you approve and push in with the next release of phablet-tools? https://code.launchpad.net/~nskaggs/phablet-tools/fix-1371241-try2/+merge/236385
<ogra_> balloons, see line 90 on the spreadsheet :)
<balloons> ogra_, :-)
<ogra_> balloons, i'm landing three MPs, but one is waiting for signoff ( sergiusens took a look but didnt sign off yet)
<ogra_> i'm confident i can land this within the next hours though ....
<ogra_> (i really needed your fix today here(
<balloons> ogra_, same, I ran into the issue again and it reminded me
<ogra_> sergiusens, ^^^ can i have that phablet-shell MP approved ?
<sergiusens> ogra_: well I didn't test yet
 * sergiusens doesn't approve without testing
<ogra_> ok
<mzanetti> anyone here with powers to reconfig silo7?
<ogra_> mzanetti, robru should be up soon
<mzanetti> ah, great
<cwayne> ogra_: has a build been kicked?
<cjwatson> mzanetti: doing
<ogra_> cwayne, yes, bot should announce it in a moment
<cwayne> ogra_: awesome, thank you :)
<mzanetti> cjwatson: thanks
<imgbot> === trainguards: RTM IMAGE 76 building (started: 20141001 16:00) ===
<davmor2> ogra_: just waiting to see if it updates the issues tracker but it is here https://bugs.launchpad.net/ubuntu-keyboard/+bug/1376337 there are also a couple of sound-indicator issues that should probably be tagged but not blockers
<ubot5> Ubuntu bug 1376337 in ubuntu-keyboard "Spellcheck holds a single word reply in messaging indicator" [Undecided,New]
<Mirv> bfiller: not approved https://code.launchpad.net/~renatofilho/address-book-app/release-30-09-2014/+merge/236630
<kgunn> fginther: hey, so, let's say for a silo we'd like to run our ui tests on unity, would there be a way to either a) automagically have these run? or b) is there a way to check out the source from a built silo to manually run them ?
<kgunn> fginther: details would be to  ./build.sh, cd builddir, make check (which includes make test and make qmltests)
<kgunn> we just keep chasing our tail on landing 1 or 2 broken ui tests
<bfiller> Mirv: fixed
<fginther> kgunn, can we discuss this later this afternoon (I've got a few meetings first)?
<fginther> kgunn, it's sounds possible, but I want to make sure I understand the whole picture first
<kgunn> fginther: sure...
<kgunn> yep
<ogra_> davmor2, http://people.canonical.com/~lzemczak/issues/ looks great, thanks
<davmor2> ogra_: there is more yet
<ogra_> add away :)
<popey> ogra_: i am seeing a bit of memory leaking in unity8-dash with a lot of scopes enabled...http://paste.ubuntu.com/8473625/
<popey> is there a bug for that already?
<kgunn> popey: we did fix one recently
<popey> ok. i have 11 open
<kgunn> popey: but it might be different...
<popey> started monitoring memory and haven't touched the device since. it's sat unlocked
<popey> (odd it's not locking itself)
<kgunn> popey: not sure if you can easily tell if this https://code.launchpad.net/~albaguirre/platform-api/fix-1206146
<kgunn> is in the image you're on
<kgunn> ...things taking longer to hit rtm branch it's hard to say
<imgbot> === trainguards: RTM IMAGE 76 DONE (finished: 20141001 17:05) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/76.changes ===
<ogra_> cwayne, ^^^ enjoy
<sil2100> davmor2: hey! I heard you found a regression in our last promoted image - do you have a bug handsy?
<davmor2> sil2100: they should be in the issues tracker
<davmor2> sil2100: I'm still looking through the image currently though
<ogra_> is LP timing out for anyone else ?
<dobey> ogra_: it is a bit yes
<dobey> well, bug page loaded fine, but my MP timed out
<ogra_> right
<ogra_> same here
<sil2100> davmor2: btw. are those blockers for next promotion?
<ogra_> sil2100, they are in the last promoted image ...
<bzoltan1> brendand: I have started the validation of the UITK release candidate from the RTM silo14. I see thatthe Unity tests still hang. Is there a special trick i could see the same results as on the CI Dash?
<brendand> plars, should the unity8 tests still hang?
<ogra_> no
<ogra_> they never hung in rtm
<cwayne> davmor2: latest custom is available for testing (ubuntu-touch/ubuntu-rtm/14.09-proposed-customized)
<cwayne> sil2100: ^
<sil2100> Excellent
<ogra_> brendand, bzoltan1 http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/75:20141001:20140929-d974fdc/503/
<sil2100> davmor2: how long does the custom tarball testing take for you?
<ogra_> there were unity8 failures today ... but it surely ran
<ogra_> (and finished)
<plars> bregma: where did you see it hang?
<ogra_> plars, i think they are referring to the media-hub/gstreamer/whatever hang we had on utopic for a while
<bzoltan1> ogra_: All right, fingers crossed that I will see the same results with my re-run
<ogra_> bah
<ogra_>  1907 root      20   0   81652   4748   4748 S  99,3  0,5  13:02.57 ubuntu-location
<ogra_> lool, didnt you land a fix for that ?
<ogra_> wow
 * ogra_ has a black screen with panel after unlocking on image 76
<ogra_> (and location service eating 100%)
<ogra_> apps dont start anymore
<ogra_> showing an eternal splash
 * ogra_ reboots, this is unusable :(
<cwayne> davmor2: sil2100: just for claiification, the custom tarball needing testing is 1412208333 (can be found by running cat /custom/build_id)
<cwayne> i've got to run a quick errand, will brb to see if everything's going ok
<ogra_> cwayne, could we sync that versioning with something ubuntu-ish at some point ?
<cwayne> ogra_: i thought of that, but unsure how system-image server works (i.e. does it care about the version number or just the timestamps)
<ogra_> cwayne, that i dont know ... but having something like YYYYMMDD.N-$STAMP would be more in line with all other versioning we use
<cwayne> ogra_: i'll poke around, i would definitely like to change it to something more meaningful
<cwayne> we need the build_id still because it tells whether or not we do a dconf update, but i dont think it should be used as the version number
<ogra_> cwayne, talk to stgraber what s-i supports
<bzoltan1> ogra_:  do you have a trick for silencing that device from adb shell? Not as I would not enjoy the music app's tests at 3am :) But am not sure if my family shares my passion to nightly tests.
<ogra_> audio you mean ?
<ogra_> hmm, no
<ogra_> bzoltan1, you could try something like: amixer -D pulse set Master 1+ mute
<ogra_> no idea if that would work though
<ogra_> probably rsalveti knows another way
<bzoltan1> ogra_: thanks, I will test it
<davmor2> sil2100: sorry just got back from tea
<davmor2> sil2100: So I think they will become blockers if they are not fix in the next 7 days but currently shouldn't blocker as it technically isn't a regression but are so user facing that they need fixing if that makes sense
<davmor2> sil2100: custom tarball changes depending on what is landing but an hour or 2
<lool> ogra_: no, we don't have a repro for the 100% location-service CPU usage
<ogra_> ok
<lool> ogra_: brendand might have filed it, haven't seen it yet
<lool> will look after dinner
<ogra_> lool, well, it is gone again after reboot
<ogra_> and i havent noticed it ever before
<sil2100> davmor2: btw. will you be able to take a look at utopic mako tomorrow? Since maybe we'll be able to promote a new image for that channel at least
<sil2100> Sicne I guess the mediascanner scope issue seems to be fixed
<davmor2> sil2100: I can once I get to the box that has my mako flo and manta in ;)
<dbarth> hi trainguards, can i get a sync for silo utopic 14?
<dbarth> i need it to populate line 54 for rtm
<robru> dbarth: ok you got rtm4
<dbarth> thank you
<robru> you're welcome
<dbarth> hey, btw, pitti did what's needed to get the langpacks up to date on rtm
<robru> dbarth: oh cool, so you should be able to just rebuild oxide and have it work? or maybe rebuild isn't even needed
<dbarth> so that last bug will get fixed on friday
<dbarth> a rebuild is not needed
<robru> even better
<dbarth> right
<infinity> camako: Can you give more details on the code that "requires a newer kernel"?
<infinity> camako: If it's just a test that can't pass without a newer kernel present, it's fine to conditionally skip that on older kernels.  If it's that your package literally doesn't work with older kernels, that might be a bug on your end, IMO.
<infinity> camako: It's generally sane to try to keep things working in a state where they can work in a chroot on top of our oldest supported LTS kernel.
<dbarth> robru: and utopic14 is good for publishing
<camako> infinity, thanks for the comments ...
<camako> infinity, this is for Mir desktop
<camako> and we are ok not supporting kernels older than 3.11
<camako> where this kernel feature we depend on was introduced
<camako> Since mir on the desktop won't be ready for a while
<infinity> camako: Right, that's perhaps a fair decision to make.
<robru> dbarth: https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/38/console please approve your merges
<infinity> camako: It won't prompt us to run around and upgrad the buildds in a hurry, though, so you might want to conditionally skip the test, and work out an alternate testing scenario (ie: build with tests enabled in a virt PPA, which are all 3.13 now).
<camako> infinity, yea we discussed this during the review process... So how do you bypass a failing test on an old kernel?
<infinity> camako: The test itself should check the running kernel version before attempting to run.
<camako> infinity, oh ok...
<cjwatson> Have a helper function that tests uname(2) or something
<camako> sure, I'll look into that
<cjwatson> Or, better, check for availability of the actual kernel feature you're using
<cjwatson> Testing kernel version numbers is generally a last resort and not usually a good idea
<infinity> Yeah, what he said.
<infinity> Testing the feature availability (is it a syscall?) is the sanest route.
<camako> cjwatson, yes I believe that would be quite straightforward
<cjwatson> Cool
<camako> it's just a flag passed to open
<camako> O_TMPFILE
<cjwatson> infinity: Do you know if we have a policy issue with upgrading buildds to trusty?
<cjwatson> I know there's a general thing about "don't upgrade metal to trusty, switch to the cloud", but we know that full conversion of buildds to the cloud is (a) in progress and (b) blocked for a while ...
<infinity> cjwatson: So, yes, there's the "don't upgrade metal" issue, but I think elmo and I have already discussed that buildds are a unique snowflake there.
<cjwatson> k
<infinity> cjwatson: I also am personally annoyed that "the cloud" must mean openstack, as the buildds are ALREADY a cloud and, in fact, the oldest cloud in Canonical. :P
<cjwatson> Yeah, not maybe as horizontally scalable as we might like but indeed
<cjwatson> We should probably try to figure out who's working on scalingstack/{power,arm}
<cjwatson> If anyone
<infinity> cjwatson: So, yeah, the only blocker for upgrading to trusty on x86 is time and a ticket, but I've been in no rush because powerpc has a kernel bug to hunt before we can upgrade, and armhf is just going to have the hardware replaced instead of upgraded.
<cjwatson> So maybe midway armhf can just be installed fresh with trusty (it might have to be anyway), and that'll take care of most of mir's needs
<infinity> cjwatson: But I also don't see any factors other than dogfooding that should force the issue either.
<infinity> cjwatson: And the dogfooding argument should usually happen before an LTS releases, not after. ;)
<infinity> cjwatson: Yeah, the midways will be tusty from day 1.
<infinity> But Mir builds places other than armhf, so the kernel feature testing before running the test thing will be required regardless.
<infinity> And is also the right way to do it.
<cjwatson> Yep
<infinity> Assuming that build environment == runtime environment is pretty much universally wrong, IMO.
<infinity> camako: Oh, there are reasons other than kernel version to test O_TMPFILE anyway (and, maybe a good argument to have a forked path in your code, not your testsuite).
<infinity> camako: It's not supported on all filesystems.
<infinity> camako: So, if this code was running on, say, btrfs, it would explode, even if on a current kernel.
<camako> infinity, good point
<cjwatson> Yeah, that gets more delicate, you have to make sure your test runs against a file on the relevant fs
<infinity> camako: Not sure how one determines this without an expensive try;fail;fall-back, though. :/
<cjwatson> You can probably cache it for each fs
<davmor2> sil2100, cwayne: I'm not getting a location so I checked the /var/crash folder crashes for trust-store and location ouch
<davmor2> not sure if that it the custom image fault or the app-armor update
<cjwatson> using statvfs().f_fsid or something
<infinity> cjwatson: Well, it depends on how often the flag is passed to open(2) during runtime.  If it's frequent, it's worth a startup check to determine if the target FS will support it, then cache the result.
<cwayne> davmor2: there was 0 change in custom pertaining to either of those
<infinity> If it's a one-time thing, that's a huge performance hit with little gain, when you could just avoid the flag.
<cwayne> or anything related to HERE
<camako> we are opening /dev/shm... and it's a one-time thing
<infinity> camako: Ahh, if it's /dev/shm, you're safe.
<infinity> camako: That's guaranteed to support it (in newer kernels).
<cjwatson> ok, so just try O_TMPFILE and fall back if you get EINVAL
<infinity> camako: So, going back to "the testsuite can test this" rather than testing it in the code seems reasonable.
<cjwatson> (fall back => skip test, if you only want to cover this in the test suite)
<camako> indeed
<camako> thanks for your feedback guys.. appreciate it..
<davmor2> ev: I thought that previous errors was going to get a fix so that the error tracker showed the previous errors :(
<davmor2> sil2100: you might want to add tags to https://bugs.launchpad.net/unity8/+bug/1373312 and https://bugs.launchpad.net/unity8/+bug/1373313 too
<ubot5> Ubuntu bug 1373312 in Unity 8 "Phablet album art not coming through from media-hub" [High,Triaged]
<ubot5> Ubuntu bug 1373313 in Media Hub "Previous & New buttons not hooked up in indicator" [High,Triaged]
<sil2100> Oh?
<sil2100> New stuff!
<sil2100> davmor2: blockers?
<cjwatson> sil2100: your landing team mail said that emulator images were broken on the RTM channels - are you sure?  the breakage I'm aware of is only in devel-proposed
<cjwatson> (possibly devel)
<sil2100> cjwatson: someone mentioned to us that the emulator image we promoted for ubuntu-rtm was broken
<cjwatson> and I was able to use the emulator on ubuntu-rtm as of this morning
<cjwatson> well, ubuntu-rtm/14.09-proposed was fine today
<davmor2> sil2100: no user facing again but block in 7days if not fixed they got released in image 3 so not a regression
<sil2100> cjwatson: maybe it's fixed in -proposed, but ogra_ mentioned it being broken in ubuntu-rtm/14.09
<sil2100> davmor2: ACK
<cjwatson> mkay
* fginther changed the topic of #ubuntu-ci-eng to:  Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: fginther | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<cwayne> davmor2: so how's it look otherwise?
<cwayne> i need to disappear for an hour or so pretty soon, but ill be able to pop in to publish if needed
<davmor2> cwayne: so it is broken on 76 ToyKeeper just confirmed so it looks like this isn't an issue with custom, but it means any of the scope that need location don't actually get it
<ToyKeeper> I see a crash on boot for both.
<davmor2> jdstrand: I'm going to have a dig but I think there were only a couple of things land in image 76 and your app-armor was one :(
<cwayne> davmor2: right, but with 76 the scopes that need location won't get them anyway
<ToyKeeper> Yesterday one of the new default scopes did ask me to allow location permission...  couldn't tell if it worked though.
<cwayne> so no reason to block custom :)  main thing that changed is we set favorites (if the user has never set them) and we have a new cache to match jdstrand's upload
<cwayne> so if we block custom, it'll be back to like 5 minute boots on krillin :/
<davmor2> cwayne: which will mean that there should be a revert of the thing that broke it if that is app-armor we can't land custom either right
<cwayne> davmor2: are there any apparmor denials?
<davmor2> cwayne: only just started digging
<jdstrand> davmor2: apparmor-easyprof-ubuntu? what broke?
<jdstrand> I find it pretty unlikely that would've broken anything
<jdstrand> davmor2: are you talking about indicator-sound? that is confined so not affected by that upload
<jdstrand> err
<jdstrand> that is *not* confined
<davmor2> jdstrand: location and trust store started crashing on 76 only adb and app-armor changed
<jdstrand> location is also not confined by apparmor
<cwayne> i can't reproduce btw on 88
<jdstrand> davmor2: please do 'grep DEN /var/log/syslog' and paste the denials
<cwayne> well 14.09-proposed-customized 88
<davmor2> jdstrand: http://paste.ubuntu.com/8474451/
<cwayne> all those leaf-net ones are just noise
<rsalveti> bzoltan1: you can use the cmdline tools from pulse to mute the device
<rsalveti> don't use alsa
<jdstrand> com.canonical.scopes.timeout_timeout_0.4.10 is not using the connection api but trying to access network-manager directly
<jdstrand> that is a bug in that app
<bzoltan1> rsalveti:  you would not use `amixer -D pulse set Master 1+ mute`?
<bzoltan1> rsalveti: any better suggestion?
<rsalveti> pactl probably, let me check
<cwayne> jdstrand: would you mind logging a bug against hanloon?
<jdstrand> yelp is a bug in the scopes api-- it is trying to create a directory not specified in https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
<cwayne> that one has an upstream bug, i can try and find it
<jdstrand> it looked different to me
<jdstrand> cwayne: is hanloon for timeout?
<rsalveti> bzoltan1: pacmd set-sink-mute sink.primary 1
<davmor2> jdstrand: I can file the bugs if you can point me to what the denial is for
<cwayne> jdstrand: hanloon is for all the scopes in /custom, so yep
<jdstrand> oh it seems like a bunch of theme
<jdstrand> all network manager denials: bug #1376408
<ubot5> Error: Launchpad bug 1376408 could not be found
<cwayne> jdstrand: thank you
<cwayne> but thats also unrelated to davmor2's issue (and in fact none of thses scopes except news have even changed since the last custom tarball release)
<jdstrand> so, yelp should be using @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}, but it is using @{HOME}/.local/share/unity-scopes/@{APP_PKGNAME}_@{APP_APPNAME}
<jdstrand> that is a bug in yelp of the scopes api
<jdstrand> davmor2, cwayne: ^
<cwayne> jdstrand: yelp is only using what the scopes api is giving it
<cwayne> it could be specific to the go bindings maybe.. but all the scope itself does is call ScopeBase.ScopeDirectory()
<cwayne> jdstrand: but regardless I'll take a look and see what I can find
<jdstrand> then that is returning the wrong thing
<jdstrand> I can't seem to find the bug
<jdstrand> I thought there was one
<jdstrand> I'll file it
<davmor2> ToyKeeper: can you do grep DEN /var/log/syslog and see if it is similar to http://paste.ubuntu.com/8474451/ please I want to double check that they are not masses apart
<cwayne> davmor2: jdstrand: I've got to run for an hourish, please shoot me an email if theres any ?'s, but it really seems like whatever is causing location-service to crash is unrelated (and I can't for the life of me reproduce)
<ToyKeeper> davmor2: http://paste.ubuntu.com/8474560/
<robru> ted: do you have any idea what that error meant? wtf?
<ted> robru, No, I built the package locally just to be sure. But no.
<davmor2> jdstrand, cwayne: so ToyKeeper 's result is looking pretty similar to the one I pasted but nothing obvious, I'll keep digging in errors to see if I can see the faults that were filed there
<ted> robru, Restarting the build I think it's going find nowâ¦
<robru> ted: messed up
<jdstrand> cwayne, davmor2: bug #1376416 for yelp
<ubot5> bug 1376416 in unity-scopes-api (Ubuntu) "apparmor denial for yelp" [High,New] https://launchpad.net/bugs/1376416
<jdstrand> that leaves two denials:
<jdstrand> Oct  1 18:14:46 ubuntu-phablet kernel: [  232.213753] (1)[9350:scoperunner]type=1400 audit(1412187286.501:143): apparmor="DENIED" operation="open" profile="com.canonical.scopes.timeout_timeout_0.4.10" name="/android/system/lib/libGLESv2.so" pid=9350 comm="scoperunner" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
<jdstrand> Oct  1 18:14:46 ubuntu-phablet kernel: [  232.395523] (0)[9388:com.ubuntu.yelp]type=1400 audit(1412187286.681:145): apparmor="DENIED" operation="mkdir" profile="com.ubuntu.yelp_yelp_1.0.26" name="/home/phablet/.local/share/unity-scopes/com.ubuntu.yelp_yelp/" pid=9388 comm="com.ubuntu.yelp" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
<jdstrand> Oct  1 18:45:47 ubuntu-phablet kernel: [ 2093.373992] (0)[25723:webapp-containe]type=1400 audit(1412189147.661:151): apparmor="DENIED" operation="open" profile="com.nokia.heremaps_here_1.0.1" name="/custom/etc/dconf_profile" pid=25723 comm="webapp-containe" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
<jdstrand> whoops
<jdstrand> Oct  1 18:14:46 ubuntu-phablet kernel: [  232.213753] (1)[9350:scoperunner]type=1400 audit(1412187286.501:143): apparmor="DENIED" operation="open" profile="com.canonical.scopes.timeout_timeout_0.4.10" name="/android/system/lib/libGLESv2.so" pid=9350 comm="scoperunner" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
<jdstrand> both of these are due to changes outside of apparmor-easyprof-ubuntu
<jdstrand> davmor2: these are also not related to location service
<davmor2> jdstrand: https://errors.ubuntu.com/problem/361a1c5dde22e0ce444d9aaa23180449a7a52446 could be this fault which looks like it started on utopic yesterday
<jdstrand> it is getting a little frustrating seeing new denials that no one is reporting
<jdstrand> cwayne: so, apps aren't supposed to be using dconf
<jdstrand> cwayne: do you know what /custom/etc/dconf_profile is about with the here app?
<davmor2> jdstrand: I can run grep DEN /var/log/syslog once a day for you and email to you if you want?
<jdstrand> davmor2: that could be helpful. I'd really like to see this automated though in the ci infrastructure...
<jdstrand> ie, so that things are blocked if they introduce new denials
<davmor2> jdstrand: that would be the ultimate in awesome :)
<jdstrand> :)
<davmor2> hey ogra_ plars would it be possible to make that happen and maybe add the result to the image results? ^  ie run grep DEN /var/log/syslog and initially just store the output on the image results?
<davmor2> eventually have it go green if there are none and red if there is :)
<plars> davmor2: jdstrand: is this not covered by the /home/phablet/bin/check-clickhook-rules check that we added before?
<davmor2> plars: no idea
<plars> davmor2: also, is there any possibility that a test (like security tests) could throw a false positive here?
<cjwatson> rsalveti: looks like the last unforced autopkgtest (aria2) is passing locally for me - just double-checking that and then I'll force-skiptest glibc
<rsalveti> cjwatson: great, thanks
<cjwatson> rsalveti: thanks for poking zodb earlier
<cjwatson> hate these flaky tests
<rsalveti> np
<rsalveti> yeah
<davmor2> plars: possibly
<davmor2> night all, cwayne I'll take another look in the morning but I just ran out of day trying to figure out why location is dying
<jdstrand> plars: what project is that in again?
<jdstrand> plars: security tests would totally throw false positives (thousands of them)
<brendand> mvo_, are you around?
<brendand> mvo_, there's an issue with the rtm silo for click
<jdstrand> plars: I think we would just want to block on apps suddenly geteting new denials
<brendand> cjwatson, ^
<brendand> cjwatson, actually it's your name next to the test results
<plars> jdstrand: we don't really have a way to inspect history while running the test
<jdstrand> plars: at least as a start. apps are what are confined, and they use the services via their autopilot tests, etc
<cjwatson> brendand: what is it?  I'm only around for a few more minutes and I suspect mvo has finished for the day
<jdstrand> it could be after
<cjwatson> (and I'm on vac tomorrow)
<brendand> cjwatson, it seems the 'stop apps when uninstalling' fix doesn't work
<cjwatson> brendand: yes I already reopened the bug
<jdstrand> you'd just need to filter out denials prior to test start
<cjwatson> brendand: it's fine as long as it hasn't actually made things any worse (which AFAIK it hasn't)
<cjwatson> it fails because it removes the registration link before trying to stop the app, so can't get its manifest
<cjwatson> brendand: see end of https://bugs.launchpad.net/ubuntu/+source/click/+bug/1232130
<ubot5> Ubuntu bug 1232130 in click (Ubuntu) "Uninstalling an app doesn't stop it" [Medium,Triaged]
<cjwatson> brendand: I don't think this should block landing though - it didn't stop it before and it doesn't stop it now, but it also doesn't break app removal
<brendand> cjwatson, alright i'll take that into account
<cjwatson> we should absolutely fix it up properly in the next landing though
<cjwatson> brendand: I'm glad to see QA noticed this too though! :-)  Sorry, I should've mentioned it in the spreadsheet to save on worry
<mvo_> brendand, cjwatson: thanks, I will work on a fix tomorrow
<mvo_> (and will also find out why the test did not fail for this :/)
<cjwatson> mvo_: because you happened to pick a package name to remove that exists in two database layers, so .remove just removes it from the top one, maybe?  though that should've caused the version to be wrong
<cjwatson> hopefully it's shallow-ish anyway
<mvo_> cjwatson: right, I check it out
<cjwatson> thanks
<cjwatson> rsalveti: glibc forced
<cwayne> davmor2: so what's the verdict?
<cwayne> ah nm sorry davmor2 I'd missed your message earlier, tomorrow's good
<robru> bfiller: you got rtm9
* fginther changed the topic of #ubuntu-ci-eng to:  Need a silo? Ping train support: trainguards | Need other help? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<rsalveti> slangasek: may I ask some help to approve pulseaudio and indicator-sound? so we can completely land silo 18
<slangasek> rsalveti: ok. is there a bug open / patch to review?
<slangasek> hmm I suppose clicking through the silo will take me to the diffs
<rsalveti> slangasek: the main bug is https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1368827
<ubot5> Ubuntu bug 1368827 in indicator-sound (Ubuntu) "[touch] indicator needs to be able to control volume per audio role" [Critical,In progress]
<slangasek> ah, but maybe not for pulseaudio
<slangasek> ok
<rsalveti> pulse changes are just bugfixes
<rsalveti> and also only relevant to touch
<rsalveti> the main one that adds a bit more logic is indicator-sound, but also for touch
<rsalveti> slangasek: I though we had a FFe for it, but saw that it was not included at bug 1371635
<ubot5> bug 1371635 in Ubuntu "[FFe] standing freeze exception in utopic for Ubuntu Touch-specific packages" [Undecided,Triaged] https://launchpad.net/bugs/1371635
<rsalveti> so my mistake for trying to push it before checking that properly
<rsalveti> I added one comment to add indicator-sound to the list of packages
<slangasek> right, I responded there - basically, it's not included because the package isn't touch-specific
<rsalveti> oh, you already replied
<slangasek> doesn't mean it shouldn't go in, but it means we should be extra careful that it doesn't regress non-touch stuff
<rsalveti> oh, right, similar to the other indicators in there I guess
<rsalveti> let me check
<rsalveti> you're right, the other indicators in there are common to the desktop
<rsalveti> sorry, not common
<rsalveti> slangasek: want me to open a separated bug for this package?
<slangasek> no, we can use the existing bug report
<rsalveti> slangasek: updated bug
<rsalveti> argh
<rsalveti> bug 1368827
<ubot5> bug 1368827 in indicator-sound (Ubuntu) "[FFe] [touch] indicator needs to be able to control volume per audio role" [Critical,New] https://launchpad.net/bugs/1368827
<rsalveti> what is wrong with my copy & paste
<robru> bfiller: rtm12
<bfiller> robru: fast service today :) thanks!
<robru> bfiller: you're welcome!
<robru> bfiller: just a heads up, if you change your MPs and need a reconfigure, the button for that moved off the dashboard and into the spreadsheet. I'll make a public announcement about this soon but I'm still ironing out some bugs here
<bfiller> robru: thanks for the heads up
<slangasek> rsalveti: so the idea here is that the sink-input-by-media-role:$foo are only present if we're on touch?
<rsalveti> slangasek: they can be part of the desktop, but the dbus module that export that interface to the indicator is only available on touch
<rsalveti> the stream can have basically any role, as the app is responsible for setting that up, we just have a small set of supported ones on touch
<rsalveti> and this additional work was to enable this extra dbus interface so it can be used to change volume per roles
<rsalveti> so if the dbus interface and the needed roles are not available in the stream-restore internal database, it'll act like today (only controlling the main sink)
<rsalveti> if the dbus interface is available, and the required set of roles are available in stream-restore, then the volume will reflect on the current active role (or alert by default)
<slangasek> ok. what package provides this new dbus interface?
<rsalveti> slangasek: pulse itself, but that's disabled by default, and the config enabling that is part of ubuntu-touch-session
<rsalveti> we have a separated pulse audio config for touch
<rsalveti> the pulse changes are just basically to fix that use case (like preloading volume per roles, which was broken)
<rsalveti> I'm also sending both pulse patches upstream as we speak
<slangasek> rsalveti: ok, FFe approved, and indicated this in the bug log
<rsalveti> slangasek: great, thanks so much
<rsalveti> great, glibc also migrated, next image should make the x86 emulator to work again
<rsalveti> slangasek: ok, both pulseaudio patches were sent upstream, will update the package later on once they get accepted
#ubuntu-ci-eng 2014-10-02
<robru> Queuebot, nooooooooooooo
<bfiller> robru: I need a silo for line 94 please
<bzoltan1> rsalveti: I used to use the `gdbus call --session --dest com.canonical.UnityGreeter --object-path  --method com.canonical.UnityGreeter.HideGreeter|grep -v '\(\)'` to hide the greeter... it does not seem to do the job. Do you know what should I use instead?
<rsalveti> bzoltan1: hm, no idea, mterry might know
<bzoltan1> rsalveti: he is not around. ogra_ gave me this line... I need to unlock the screen and kill the greeter after resets between AP tests
<rsalveti> robru: any idea ^?
<bzoltan1> rsalveti:  the best kept secret of the CI :) is how the CI dash does things ... I am positive that nobody is unlocking the screen and typing passcodes manually there :) So there is a CI approved way to do. It would be cool to share those lines with the pubic.
<rsalveti> bzoltan1: yeah, I know ogra_ was involved with that, maybe plars has any idea
<bzoltan1> rsalveti:  for me that shell function used to work -> http://pastebin.ubuntu.com/8476271/ But not anymore.
<plars> bzoltan1: rsalveti: you want to use /usr/share/unity8/unlock-device from unity8-autopilot
<plars> it's made to be pulled onto the adb host and run from there
<plars> otherwise, if you just want the dbus call, you should be able to run:
<plars> adb shell "gdbus call --session --dest com.canonical.UnityGreeter --object-path / --method com.canonical.UnityGreeter.HideGreeter && echo Greeter unlocked"
<bzoltan1> plars: Thanks I prefer the dbus call... I do my own reboots :)
<plars> bzoltan1: actually, that looks the same as what you were running I think
<plars> bzoltan1: we have seen it fail a few times if it's done too soon, what's it returning for you?
<bzoltan1> plars:  it looks similar to my script, but it is not the same
<bzoltan1> plars: I would not use the `adb reboot; sleep 5; adb wait-for-device`
<bzoltan1> plars:  that is unreliable...
<plars> bzoltan1: the sleep is more than enough to ensure that we don't return from wait-for-device before the reboot
<plars> bzoltan1: or were you referring to something else?
<bzoltan1> plars: sometomes... but 10 sec is safer
<plars> bzoltan1: I've never seen that part of it fail so far, really we could probably even get away with less
<plars> bzoltan1: the part we have problems with is that if it fires too soon after boot, sometimes it can't make the dbus call yet
<bzoltan1> plars:  I run my reset like 100-200 times a day when I do... weekly.
<plars> bzoltan1: mterry just landed a change that loops it a few times if it fails though
<bzoltan1> plars: I think I stick to my script with the right dbus call :)
<plars> bzoltan1: feel free to propose an improvement to it if you have something that works better :)
<bzoltan1> plars:  according to my experience there is no sure way... I have to tune my script  every week.
<bzoltan1> plars:  Things change all over without much notice and tools fail without any meaningful error... so it is a continuous fight :)
<bzoltan1> plars:  so that dbus call takes away the Greeter. But does it take away the password lock too?
<plars> bzoltan1: yes
<bzoltan1> plars:  cool, thank you
<imgbot> === trainguards: IMAGE 265 building (started: 20141002 02:10) ===
<bzoltan1> plars:  I am still lobbying :) for releasing the CI validation tools via the CI train to the archive. Make it pass all the QA standard what other packages pass and offer a tool what developers can apt-get install and use
<plars> bzoltan1: that script is part of unity8 - it already goes through the landing process same as everything else
<robru> rsalveti: sorry nope, i just do train stuff, dunno about messy device stuff like greeters ;-)
<robru> bfiller: utopic 2
<imgbot> === trainguards: RTM IMAGE 77 building (started: 20141002 03:10) ===
<bzoltan1> robru: the clock app fails with the stock RTM image but all green on the CI dash.
<bzoltan1> robru:  also the dialer_app tests are flaky
<rsalveti> robru: just configured silo 8 and can't build: https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/82/console
<robru> rsalveti: weird. click IGNORE_STEP for now
<robru> bzoltan1: no idea
<robru> rsalveti: hm that's odd... still digging
<rsalveti> robru: hm, also failed
<robru> rsalveti: the thing is I just refactored that code, and now it makes no sense to me. I need to review the old code to see how badly I broke it i guess.
<rsalveti> but differently
<robru> rsalveti: that one's a legitimate failure though, isn't it? ;-)
<rsalveti> oh, need to put force rebuild
<robru> rsalveti: well wait
<robru> rsalveti: the trunk branch is really missing that revision from distro.
<robru> rsalveti: make sure you check that before you just wantonly revert it
<rsalveti> robru: yup, no worries, that is as expected
<rsalveti> not landing this until my other landing migrates properly
<robru> rsalveti: right http://launchpadlibrarian.net/186327488/ubuntu-touch-session_0.108%2B14.10.20140926.1-0ubuntu1_0.108%2B14.10.20140929-0ubuntu1.diff.gz you need to push this to trunk ;-)
<rsalveti> robru: can't yet because it's waiting on another silo to be cleaned
<rsalveti> guess I can actually
<rsalveti> but the clean step from the other silo might fail
<rsalveti> which is fine I guess
<robru> rsalveti: why would the clean step fail? wouldn't it just merge the branch?
<rsalveti> robru: migration is blocked as pulse still needs to be accepted
<rsalveti> I just wanted to go ahead and start my other landing, but yeah, the changelog entry is still missing until the other silo gets merged
<rsalveti> let me try something different
<robru> ah
<imgbot> === trainguards: IMAGE 265 DONE (finished: 20141002 04:00) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/265.changes ===
<Mirv> morning
<robru> Mirv: morning!
<Ursinha> man, "morning" means I should go to bed :)
<robru> Ursinha: haha. it sure means I shouldn't be working... not quite bedtime though
<Mirv> rsalveti: if you're still there, you could possibly ack this addition of a single symbol to platform-api: https://ci-train.ubuntu.com/job/ubuntu-landing-007-2-publish/lastSuccessfulBuild/artifact/packaging_changes_platform-api_2.5.0+14.10.20141001.3-0ubuntu1.diff
<bzoltan1> Wow, I got full OK from the gallery tests with the UITK silo.
<Mirv> bzoltan1: it's been some time since I've seen full OK from gallery locally..
<Mirv> nice
<bzoltan1> Mirv:  yes, I am surprised too :D The UITK landing tests look good
<imgbot> === trainguards: RTM IMAGE 77 DONE (finished: 20141002 04:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/77.changes ===
<bzoltan1> Mirv:  but the camera app hangs .. is there a special trick to make that run? Maybe robru knows...
<robru> bzoltan1: i dunno nuthin bout nuthin
<bzoltan1> robru: dude :) that is a perfect line before saying EOD
<robru> EOD
<robru> ;-)
<robru> (EOD 3.5 hours ago)
<bzoltan1> LOL
<bzoltan1> I EOD'd 8 hours ago and woke up 3 hours ago...
<rsalveti> Mirv: why the bump from 2 to 5?
<rsalveti> I wonder if we shouldn't also bump the other files we have in there
<rsalveti> ops, 3 to 5
<Mirv> rsalveti: it looks like they forgot the bump the last time they bumped the version to 2.4.0..
<rsalveti> right
<rsalveti> seems fine from the MR
<rsalveti> Mirv: +1
<Mirv> thanks.
<Mirv> bzoltan1: I know no special trick for camera, it used to run ok
<robru> rsalveti:  my fix for that bug you saw just landed in production
<Mirv> camako: (if you are around) are you planning Mir 0.8.0 landing soon or slightly later? mzanetti kgunn etc would probably like to know whether they can land their QtMir + QtUbuntu also to rtm now that it's landing to utopic
<bzoltan1> Mirv: running like `/bin/sh -e /usr/bin/phablet-test-run -r 0000 -s JW024063 -p camera-app-autopilot camera_app` does nothing ... Failed to connect to Mir: connect not called
<rsalveti> robru: nice, hot fix in production
<rsalveti> that's how we roll :-)
<kgunn> Mirv: i know camako said there was a stopper for mir0.8 promotion
<Mirv> robru: any idea where queuebot went? it was active 45mins ago, no totally silent despite me doing things.
<robru> rsalveti: oh no, this one went through code review! ;-)
<Mirv> kgunn: ok. I can then at least assign silo for mzanetti.
<rsalveti> robru: awesome
<robru> Mirv: yeah stgraber says his server is kernel panicking every 10 minutes, so queuebot is more or less offline. before you woke up it was freaking out and spamming the channel a bit
<Mirv> robru: oh, ok.
<Mirv> oh yeah, scrolling a bit further, a suspiciously _lot_ of queuebot activity :)
<robru> Mirv: but not like the spamming we saw before, it was behaving normally in the sense that it would start up, and then ping everything as if it was new, and then the server crashed, and then it would reboot, restart, ping everything, etc
<robru> "behaving as well as could be expected from a server that crashes every 10 minutes"
<ToyKeeper> cyphermox_: Any idea if the two critical indicator bugs for rtm-024 (indicator-network, urfkill) are still present?  (network indicator crashes and doesn't restart, wifi toggles disappear when wifi disabled)
<ToyKeeper> The bug report doesn't indicate any fixes yet, and if the silo enables a new critical bug (even if it's in some other component), it can't land until the fix is included too.
<bzoltan1> trainguards: is here a QA eng available to check and sign the UITK in the silo14?
<ToyKeeper> bzoltan1: There might be soon.  The other two silos in queue are blocked.
<ToyKeeper> kgunn, mzanetti: On that note, what test plan is relevant for silo rtm-011?  Nothing is linked.
<bzoltan1> ToyKeeper:  all right, thanks. Then I carry on with the QtC work
<ToyKeeper> kgunn, mzanetti: I'm heading to sleep soon, so could you add the test plan info to the spreadsheet for whoever picks it up next?
<ToyKeeper> bzoltan1: I think a faster uitk testing method may have been worked out, but I don't recall if that matter ever came to a conclusion.  I hope it did, so we can get that tested and landed faster.
<bzoltan1> ToyKeeper:  That would be awesome. My tests took only about ~24 hours this time... but the base is not really good. The stock image has too many failures
<ToyKeeper> bzoltan1: I think the most bang for the buck with UITK is in manual exploratory testing, which would be both faster than re-running AP and more likely to catch visual glitches which don't affect the function.
<bzoltan1> ToyKeeper:  that is exactly I was suggesting from the beginning. Simple re-running the AP tests on a most likely different base image (I tested on three images in 24 hours) does not make much sense in my view. But as you said, good eyes can catch things.
<ToyKeeper> I just don't recall a final decision about it, and am at the end of my day.  I'll try to get it at least started though.
<bzoltan1> ToyKeeper: So I am happy for the change
<bzoltan1> Mirv:  I got a funny question... I am preparing the -gles package .. Now as the UITK is built in the RTM silo, I expect that the debian/watch file should contain different PPA URL. Is that correct?
<bzoltan1> trainguards: I would like to ask for a reconfig of the rtm14 silo, i just added there the -gles package.
<ToyKeeper> In that case, perhaps I shouldn't start on it.
<ToyKeeper> If the contents of the silo changed just now, wouldn't that invalidate the previous test results?
<bzoltan1> ToyKeeper: absolutely  not... I am adding the -gles package
<bzoltan1> ToyKeeper:  that has nothing to do with the UITK package I tested. It is a package for the emulator... what is not tested by anybody for any landing
<ToyKeeper> Oh, okay.
<bzoltan1> ToyKeeper: actually it is something what is a real issue... at some point we should start testing the emulator images too
<ToyKeeper> Haha, yeah.  As soon as the emulator itself is reasonably stable.  :)
<Mirv> bzoltan1: you're correct, it should be of the style http://ppa.launchpad.net/ci-train-ppa-service/landing-020/ubuntu-rtm
<bzoltan1> Mirv:  I used this "https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-014/+files/ubuntu-ui-toolkit_([^-]*)\.orig.tar.gz"
<bzoltan1> Mirv:  I can still change
<Mirv> bzoltan1: maybe that's correct... we'll see. reconfigured.
<Mirv> or sorry, not yet
<Mirv> changes in the prepare jobs
<Mirv> "Please ask the trainguards to reconfigure this silo for you." I _am_ a trainguard :)
<Mirv> oh, right, there it is
<Mirv> bzoltan1: now reconfigured
<bzoltan1> Mirv: :D
<bzoltan1> Mirv: ehh https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-014-1-build/25/console
<Mirv> bzoltan1: unsynced changelog vs https://launchpad.net/ubuntu-rtm/+source/ubuntu-ui-toolkit-gles
<Mirv> psivaa: btw the clock app qmlscene was a duplicate bug #1376346
<ubot5> bug 1376256 in qtorganizer5-eds (Ubuntu) "duplicate for #1376346 libedataserver crashed with signal 5 in clock-app" [Medium,Confirmed] https://launchpad.net/bugs/1376256
<Mirv> but the mediascanner one was potentially a newly filed
<Mirv> anyway, neither is upstream Qt crasher but apparently in our components
<bzoltan1> Mirv:  does it mean that I need to change the previous entry in the changelog? So it will pull from the RTM distro...
<Mirv> bzoltan1: probably yes
<bzoltan1> Mirv:  all.. right. I try that
<bzoltan1> Mirv:  it seems that the trick works.. thanks
<Mirv> good!
<brendand> sil2100, red alert, we got a true blocker yesterday
<brendand> sil2100, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1376500
<ubot5> Ubuntu bug 1376500 in thumbnailer (Ubuntu) "[regression] thumbnails and image previews displayed wrong" [Critical,Confirmed]
<sil2100> brendand: ugh, that in ubuntu-rtm?
<sil2100> Right, rtm
<tsdgeos> who do i need to bribe to get some nodes for http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/ ?
<tsdgeos> ' All nodes of label 'utopic&&amd64' are offline '
<Mirv> sil2100: at least that wasn't "isolated bug fix" but went through QA
<Mirv> tsdgeos: cihelp, probably
<tsdgeos> Mirv: if there was someone called cihelp :D
<sil2100> hah ;)
<sil2100> tsdgeos: cihelp is a key-word that all CI team members get pinged on
<tsdgeos> ic
<vila> tsdgeos: O_o /me looks
<brendand> Mirv, no i would have extra pissed off it is was an 'isolated bug fix'
<davmor2> Morning all
<sil2100> brendand: I just poked Satoris, not sure when he starts his day though
<vila> tsdgeos: weird, the node appears to be up but jenkins fails to connect to it, I'll escalate
<tsdgeos> vila: tx
<Mirv> sil2100: what's your current damage report? I mean in terms of recovering from injuries..
<Mirv> "hull intact" etc
<sil2100> hah ;)
<davmor2> sil2100: did I set the day thing right on those tags age still say N/A
<sil2100> It's better, it's not swollen anymore
<sil2100> But I still have problems moving it so I'm wearing a stabilizer
<sil2100> davmor2: hm, I thought those were correct, let me re check
<davmor2> sil2100: what this teach you about doing martial arts incorrectly ;)
<sil2100> I think everyone took our previous exercises a little bit too seriously
<sil2100> ;)
<sil2100> davmor2: ok, fixed, we both filled in bad tags yesterday - it's suppsaosed to be lt-date- not lt-age-
<davmor2> sil2100: hahaha
<mzanetti> sil2100: hey ho :) could I have a silo for spreadsheet line 42 please?
<sil2100> mzanetti: looking!
<sil2100> mzanetti: it's a sync from utopic now, right? Only unity8?
<mzanetti> sil2100: yeah
<mzanetti> sil2100: wait, let me make sure which ones
<mzanetti> sil2100: yep, only unity8
<sil2100> mzanetti: hm, unity8 already seems to be configured for ubuntu-rtm in silo 11
<sil2100> mzanetti: I'll assign a silo but make sure you land rtm/11 first
<sil2100> mzanetti: as the packages in the new silo I'll assign will include the version from rtm/11 as well, so we first need to +1 the previous silo before proceeding
<Mirv> sil2100: ok. hopefully getting better and better soon.
<mzanetti> sil2100: ah... that's why
<mzanetti> sil2100: ok... I can also wait... but rtm seems to start being 3 silo releases behind utopic
<mzanetti> sil2100: but we have > 10 approved branches in unity8 again, so I'd need to get going with that too soon
<sil2100> mzanetti: ok! Let's poke QA today to make sure it gets signed off as soon as possible
<mzanetti> brendand: hey, could you prioritize silo rtm/11 a bit please?
<sil2100> davmor2, brendand: can you (or anyone else) sign off rtm/11?
<brendand> mzanetti, no test plan
<brendand> mzanetti, otherwise it probably would have been signed off already
<sil2100> psivaa: hey! You online today?
<mzanetti> brendand: added the test plan link
<brendand> mzanetti, you didn't think about running any of the indicator- test plans?
<mzanetti> brendand: hmm... doesn't really change the indicators itself. only the ui for it.
<mzanetti> brendand: unity8 test plan contains verification of the ui
<mzanetti> but if you're worried, feel free to do some more checks
<Mirv> sil2100: he e-mailed that he'll be later on
<brendand> mzanetti, ok but keep in mind the testing is not only to verify the fixes work but also to check for regressions
<mzanetti> brendand: yeah sure... but if that silo introduces regressions its the ui not connecting to them, or rendering some labels wrong in there... still covered by the unity8 test plan
<brendand> mzanetti, ok just making sure - some people are not so careful
<chihchun> question: how do I push a new package version to the image?
<chihchun> https://wiki.ubuntu.com/citrain/RTMLandingApproaches # really confusing
 * popey gives up
<sil2100> chihchun: let me get back to you in a moment
<chihchun> sil2100: #1351092 and #1334495 are fixed in fonts-android 1:4.3-3ubuntu2, but I see fonts-android 1:4.3-3ubuntu1 in current image
<dbarth> hi trainguards; i've unblocked branches in silo 14 for landing
<brendand> pstolowski, hey - you tested the last mediascanner landing right?
<sil2100> chihchun: ok, so generally the RTMLandingApproaches is a document for people that already know the CI Train landing process and just want to know how to land the same stuff in ubuntu-rtm
<sil2100> chihchun: did you use the CI Train before?
<pstolowski> brendand, i tested last mediascanner-scope landing
<Mirv> dbarth: ok!
<Mirv> sil2100: robru: we'd btw need a feature to mark a silo "test silo" so that anything conflicting with only that is allowed to be prepared
<pstolowski> brendand, (not the mediascanner)
<Mirv> sil2100: robru: considering my Qt silo now conflicts with half the world
<chihchun> sil2100: No, I did not. and the issue has been fixed in ubuntu package, I don't need to do a new MP
<ogra_> ricmm, could you top approve https://code.launchpad.net/~ogra/phablet-tools/fix-phablet-shell-without-local-key/+merge/236696 ?
<sil2100> chihchun: ok then, let me take a look at this
<chihchun> sil2100: thanks
<sil2100> chihchun: ok, so I see that the new utopic images already have the ubuntu2 in them - all we need to do is sync up this package to RTM
<sil2100> chihchun: do you have an ubuntu-rtm enabled device?
<chihchun> sil2100: right, I have a nexus4
<sil2100> chihchun: does it have an image from the ubuntu-rtm channel installed?
<sil2100> Or is it devel-proposed?
<Mirv> pstolowski: MP not approved, can't publish https://code.launchpad.net/~unity-api-team/unity-scopes-shell/department-doesnt-go-away/+merge/231774
<Mirv> (top-approved)
<sil2100> chihchun: anyway, I'll fill in a sync landing for you - this will generate a PPA for ubuntu-rtm where the packages will be available for testing
<chihchun> sil2100: yes, I have r67, 20141002 image on it. (ubuntu-touch/ubuntu-rtm/14.09-proposed)
<sil2100> Excellent
<pstolowski> Mirv, ah, it is now
<ogra_> mvo, iirc that came from your meta upload ... https://lists.launchpad.net/ubuntu-phone/msg10035.html ... any idea about it ?
<brendand> psivaa, but you know it had mediascanner and thumbnailer in that silo right?
<brendand> psivaa, sorry
<sil2100> chihchun: ok, so now https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-021 has the fonts-android version for your testing
<brendand> pstolowski, ^
<chihchun> sil2100: where should I report my test result?
<sil2100> chihchun: once you test those packages, please go to the spreadsheet, find your landing (it's currently row number 68, but you can find it by your nickname), scroll the sheet to the right and switch 'Testing pass?' for this column to 'Yes (#image_no_you_tested_on device_name your_nickname)'
<sil2100> chihchun: after that the rest belongs to us and QA, so you're free
<Mirv> pstolowski: thanks, published.
<psivaa> sil2100: sorry dint know you'd lead the meeting back today. so i emailed Mirv in the rush to go out
<Mirv> psivaa: and I didn't notice sil2100 wasn't included :)
<psivaa> :)
<pstolowski> brendand, i know nothing about that, sorry
<brendand> ok that's kind of a problem
<chihchun> sil2100: all done, thanks
<mvo> ogra_: I am just the uploader, its "bzr log -r 248" committer: Jamie Strandboge <jamie@ubuntu.com>
<mvo>   merge from David Barth: Let apparmor protect access to the OA APIs
<ogra_> oh, ok
<sil2100> psivaa: ah ;) No worries!
<ogra_> dbarth, ^^
<ogra_> dbarth, see https://lists.launchpad.net/ubuntu-phone/msg10035.html for context
<sil2100> chihchun: thanks! Now just we need to wait for QA to sign it off and it'll be in ubuntu-rtm
<dbarth> reading
<dbarth> ok, i noticed that yesterday with mardy
<dbarth> mardy: ^^ that same permission error; so the fix is to explicitely specificy the applicationid when making calls. right?
<mardy> dbarth, ogra_: I'll comment on the bug report, as well as to the ML
<ogra_> mardy, merci :)
<brendand> sil2100, i almost forgot there's something i needed to talk to you about
<sil2100> Wazzup?
<brendand> sil2100, silo 19 has qml pre-compilation fixes, we think it will be high impact so when it lands we want it to land alone
<brendand> sil2100, you think you can arrange that?
<sil2100> Oh, finally that big landing!
<sil2100> brendand: sure thing, I also see that Mirv is set as one of the landers so I'm sure he'll additionally have a look at that
<ogra_> lets make sure to have a standalone image for it
<bzoltan1> brendand:  Do you think you can take the UITK release candidate?
<mzanetti> sil2100: hey, when you have a minute, please assign me a utopic silo for row 69
<brendand> bzoltan1, i'll put it next in the queue
<ogra_> how would people think about a remote execution feature for phablet-shell ? like: http://paste.ubuntu.com/8478233/
<bzoltan1> ogra_: I would use it
<seb128> do you people know what happened to get glib updated in the rtm serie?
<bzoltan1> brendand: thank you. The logs are at the same place. The link is in the sheet
<ogra_> seb128, havent checked excuses yet
<seb128> ogra_, excuses?
<seb128> we wanted to get it updated but qa needed to approve it I think
<ogra_> seb128, seems colin didnt move it over to rtm-proposed yet
<brendand> ogra_, what benefits would it give over adb shell?
<seb128> is that still blocked?
<ogra_> seb128, oh, wait ... glib ? not glibc
<seb128> ogra_, https://launchpad.net/ubuntu-rtm/+source/glib2.0
<seb128> right
<ogra_> heh, sorry ... (we're trying to land glibc too atm)
<seb128> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=glib
<seb128> that one ^
<seb128> is it blocked? can we do anything to unblock it?
<seb128> it's an important fix for wakeups issues
<ogra_> seb128, spreadsheed line 19 ..
<ogra_> hasnt been set to "testing done" yet
<ogra_> QA qill only be notified about it if that has happened
<ogra_> *wil
<ogra_> l
<seb128> Laney, ^ should we do that?
<bzoltan1> brendand:  I explained to ToyKeeper that the silore configuration  is not relevant for the QA because it was needed to get the -gles package built too
<ogra_> seb128, i assume the testplan: "test ALL the things" might be a bit time consuming though :P
<seb128> ogra_, not sure how you want to test base libraries
<ogra_> me neither
<ogra_> but at least describing how to test the bugs you aim for to be fixed are gone might be helpful
<Laney> testing done where?
<ogra_> Laney, the K column on the spreadsheet
<Laney> okay, I thought that was for QA to do
<Laney> seb128 did some testing
<Laney> I don't know how to check for the wakeup problem
<seb128> I run my krillin with that version for a few days without issues
<Mirv> sil2100: brendand: I'm just a lander helper there, but yes it's a high impact landing and requires super extra care. not sure about ETA though.
<Laney> seb128: can you fill in image number please ;-)
<davmor2> Laney: No the developers run their testplan and mark it tested, we then grant it in the needs QA sign off
<seb128> Laney, urg, I don't remember, I think it was 71
<Laney> heh
<seb128> let me reinstall it on the current image
<seb128> so we can put the current number there ;-)
 * Laney wibbles at davmor2 
<davmor2> Laney: take those pants off your head and pencils out of your nose, you don't fool anyone :P
<ogra_> Laney, note that if you put in "test all the things" someone might take that literally and run all AP tests (which is a several hour process) :)
<ogra_> i know that ToyKeeper does that in such cases
<Laney> ogra_: I don't mind, it's not expected to break anything
 * ogra_ usually points to the bugs and how to check they are gone in the test plan 
<ogra_> Laney, no, but it takes QA time and will make the landing slow
<Laney> well it's not an isolated upload just for that fix
 * brendand grumbles check for regressions too...
<Laney> we just took the upstream release which contains it
<ogra_> sil2100, any idea on what vacation the bot is today ?
<sil2100> hmmm
<sil2100> ogra_: I think it's just slacking off, we should fire it!
<ogra_> ++
<davmor2> ogra_: tomorrow it is uniting with all the other bots
<ogra_> lol
<Laney> Tag der queuebotten einheit
<sil2100> But yeah, I guess we need to poke stgraber about it
<Mirv> sil2100: ogra_: the machine running it reportedly crashes every 10 minutes, so it's essentially gone for now
<john-mcaleely> morning all
<john-mcaleely> sil2100, ogra_ new device tarball available
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141002-d5938d7.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141002-d5938d7.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141002-d5938d7.ods
<john-mcaleely> any chance of a davmor2 or brendand QA pass? ^
<brendand> john-mcaleely, as long as we're going to have the results in spreadsheet form can we keep it in the google doc?
<john-mcaleely> brendand, have a look at the google doc :-)
<sil2100> \o/
<bzoltan1> Mirv:  the QtC from the silo6 is well tested and good to go... it has a fix what could be important to important people :D
<Mirv> bzoltan1: ok, I'll publish it as soon as the arm64/etc builds are fully ready
<brendand> davmor2, are you busy with something else?
<davmor2> brendand: bisecting the trust-store crash
<ogra_> john-mcaleely, oh, i see two lovely fixes there :D
<john-mcaleely> ogra_, only two :-)
<brendand> davmor2, can we let the developers do that and you pick up the device tarball?
<davmor2> brendand: location crashing is definitely just 76+ trying to find when truststore crash happened now
<ogra_> well, the otherse are a nice icing :)
<john-mcaleely> ha!
<john-mcaleely> oh, the change in disk space will be latent unless you flash_tool install the release. I'll send mail on that topic once the release is up on s-i.u.c
<lool> davmor2: could you check syslog for aa errors?
<lool> davmor2: since the main difference seems to be apparmor
<davmor2> lool: done it yesterday with jdstrand  no issues relating to location directly
<lool> :-/
<davmor2> lool: exactly
<lool> davmor2: there was no simultaneous device tarball update, was there?
<lool> davmor2: any satellite crashed in your backyard between #75 and #76?
<davmor2> lool: no the device tarball is only available now, and the custom tarball did touch anything in here, but custom didn't land and ToyKeeper confirmed that location service crashed for her in 76 too
<davmor2> s/tarball did/tarball did not
<davmor2> brendand: I already have 73 flashing so I'll try that and then leave it with lool for the trust-store crash, and then test the device tarball on current
<davmor2> lool so image RTM73 has trust-store crash
<davmor2> lool: no I need to get on with some other stuff
<davmor2> now even
<davmor2> john-mcaleely: I get permission denied on the ods doc
<john-mcaleely> davmor2, doh
<john-mcaleely> davmor2, please retry
<davmor2> john-mcaleely: yay
<davmor2> lool just to confuse matter 77 with the device tarball I'm testing and location is working again but trust-store still crashes on it's initial run
<sergiusens> sil2100: so today, there's no difference from doing a utopic or rtm first landing?
<sil2100> sergiusens: what do you mean?
<sergiusens> sil2100: well, robru was telling me you were working on something to make it just one atomic thing
<sil2100> sergiusens: yeah, I didn't work on it yesterday because of a sick day so I'm one day late in the schedule
<sil2100> So for now it's still the same as before
<thostr_> sil2100: any idea what's wrong with silo 11? it seems to be building for days...?
<sil2100> thostr_: looking
<thostr_> sil2100: the log says it's building since 26.9.!
<sil2100> thostr_: ouch, well... this is iterating into infinity, as urfkill started being unbuildable for 3 platforms with the introduced changes
<sil2100> thostr_: I aborted the build, but this needs to be resolved anyway
<bzoltan1> brendand:  any news about the UITK landing?
<thostr_> sil2100: nice... just wondering why none of the landers noticed...
<sil2100> cyphermox_: hey!
<thostr_> and this is blocking others silos
<sil2100> cyphermox_: what's up with silo 11? Is making urfkill unbuildable for those 3 architectures wanted?
<sil2100> thostr_: yeah, I guess we, the LT, should have also noticed, but we can't keep track of all individual silo contents
<sil2100> Though, this one we should have noticed
<sil2100> thostr_: thanks for noticing!
<thostr_> sil2100: well, I think it should have been noticed by landers... I mean, when I press the build button I really want ot have it build ASAP. anyway
<cwayne> davmor2: ping
<davmor2> cwayne: so the custom tarball sucks without location dude :(  I'm testing a device tarball now tough and the location seems to be working there so lets get that landed and I'll try the custom again after that and hopefully we will be rocking then
<davmor2> cwayne: but it was looking pretty good except for the scopes that didn't load properly because of the lack of location :)
<cwayne> davmor2: but that's not the custom tarball's fault :(
<davmor2> cwayne: no but the broken scope become more obvious now they become front and center
<cwayne> but it's really not a broken scope, its a scope that requires location but not getting it
<cwayne> but anyway, im fine to get it in after device tarball :)
<brendand> bzoltan1, someone is looking at it now
<brendand> bzoltan1, remember the trello board :)
<ogra_> brendand, i thought that was supposed to be linked from the spreadsheet
<brendand> ogra_, i did to - look at sil2100
<brendand> ogra_, it's in the topic though
 * ogra_ loks at sil2100 
<ogra_> *looks
<sil2100> It was on the spreadsheet some time ago, ugh
<ogra_> brendand, he looks like evry day ... just with that thing around his wrist
<sil2100> brendand: re-added
<sil2100> That thing on my wrist is irritating - looks cool but is uncomfortable as hell
<ogra_> heh
<davmor2> sil2100: then stop doing martial arts badly, lesson learnt ;)
<davmor2> sil2100: this is the problem with martial arts when it goes wrong it hurts like hell, I broke me little finger cause it got caught up wrong doing a roll for gods sake :) You think your wrist support is annoying try a cast :D
<sil2100> hah ;)
 * sil2100 goes for lunch
<sil2100> No way I'm cooking with this hand, we'll eat something outside
<cwayne> davmor2: man im pretty sure i would break everything if i tried martial arts
<davmor2> sil2100: wow that ambitious unless you have snails outside
<davmor2> cwayne: man you'd be fine
<cwayne> davmor2: nah, im pretty sure i'm like made of glass or something, I broke my pinky finger badly last year just playing catch with my brother
<cwayne> lol
<davmor2> hahaha
 * ogra_ would recommend a ball instead
<cwayne> lol
<cwayne> but he's so fun to throw
<ogra_> heh
<bzoltan1> brendand:  ahh.. of course. I see victor opened it
<cwayne> davmor2: btw, i've started this up if you think it could be helpful for tracking.. it's basically what you told me you test anyway + like 2 things :) https://docs.google.com/a/canonical.com/spreadsheets/d/1j9dQyiHLj5w6udh8Ixp3VfOF7C8ZGYaUYz65wx9TxyM/edit#gid=0
<cwayne> davmor2: so installing with a --wipe, I am now able to reproduce not getting location
<cwayne> and it does suck :/
 * lool goes wiping his krillin then
<davmor2> cwayne: told you so ;)
<cwayne> davmor2: you were right :)
<cwayne> although it isn't my fault at least :P but it does certainly ruin the scope experience
<lool> davmor2: still we dont know exactly what caused the regression, there was no location-service related landing between 75 amd 76
<davmor2> john-mcaleely: I have run everything on your spreadsheet and that is all good, including headset
<davmor2> john-mcaleely: I'm just running a quick smoketest now and then I think it is good to go
<john-mcaleely> davmor2, sounds good
<sil2100> davmor2: I don't like eating snails
<zsombi> brendand: ping
<brendand> zsombi, hello
<zsombi> brendand: zoltan is away, so in case you have sthing for the toolkit, I'll be here for an hour still
<kenvandine> sil2100, can  you tell what's wrong with line 71 on the spreadsheet?  says circular dependency?  and there's a request ID, but it isn't in a silo
<sil2100> kenvandine: hm, let me check
<sil2100> kenvandine: ok, fixed - something broke and there was an invalid formula in column O
<kenvandine> thx
* Ursinha changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: Ursinha | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<davmor2> john-mcaleely, sil2100: device tarball is good
<ogra_> yay
<sil2100> yay!
<sil2100> john-mcaleely: push it o/
<ogra_> john-mcaleely, are we there yet ?
<sil2100> davmor2: then the custom tarball, right?
<john-mcaleely> sil2100, sure?
<lool> davmor2, cwayne: How does one track landing of a custom or of a device tarball?
<lool> cause I have some updates to land there too
<davmor2> lool: you talk to cwayne and john-mcaleely
<sil2100> john-mcaleely: I guess so - ogra_, brendand: any objections?
<ogra_> lool, custom -> cwayne, device -> john-mcaleely
<lool> and for utopic?
<davmor2> lool: there isn't one
<ogra_> the android package for device ...
<lool> davmor2: there is!
<lool> davmor2: or do you mean no process?
 * john-mcaleely my hand is hovering above an 'enter' key...
<ogra_> lool, cwayne again :)
<ogra_> john-mcaleely, ohhhh, the suspense !
<john-mcaleely> lool, one reads the tea laves
<john-mcaleely> (for device tarball)
<davmor2> lool: I meant tarball, it's in the package as ogra_ says :)
<lool> ah right
<sil2100> john-mcaleely: pressit!
<john-mcaleely> pressed, sil2100 davmor2 ogra_ brendand  - new device tarball pushed
<davmor2> john-mcaleely: Don't make me come down there and press it for you :P
<john-mcaleely> lool, ^ there you go - live feedback on progress :-)
<davmor2> cwayne: do you need to do anything to have it pull in the device tarball on your version?
<lool> john-mcaleely: :-)
<cwayne> davmor2: shouldn't
<alecu> trainguards: ping. I'd like to ask about bug # 1376445, where a change in signon-apparmor-extension broke online accounts as used from the click scope and some other places
<alecu> http://pad.lv/1376445
<ubot5> Launchpad bug 1376445 in signon-apparmor-extension "Addition of signon-apparmor-extension causes token lookup problems" [High,In progress]
<cwayne> if you're asking to revert it, +1 from me too
<alecu> trainguards, cwayne: I'd like to find out how did it land (I suspect not thru a silo), and how we can prevent those kind of breakages in the future
<alecu> at least, I'd like to make sure that landings for online accounts are triggering QA in dependent projects, like our scopes
<alecu> mardy: dobey: I'd like your ideas on that too ^
<dobey> alecu: require QA approval and ensure QA tests the appropriate things, when new packages are requested to be added to the ubuntu-touch seed, before the change is actually made, as i don't think ubuntu-meta lands through CI train
<dobey> moving ubuntu-meta to CI train would probably be a major annoyance for everything other than ubuntu-touch though
 * Ursinha watches the conversation and makes notes
<alecu> Ursinha: feel free to throw ideas too, I'd like to understand how this is happening, and how to prevent it.
<Ursinha> dobey: that's an interesting use case
<Ursinha> alecu: I'm learning the process as well so I can suggest improvements :)
<dobey> Ursinha: indeed
<Ursinha> dobey: how does that work in that case? the package is pushed to archive directly and then you have to QA it?
<Ursinha> as you say that doesn't land through citrain
<Ursinha> *said
<dobey> Ursinha: well, ubuntu-meta is just a meta package; the package that caused the breakage was already in the archive. what caused the breakage was it being added to the seed, and thus instaleld on the image.
<dobey> Ursinha: so i think when there is a request to add a new package to the ubuntu-touch seed, QA should first install that package on a device, and then run through appropriate test plans to ensure things don't break; then they sign off and it can be added to the seed
<cwayne> +1
<dobey> and i'm guessing this problem happened, beacuse we aren't doing that (if we are doing that, then i guess the wrong tests were run, or at least, not enough tests were run)
<Ursinha> dobey: oh, I see the problem package-wise..... do we have more of these, a significant number of metapackages that we care about on the phone side?
<dobey> Ursinha: i don't think so. afaik ubuntu-touch is the only metapackage we really care about on the phone side
<Ursinha> right
<dobey> cjwatson would know better than me if there are others though
<Ursinha> dobey: I'll think about it on the train/airline side, thanks for the info
<sergiusens> sil2100: Mirv can I get a slo for 77?
<sil2100> Ah, crap, right... no queuebot
<sil2100> sergiusens: sure
<Ursinha> sil2100: what happened with queuebot?
<sil2100> Ursinha: stgraber's machine has problems right now, so queuebot has no where to work on - we've been already discussing moving it to somewhere public
<Ursinha> sil2100: oh yeah, you know you have my +1 on that :)
<dobey> Ursinha: sure. i'm not sure we want to stick ubuntu-meta in the ci train process completely though; as that would add a bunch of needless process for the rest of ubuntu when managing server/desktop images and such.
<Ursinha> dobey: not completely, as you said it would be a lot of trouble and the goal is to facilitate, not the other way around
<Ursinha> dobey: I was more considering the tracking part, having maybe a "partial" request where the building part is done outside the train but we still get to track and request QA input
<Ursinha> something along these lines
<robru> bfiller: your build failure is caused by a comma in the space-separated packages list, fixed it for you and building: https://ci-train.ubuntu.com/job/ubuntu-landing-002-1-build/76/console
<cwayne> but so while fixing process in the future is great, we also need to fix the immediate problem :)  should we revert that addition? or wait for a fix?
<cwayne> it breaks all my scopes that use OA..
<bfiller> robru: oh thanks, I hadn't seen that yet
<dobey> cwayne: i was hoping mardy would get the fix in which i suggested on the mailing list
<Ursinha> bot being dead makes me sad
<dobey> Ursinha: don't be sad. it's only the beginning in bot's new afterlife
<Ursinha> LOL
<cwayne> dobey: https://code.launchpad.net/~mardy/signon-apparmor-extension/lp1376445/+merge/236882
<cwayne> not in a silo yet that i've seen
<dobey> cwayne: well, jenkins doesn't like it :)
<cwayne> noticed that :)
<dobey> oh
<dobey> that's because coverage isn't working in jenkins for some reason, but it's trying to build with coverage
<dobey> the tests apparently passed
<sergiusens> brendand: do critical bugs get QA signoff preference?
<brendand> sergiusens, i would hope all silos are fixing critical bugs at this stage
<sergiusens> brendand: well some of us only have high bugs in our lists ;-)
<sergiusens> I would bet not thought
<sergiusens> easily checked in the PPA changelog
<dbarth> trainguards, can i have a silo for line 78 please; thank you
<rsalveti> jezz
<ogra_> lovely
<sil2100> Let the poor guy talk all he wants
<sil2100> queuebot: we're happy to see you too
<sil2100> dbarth: ok! Let me check if anyone was faster than me
<dbarth> eh
<dbarth> so, who wins? ;)
<sil2100> dbarth: I did ;) Silo should be yours
<sil2100> elopio: hi! Do you know if there is any progres related to gallery and calculator utopic failures?
<sil2100> elopio: the ones with $HOME issues
<Ursinha> sil2100: where is the bot running now?
<elopio> sil2100: we started a long discussion to find the right way to solve it
<elopio> https://bugs.launchpad.net/ubuntu-app-launch/+bug/1376423
<ubot5> Ubuntu bug 1376423 in Ubuntu Application Launcher "There is no easy and future-proof way of starting an app in a clean environment" [Undecided,Invalid]
<sil2100> Ursinha: I think it's still at Stephane's
<elopio> for now, things point to create a new user, and that's something that will take time to implement properly.
<elopio> so now we need to see if we add a new patch to fix it for the moment.
<Ursinha> sil2100: got it
<lool> trainguards, Mirv: FYI, I've repurposed the dbus-cpp + l-s rtm silo / landing request to include more packages and do a single bigger location related landing
<lool> however I need to land translations first
<lool> trainguards, Mirv: woudl you mind killing line 25 ?
<lool> kgunn: hey, how's the utopic landing of trust-store going?
<kgunn> lool: i am just now testing it
<kgunn> hope to be done w/in 30 min
<lool> kgunn: cool; mind pinging me when it's in?
<kgunn> lool: will do
<sil2100> lool: oh, ok, so completely freeing line 25, yes?
<lool> sil2100: yes
<lool> sil2100: I've merged into the first landing for l-s
<lool> sil2100: if I read this correctly, there's no silo
<sil2100> lool: just to make sure - you mean the rtm landing from tvoss, right?
<lool> sil2100: yes
<kgunn> lool: hey do you know much about trust-store ?
<lool> kgunn: not much; the concepts and have poked a bit
<lool> kgunn: I saw there was a comment on the top crasher that this could possibly be fixed by a random branch, but I kind of doubt it
<kgunn> lool: so his official test plan filters down the testing, and it passes....but if i run the full suite i see a couple of failures....
<kgunn> altho, those aren't called out in his test plan
<kgunn> so...hmmmm
<kgunn> reverting to virgin image to try
<sil2100> geh
<sil2100> Firefox died
<sil2100> One final try
<sil2100> Ok, that's no use, my connection to google services is too terrible
<sil2100> ogra_: could you lead the meeting in my stead?
<ogra_> sil2100, sure
<sil2100> Since I can't even get hangouts to open now
<sil2100> ...aaand I can't even close the tab, great
<ogra_> sil2100, not sure you had anything you wanted to bring up specifically ... we shortly talked about the systemsettle issues ...
<pstolowski> trainguards, what should I do with line 55 (see my comment in line 81)? i basically need the hotfix to land in utopic first, then 55 should have all the fixes listed previously in #54/#55, plus the hotfix
<robru> pstolowski: i don't understand what you're trying to do
<pstolowski> robru, a few MPs just laned in utopic, but we discovered an issue and need to land one more MP in utopic. then we want to copy utopic package into rtm (so, all the MPs from #55 + the hotfix)
<robru> right, so just do that exactly how you described it, then? I don't understand what the problem is
<pstolowski> robru, shall #55 still list all MPs, plus the new one? or just the new one?
<robru> pstolowski: no, 54 already landed, it's done. 55 can't have any MPs because it's a sync. I gave you silo utopic 1 for line 81, build test & land that one, and then when you do the sync it'll pick up everything together
<kgunn> lool: i want to check something but have to step away for an hour...sorry to be a hold up on trust -store but wanna be sure
<pstolowski> robru, ack, thanks
<lool> kgunn: ok
<robru> pstolowski: you're welcome
<dbarth> hey, i'm trying to see which rtm image oxide 1.2.4 will be in
<bzoltan> brendand: I missed the last few hours. Is there any news about the UITK QA tests?
<ogra_> dbarth, is it in the rtm archive already ?
<imgbot> === trainguards: IMAGE 266 DONE (finished: 20141002 17:00) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/266.changes ===
<davmor2> cwayne, sil2100, ogra: so let it roll I think, everything opens, everything seems to work, location works which was the big issue before I'm happy
<cwayne> davmor2: did it add the extra favorites too?  (if you'd ever touched them it won't unless you do a fresh flash)
<cwayne> neato
<popey> my unity just crashed in 266
<cwayne> so sil2100 am i good to push?
<popey> died completely
<sil2100> cwayne: yeah, I guess that's a +1!
<sil2100> robru, slangasek: not sure if I'll be able to join todays hangout ;/ I seem to have issues with the internet, or at least with accessing google
<robru> sil2100: try chromium? it seems to work better for hangouts
<robru> sil2100: oh I need to coordinate with you: so I'm done hacking the build job (for now). are you still working on the publish job?
<sil2100> Yeah, but I have problems with connectivity in overall, I'm dropping packets to google.com
<robru> hm
<sil2100> robru: not yet, but I'm almost done!
<davmor2> popey: why did you kill it you are meant to cherish it and nurture it like it is a small child, not kill it ;)
<sil2100> Still writing tests for the new bits
<cwayne> sil2100: davmor2: pushed, thanks guys
<cwayne> now there will probably be a new one on monday :P
<robru> sil2100: cool, no worries. I do need to get on the publish job sooner or later, but it can wait ;-)
<dbarth> ogra_: it's in ubuntu-rtm yes
<dbarth> ogra_: https://launchpad.net/ubuntu-rtm/+source/oxide-qt
<brendand> bzoltan, let me check
<brendand> bzoltan, is it urgent to land today?
<bzoltan> brendand: would be nice
<bzoltan> brendand: so we can sync the trunk tomorrow and it could land on an rtm image
<dobey> are the lines in the spreadsheet for syncs from one distro to the other supposed to include the MP lines now as well?
<sil2100> dobey: no, no MPs needed there
<dobey> that's what i thought. i saw a couple that had MPs listed there though
<sergiusens> fginther: any reason http://s-jenkins.ubuntu-ci:8080/view/click/job/account-polld-ci/ is not running?
<sil2100> dobey: yeah, we usually clean those up before assigning
<sil2100> What the heck
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: Ursinha | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: s-jenkins need to be restarted. Please inform robru of all build failures today.
<fginther> sergiusens, We need to bounce s-jenkins. the trigger jobs were stopped a little while ago to stop incoming work
<sil2100> slangasek, robru: I'm trying to connect right now
<sil2100> Ffffff
<sil2100> slangasek, robru: ok, quick modem reset
<sil2100> brb
<AlbertA2> trainguards: can I get a silo for line 84?
<robru> slangasek: meeting?
<fginther> sergiusens, s-jenkins is up again, that job should start soon
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: Ursinha | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all build failures today.
<sergiusens> ralsina_: ^
<sergiusens> fginther: thanks
<ralsina_> fginther: thanks
<kgunn> Ooo ooo ^ silo rtm11 ready to publish!
<sil2100> !
<sil2100> kgunn: publishing :)
<kgunn> lool: ok...so sorry, so many interupts...but yeah, looks like those same tests are failling in the virgin image
<kgunn> so i'm gonna say this tests ok
<kgunn> no regression
<sil2100> o/
<kgunn> robru: line 59 on the sheet actually that one ^ silo003, can you set me up an rtm sync ?
<kgunn> thanks
<AlbertA2> trainguards: can I get a silo for line 84?
<sergiusens> robru: can we setup a sync of http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-022 to utopic?
<robru> kgunn: you got rtm23
<kgunn> thanks
<robru> AlbertA2: utopic 12
<robru> sergiusens: utopic 16, and congrats on being the 2500th silo assigned
<robru> kgunn: you're welcome
<thostr_> can I get a silo for line 81?
<robru> thostr_: utopic 17
<thostr_> robru: thanks. then another one for line 82? this is for fixing the blocker about the broken picture thumbnails
<robru> thostr_: yeah build the utopic one first, the sync can come after
<thostr_> robru: ok
<cwayne> kgunn: any reason for line 67 to not have a silo yet? would love to test many of those branches..
<kgunn> cwayne: it's up next in fact.... robru if you have a spare ^
<kgunn> robru: also, in row 29 "small unity8 fixes" can get an rtm silo now that silo11 is cleared out
<robru> kgunn: ok, row 67 got 19
<robru> kgunn: line 28 you mean? 29 landed
<kgunn> robru: which ever has the title "unity8 small fixes"
<robru> right
<robru> kgunn: i'll have to get back to you on that one, spreadsheet is imploding
<kgunn> robru: np :)
<robru> kgunn: ok utopic 11
<bregma> is it imploding or exploding?
<bregma> sideploding
<robru> bregma: definitely an implosion, it's collapsing under its own weight. it may have enough mass to achieve a singularity
<bregma> more likely just collapse into a neutronsheet, or maybe even a brown dwarf
<kgunn> bregma: lol
 * kgunn now has to imagine implosion vs http://www.youtube.com/watch?v=jdn8gQkHyHI
<ted> rsalveti, Are you going to land the indicator-sound branch for the profiles?
<ted> rsalveti, Want to rebase a couple branches on that, it would be easier if it was in trunk :-)
<cwayne> fginther: so could I try to build clicks with click-buddy on s-jenkins? (i.e. will it be installed at all on those machines)
<fginther> cwayne, I'll get back to you shortly
<cwayne> ok thanks :)
<ToyKeeper> Laney, seb128: So, the glib silo (rtm-015) needs some sort of test plan, and confirmation via testing that it actually fixes the bug it's supposed to fix.  Probably also a means of retesting the wakeups in the future to detect regressions.
<alecu> that sounds wrong... line 84 is building on silo rtm-26
<ToyKeeper> Laney, seb128: On the desktop it's usually okay to pull new revs from upstream without much testing, especially early in the release cycle, but the phone is much more strict (especially this close to release).
<seb128> ToyKeeper, not sure what would be a test plan for that "run the phone, make sure it keeps working as before"
<seb128> ToyKeeper, no need to give a speech on how the phone is stricter than the desktop
<ToyKeeper> seb128: A good start would be "here's a way to measure wakeups before/after the change".
<seb128> ToyKeeper, no idea how to do that, you would have to ask to the people who filed the bug
<seb128> ToyKeeper, we got an update from upstream that fixes the issue, but no idea how to reproduce it
<ToyKeeper> seb128: Do you have a link to the bug?
<ToyKeeper> seb128: QA can't sign off until the changes are testable and documented in a test plan or AP test suite or unit test or performance test somewhere that it won't be forgotten.
<seb128> ToyKeeper, ok, feel free to keep the phone eating power through wakeups then, your call
<seb128> that update is coming from upstream and fixing things
<seb128> even if we don't have specific steps to trigger the issue
<alecu> seb128: ToyKeeper: I think we are all a bit exhausted with deadlines
<ToyKeeper> seb128: You could ask jfunk for an exception.
<alecu> seb128: but I understand that it's our job as landers to test the silos to make sure they fix the things that they are supposed to fix. That includes finding out how to test it, to try to make QA's life easier
<seb128> alecu, well, I don't know how to make a testplan for a lib like glib
<seb128> it's used by most processes on the phone
<seb128> so it's basically "use the phone, run all the tests"
<seb128> which is what we wrote on the landing ask
<alecu> seb128: I wouldn't know how to do that too. But it sounds to me that there must be a way to test that specific thing that's being fixed
<ToyKeeper> It is indeed difficult to test core libs.  It at least needs a way to test the specific issue it's fixing though.
<seb128> well, I don't know how to reproduce/test it
<seb128> I just can say the update includes an usptream fix
<ToyKeeper> Can you find out how to test it?
<kenvandine> ToyKeeper, i've improved the updates portion of the settings test plan
<ToyKeeper> kenvandine: Sweet, thanks!
<seb128> ToyKeeper, I guess, but I don't have the free slots for that
<seb128> ToyKeeper, so either we take the fix or not, your call
<kenvandine> ToyKeeper, it's still one scenario, but more thorough
<kenvandine> i'll add more for install all/pause all along with landing fixes for  bugs in those :)
<ToyKeeper> kenvandine: I should be ready to start on that as soon as I have my phone reflashed and the silo installed.
<seb128> ToyKeeper, one corresponding bug is https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1308130
<ubot5> Ubuntu bug 1308130 in indicator-messages (Ubuntu) "indicator-messages-service is waking up every 4 seconds adding inotifies on paths that don't exist" [Low,Confirmed]
<seb128> ToyKeeper, you can maybe ask cking to help since he reported the issue?
<ToyKeeper> seb128: QA is a tiny team and doesn't have enough cycles to write the tests for everyone else's changes.  QA is mostly making sure the dev teams are doing proper testing.
<robru> ok, spreadsheet statuses restored.
<seb128> ToyKeeper, right, well other teams are also small and might not have the resources to write tests for every bugfix backported from other upstreams
<seb128> ToyKeeper, so we have the choice to test for regressions and test the fix, knowing it likely fix the issue and doesn't create new one or just reject it because it has no proper testcase and keep a blocker bug in the rtm
<seb128> ToyKeeper, I'm not the one who asked uploads to be gatekept by the qa team there, just trying to help getting issues resolved
<ToyKeeper> seb128: I'll see if cking can help, but for now it's blocked pending tests (from cking, seb128, or Laney) or an override.  It's not actually my call.
<seb128> ToyKeeper, nor mine
<pmcgowan> ToyKeeper, do you know how the daily power test results are done
<pmcgowan> thats the reference in the bug
<ToyKeeper> pmcgowan: No, sorry, I'm not really involved in the performance testing.
<pmcgowan> ToyKeeper, seems the test plan is to run that on the silo, who would know?
<thomi> pmcgowan: are you referring to the battery discharge tests, as documented on the RTM readiness report? or something else?
<thomi> pmcgowan: oh wait, I see now, sorry, ignore me :D
<thomi> I'm pretty sure that's cking's baby
<pmcgowan> robotfuel, we have a fix for https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1308130 in a silo and want to run the daily power tests to validate it
<ubot5> Ubuntu bug 1308130 in indicator-messages (Ubuntu) "indicator-messages-service is waking up every 4 seconds adding inotifies on paths that don't exist" [Low,Confirmed]
<pmcgowan> if that makes sense
<pmcgowan> robotfuel, the fix is a new glib in silo rtm-15 and QA here was unsure how to test it
<jfunk> pmcgowan: not to be pedantic, but it seems everyone is unsure how to test it
<jfunk> not just QA ;)
<robotfuel> pmcgowan: okay all the power tests take more than a day, due to lack of resources, but we should be able to tell from the screen off quiet and the screen on quiet tests.
<pmcgowan> jfunk, fair enough :)
<pmcgowan> robotfuel, would you validate that or can you tell us/ ToyKeeper how to do it
<kgunn> ted: yo, you gonna land that silo that has unity8 in it very soon ?
<kgunn> like tonight ?
<robotfuel> pmcgowan: I can do that, I'll talk to toykeeper
<pmcgowan> robotfuel, awesome thanks
<ToyKeeper> kenvandine: Sorry, it's looking like your silo might be delayed a bit.  :(
<ted> kgunn, 13?
<kgunn> ted: yeppers
<ted> kgunn, No, that's just an integration silo, mterry's branch isn't finished in there.
<kgunn> ted: ah-ha...good, so i can proceed
<kenvandine> ToyKeeper, problems? or did something else jump in front of me in line? :)
<ted> kgunn, Yes
<pmcgowan> ToyKeeper, kenvandine oh heck, I didnt mean to do that
<mterry> ted, kgunn: sorry!  working on it, but i've got weird issues with it
<kgunn> mterry: no prob, just trying to clear out some of our backlog
<mterry> ted, also, you might want to reconfigure/rebuild that silo from latest chagnes
<ted> kgunn, Sorry, it says "ignore this branch" in the spreadsheet, it just doesn't carry over well.
<mterry> slightly smoother now
<ToyKeeper> kenvandine: Depends on if we find a way to test glib soon.
<kgunn> yeah i was on dashboard
<ted> mterry, Cool, I'll rebuild.
<robotfuel> pmcgowan: it might be good to send an email to cking to ask him to test the silo tomorrow morning, he has some special equipment to measure power consumption.
<mterry> ted, only sticking point now is that it takes a bit for some of the menu content to regen
<kenvandine> ToyKeeper, haha... pmcgowan was bugging me about when it would land... now he's bumping me down in the queue :)
<pmcgowan> robotfuel, thats fine with me
<pmcgowan> robotfuel, mind emailing him?
<robotfuel> I'll send an email
<robotfuel> pmcgowan: ^
<pmcgowan> thanks robotfuel
<ToyKeeper> I'd definitely prefer if cking could do it, since he has the tools and background for it and it seems no one else does.
<pmcgowan> thats fine
<pmcgowan> ToyKeeper, he can test if it fixes the issue but not if there are side effects I'd say
<pmcgowan> but maybe also some of that
<ToyKeeper> pmcgowan: Definitely.  I'm planning to do the daily image test on it as a system-wide sanity check.
<pmcgowan> great
<brendand> robru, can you make the spreadsheet behave please?
<brendand> robru, we keep getting duplicate cards i suppose because it's flicking back and forth between the QA sign-off state
<robru> brendand: http://38.media.tumblr.com/tumblr_lyjjr8cbwp1r34qiso1_500.gif waving my magic wand just for you buddy
<brendand> robru, but seriously, this only started happening in the last couple of days
<robru> brendand: oh did it? funny I must have been hallucinating for the last 6 months then because the spreadsheet is *CONSTANTLY* reverting state and generally throwing away critical information.
<robru> brendand: you're a total nutjob for wanting to write code that integrates with this. just delete it.
<robru> the spreadsheet is going away anyway so you'll need to write new code to read from the new thing anyway
<asac> anyone knows if this glib landing can be backed out?
<asac> Laney: is it an abi bump etc.?
<robru> asac: the glib landing isn't even in RTM
<fginther> cwayne, click-buddy is installed on the armhf boxes, but it's the trusty version
<cwayne> fginther: ah, hm, any idea how different they are?
<sergiusens> cwayne: only misses the --allow-untrusted for installing on target
<asac> robru: i see a silo here: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=
<fginther> sergiusens, thanks, I was getting ready to read through bzr logs
<asac> robru: let me rephrase, i wondered if the landing intend is something that can be backed out in case we land it
<asac> e.g. abi bump etdc.
<sergiusens> fginther: much easier to grab the debs for each and compare the included click-buddy with a diff :-)
<fginther> cwayne, installing to the target wouldn't be useful here, there are no devices attached :-)
<robru> asac: oh I have no idea how easy that would be to revert. i thought you thought it was landed already and wanted to back it out
<fginther> cwayne, sounds like it should work, if there are problems we can investigate
<asac> robru: no, just want to figure what risk we can take to understand how we go about bootstrapping a formalized glib testplan
<cwayne> fginther: sergiusens: excellent :) i'll try it out
<robru> asac: ah, ok. not sure, better ask Laney then, sorry
<cwayne> fginther: /tmp/hudson6281116677040042202.sh: 2: /tmp/hudson6281116677040042202.sh: click-buddy: not found
<cwayne> oh the armhf boxes
<cwayne> fginther: actually still seeing that on calxeda
<cwayne> ah it works on calxeda-pbuilder, but doesnt have the right framework :/
<Laney> What do you want to know?
<Laney> There's no ABI break, that would be madness in the case of glib and you'd definitely know about it.
<cwayne> sergiusens: where do the click frameworks actually come from?
<cwayne> i.e. which package
<asac> Laney: just to give you context (without implying anything at this time), the way we bootstrap landing gate testplans is that the landers start a pretty simplistic testplan that captures what they think is reasonable to protect us from majority of regressions we might encounter (after all the component owner knows best how his component is used in stack and what parts are a bit flaky and hence what hotspots in the stack we might
<asac> Laney: then if we find regressions in image testing after landing, we improve the gate smartly (aka learning testplan rather than a blank "test all"); since glib never did landings before, our knowledge about how a smart testplan looks like is very constrained and since we cannot afford any big risk, we can only really do that in this way if we are sure we can get rid of a regression coming out of it through a backout.
<asac> if we canot backout there are two choices: a) nothing changes for lander and we just frontload the QA image testing on the silo; b) land a cherry pick fix so we can back out
<Laney> Can you show me one for a base library?
<asac> Laney: depends how you define base libraries. good set of what you consider base libraries are in the same situation as glib because they were always direct uploaded by core-devs which means that we have no organically grown testplan (which is really unfortunate given the level of risk averseness we have at this point where customers constantly expect better deliveries)
<asac> so i would like to use glib to maybe figure how we can do that as i expect there might be other libraries coming
<asac> at even more unfortunate times
<asac> anyway, there are components that are deep in the stack that have test plans grown organically
<asac> let me find some
<asac> Laney: given the nature that we grow as we go and start small, stuff that is stable usually doesnt need full testing. so https://wiki.ubuntu.com/Process/Merges/TestPlan/platform-api is pretty much something central is still reasonable
<asac> Laney: other extreme is uitk which broke everything here and then over time, so we run basically all APs etc. on it
<asac> Laney: https://wiki.ubuntu.com/Process/Merges/TestPlan/ui-toolkit
<asac> I cannot remember glib breaking stuff here and then.
<asac> so i think its pretty stable
<asac> there were glitches that broke everything at once, but those would have been caught by just running a single AP test
<asac> and boot system
<asac> and do something like using systemsettings or so
<asac> anyway, the whole thing is that we start with something the lander feels gives him some level of confidence in a formal manner so we can learn over time and tweak, improve etc.
<asac> Laney: https://wiki.ubuntu.com/Process/Merges/TestPlans/
<asac> there are loads of testplans under that
<asac> imo you guys are most familiar with glib and know which areas are rock solid
<asac> and which areas are causing grief
<asac> (a few years back i would have suspected that the gio part is flaky so i would have probably checked if there is anything very basic i can do to exercise that that part works)
* robru changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: Ursinha | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all silo assignment/reconfigure failures today.
<asac> otherwise, just think how glibt is used and which main submodules are used by which app in our touch stack
<asac> so lets say gio is used by app X, just say: start app and see that X works
<fginther> cwayne, I believe this error is caused by not having the necessary schroots (which makes sense as these machines have none)
<asac> tell me what you think we could do that makes sense. as i said would really much would like to use this to understand what we would do in case another base library comes even later during our product crunch
<cwayne> fginther: makes sense
<asac> Laney: looking at the bug and that its marked low prio we can also continue talking about this on monday (tomorrow is pub holiday)
<Laney> asac: Alright, well we can talk about this in the team tomorrow and see what we think.
<asac> Laney: thanks. just repost the lines i wrote. as i said its something new. so far we only dealt with base libraries taht are under heavy development
<asac> by ourself
<asac> like uitk
<asac> so folks automateically believe that all these base libraries need to have everything run at the gate automatically
<asac> but i dont think thats the case for the parts in our stack that are super stalb
<asac> but we have no data besides the incidential "all broken firedrills" due to big glitches that can happen on those
<asac> imo we should just apply what we always do. you guys think what would be a good start and then se how this evolves over time
<asac> and as long as we can backout the risk of not knowing things is bearable
<Laney> There's a lot of random stuff in the stack that is actually pretty mature software
<asac> just land early in day and if there is a regression, back it out, figure if there is a smart stitch to protect etc.
<asac> Laney: exactly
<Laney> I think that if you have this feeling about a change you want to make then a very heavyweight process is going to feel like quite a drag
<asac> Laney: so i am sure if we start light, we will protect from the bit glitches and we wont have a big testplan
<asac> Laney: what i describe above is very lightweight. its just writing up whatever you feel are reasonable test steps that help you feel confident that all will be good
<asac> anyway, run that through team
<asac> and lets chat monday
<Laney> k, thanks for info
<lool> kgunn: sorry, so what' the plan WRT trust-store? is this delayed to tomorrow?
<lool> trainguards, would you mind assigning a silo for line 68 (roaming location-service fix); this one needs a separate PPA while it's being tested by HERE folks
<lool> hopefully tomorrow morning if I can get a silo now  :-)
<robru> lool: utopic 3
<lool> robru: ty
<robru> lool: you're welcome
<kgunn> lool: i landed in utopic, and marked it ready for qa in rtm
<lool> thanks
<lool> trainguards, any free silo for utopic / line 74?
<robru> lool: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=location-service how many location-service silos does there need to be, exactly?
<lool> robru: the ubuntu-rtm one should be gone...
<robru> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=location-service even also ubuntu ;-)
<lool> robru: 17:54 < sil2100> lool: oh, ok, so completely freeing line 25, yes?
<lool> 17:54 < lool> sil2100: yes
<lool> 17:55 < lool> sil2100: I've merged into the first landing for l-s
<lool> robru: not sure why it's still there
<lool> robru: silo 3 is for HERE to test (roaming) and the other one I thought I could land, I've tested the branch successfully yesteryda, but the fix is insufficient
<robru> lool: well those are rows 11 and 39, surely 25 is not location-service
<lool> robru: speaking of the rtm one
<lool> robru: it used to be line 25
<robru> lool: well it's not clear to me whether you want to free row 11 or 39
<lool> robru: none of these
<robru> lool: which is the silo which should not be assigned?
<lool> robru: sorry let me start afresh
<lool> robru: there was one rtm landing WIP, we gave up on it and repurposed it; it's now the accunulated location related landings
<lool> so just 1 in rtm, and that's ok
<lool> but finishing some utopic landing firsts
<robru> lool: except that there are two rtm silos assigned for location-service
<lool> robru: hmm this silo 020 is completely new to me
<lool> and I am not sure it will land happily in rtm
<robru> lool: well you'll have to coordinate that with camako then
<robru> lool: more to the point, the two utopic silos you have are not just 'small fix part of mir landing' or whatever. you have two silos for location-service already. are you sure you can't roll this new one into one of the existing ones?
<lool> robru: I dont mind
<lool> robru: we could I guess; just not sure either of them will be stuck
<lool> robru: you see, the startup fix seemed to work but doesn't; am I supposed to take it back?
<lool> or fix it?
<lool> but that might take some time
<lool> and the other one is ready to land too, it was just waiting for another landing to complete
<robru> lool: the problem with having three simultaneous silos for a package like this is that a) there are only so many silos, so other people can't get theirs, and b) whichever one publishes first forces the other two to rebuild, which is time consuming and wasteful
<robru> lool: so if there's any way you can merge the requests I'd appreciate that.
<robru> brb
<lool> oh actually I can do simpler
<lool> snif, or so I thought
<robru> lool: ok, I mean if you really insist on a third silo I can do it, but I'd prefer not to
#ubuntu-ci-eng 2014-10-03
<AlbertA2> trainguards: utopic landing -012 is ready to publish
<kgunn> hmmm for some reason rtm-silo 11 didn't ping here that its ready for QA....and it's wrong on the dashboard too
<kgunn> robru: i think cause i almost accidently built ^ so it's stuck in dashboard on "ready to build"
<kgunn> ToyKeeper: ^ if you're about, silo 11 rtm is ready
<kgunn> for QA
<robru> kgunn: fixed
<imgbot> === trainguards: IMAGE 267 building (started: 20141003 02:10) ===
<robru> kgunn_: that's a new one on me
<kgunn_> robru: oh i bet i forgot to approve the twin mp
<kgunn_> let's do that 1 mo' time
<robru> kgunn_: i doubt it? mps only need to be approved to publish, not to build. the error looks like the debian/watch file is invalid but I checked it and it seems fine.
<kgunn_> huh
<robru> kgunn_: keep in mind citrain was never designed with debian/watch files in mind, you're supposed to use split mode packaging, so...
<kgunn_> robru: split mode packaging ?
<kgunn_> robru: so i'm target building qtmir-gles, should i rebuild all ?
<robru> kgunn_: http://bazaar.launchpad.net/+branch/qtmir/view/head:/.bzr-builddeb/default.conf if you use split mode packaging it creates the tarball by just deleting the debian/ directory and doesn't need to download anything, no debian/watch file necessary. I never understood what you guys were doing with the debian/watch stuff in the -gles packages
<robru> kgunn_: I don't see any reason to rebuild all
<kgunn_> robru: i know even less
<robru> kgunn_: who started all this gles stuff?
<kgunn_> robru: bregma & saviq, b/c desktop gets screwed if we release a new qtmir
<kgunn_> without a sync'd qtmir-gles
<kgunn_> and that pretty much covers my depth of knowledge
<kgunn_> i just know we keep these things in sync
<robru> kgunn_: yeah I don't get why the qtmir source package can't just publish a qtmir-gles binary package, I think the very concept of "keeping source packages in sync" is inherently broken.
<kgunn_> robru: so any ideas?
<robru> kgunn_: not a clue.
<robru> kgunn_: unless you can find a way to merge the source packages ;-)
<kgunn_> :)
<robru> Mirv: up yet?
<imgbot> === trainguards: RTM IMAGE 80 building (started: 20141003 03:10) ===
<kgunn_> robru: so the err is Unable to find the needed upstream tarball for package qtmir-gles, version 0.4.3+14.10.20141002.
<kgunn_> but the ppa is qtmir - 0.4.3+14.10.20141003-0ubuntu1
<kgunn_> is it b/c i'm building on a timezone change ?
<robru> kgunn_: oh, derp, I guess that would do it. rebuilt qtmir I guess?
<robru> kgunn_: no, wait. why does -gles have the older version?
<robru> kgunn_: if qtmir was uploaded first it should have the older version from before midnight, right?
<kgunn_> yeah...that would make sense...so it's from the future :)
<kgunn_> or a jenkins bot that's in the future
<robru> kgunn_: nah your MP just has the wrong version I guess: https://code.launchpad.net/~mir-team/qtmir/gles-sync/+merge/236843 says 2, should say 3
<kgunn_> robru: oh crap zanetti's changelog
<kgunn_> ?
<robru> yeah
<kgunn_> robru: you a baseball fan at all? this royals vs angels game is pretty good
<robru> kgunn_: not me but thanks for the tip
<Mirv> robru: morning!
<Mirv> hmm, we didn't get the unity8 QA'd? there are 3 unity8 landings queued
<imgbot> === trainguards: IMAGE 267 DONE (finished: 20141003 03:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/267.changes ===
<robru> Mirv: oh hey, sent you an email ;-)
<Mirv> robru: the subject of it is promising :)
<Mirv> merge-clean, check
<robru> Mirv: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-007-3-merge-clean/18/console ok, first official merge&clean in production looks promising. any surprise corner-case issues might arise if you need to merge & clean a silo that's only partially published.
<imgbot> === trainguards: RTM IMAGE 80 DONE (finished: 20141003 04:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/80.changes ===
<Mirv> robru: ok, that's quite rare though
<Mirv> good to know
<bzoltan> ToyKeeper:  hello, are you still around?
<ToyKeeper> bzoltan: Just on my way out.  What's up?
<ToyKeeper> I see UITK marked as "under testing" with vrruiz attached, but I haven't been following it closely.
<bzoltan> ToyKeeper:  Yes, I was about to ask the status of the UITK
<bzoltan> ToyKeeper: I will check with vrruiz when he comes online
<Mirv> ToyKeeper: any idea why brendand has two landings in "Passed" column but they are not marked as so in the spreadsheet?
<Mirv> now I'm a bit confused if they're passed or not
<Mirv> the 011 and 002
<robru> Mirv: he was complaining about the spreadsheet earlier
<Mirv> robru: ah, I see, that explains
<Mirv> thanks. I wonder what's up with the spreadsheet then.
<Mirv> or if brendand has ctrl-z stuck :)
<Mirv> robru: nice that you were so supportive of brendand too! ;)
<robru> Mirv: erk. Spreadsheet has been getting worse and it's been stressing me out. We're getting closer to a replacement for it though
<Mirv> I've a theory that it also misbehaves worse for some
<robru> Mirv: I've been trying to rip out nonessential spreadsheet features to reduce the strain on it... Hasn't been going well
<robru> Mirv: the code in the spreadsheet is just a disaster, and it only gets worse
<Mirv> actually, this unity8 is not as simple. possibly also brendand got confused that there was _another_ 011 unity8 landing right after the previous one
<Mirv> brendand: so it'd look so, only now there's a _real_ duplicate in trello ;) the previous one is there on purpose, since it's a new landing in the same silo
<Mirv> but I'm positive that 002 is supposed to be marked as QA passed, unlike the "new" 011
<Mirv> I made the error of trying to fix the pointed by switching to tty1 and back. that triggers a utopic dual mode bug where everything hangs, except that the running processes keep on running. another switch to tty1 then would have hung also the processes, but I knew not to...
<Mirv> s/pointed/pointer/
<Mirv> the same hang also happens if I detach the second monitor
<sil2100> Argh
<sil2100> Yeah, even today I got this dual mode bug that hanged my PC earlier
<Laney> report it?
<rsalveti> ted: I'm trying to land, but still stuck in the queue, needs to be approved by an archive admin, since we're in freeze
<bzoltan> brendand:  do you know if the UITK will land today?
 * sil2100 off to lunch
<brendand> bzoltan, almost there
<brendand> bzoltan, will land today for sure
<dbarth> trainguards, hi: i have line 74 (silo utopic 16) tested now; can you make it land?
<dbarth> trainguards, also: silo utopic 14 is blocked in release by an UNAPPROVED queue; can you help?
<dbarth> this prevents us from pushing more webbrowser-app fixes
<cjwatson> dbarth: trainguards cannot help you
<cjwatson> unapproved queue => release team
<cjwatson> but I will have a look
<dbarth> cjwatson: hi; ah, we're in freeze already?
<cjwatson> yes, until release
<dbarth> indeed
<dbarth> we're lining up further changes for webbrowser-app (more specifically webapp-container)
<cjwatson> accepted
<Mirv> dbarth: 016 published
<dbarth> thank you guys
<bzoltan> brendand: good to hear. Thank you.
* josepht changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: josepht | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all silo assignment/reconfigure failures today.
<kenvandine> brendand, can you confirm line 87 qualifies as an isolated bug fix?  it quiets a build time warning and fixes a crash when entering the storage page and backing out quickly
<kenvandine> nothing else
<brendand> kenvandine, can i see the diff?
<kenvandine>  
<kenvandine> https://code.launchpad.net/~laney/ubuntu-system-settings/lp1375988/+merge/236934
<kenvandine> brendand, and the build warning fix is https://code.launchpad.net/~laney/ubuntu-system-settings/security-privacy-link-gobject/+merge/236938
<brendand> kenvandine, ok
<brendand> kenvandine, you can swap your name for mine next to N/A
<kenvandine> thx
<pmcgowan> robotfuel, colin seems to have signed off on that glib fix, what else do we need to do? jfunk ?
<robotfuel> davmor2: brendand ^
<brendand> pmcgowan, let us do a sanity check on it and get it signed off before EOD
<pmcgowan> brendand, ok let me know if you need anything thanks
<Laney> I wrote a mini test plan for glib by the way
<Laney> https://wiki.ubuntu.com/Process/Merges/TestPlan/glib2.0
<pmcgowan> brendand, ^^ thanks Laney
<oSoMoN> trainguards, can I haz a (utopic) silo for line 66, pretty please?
<oSoMoN> err, line 65
<oSoMoN> (and a 14.09 silo for 66, if possible)
<Mirv> oSoMoN: done, except rtm which waits for 004 to land first
<oSoMoN> Mirv, thanks!
<sil2100> grrr
<fginther> sergiusens, is there a recommended way to handle build dependencies when building click packages with click schroots?
<sergiusens> fginther: no, there aren't supposed to be "build" dependencies in clicks; I mean, the only dep is the framework
<sergiusens> fginther: everything else should be part of the click
<sergiusens> fginther: maybe a better option is to log bugs for those offending clicks
<dbarth> sil2100: heads up; the apparmor extension impacts the youtube scope; better not make an image just yet
<dbarth> (the one that just landed on rtm)
<fginther> sergiusens, thanks. updated frameworks get created overtime, right? And are those provided via the 'click' package?
<sil2100> dbarth: ok, any ETA for the youtube landing?
<sergiusens> fginther: yes, click -f [framework] -a[arch] chroot create
<jdstrand> sil2100: it introduced a new apparmor denial. I am preparing a fix new
<sergiusens> fginther: new debs of click bring in the new frameworks
<sergiusens> fginther: during a development phase, the framework has a -devX appended to track the changes to the framework under development
<fginther> sergiusens, can developers request adding content to the framework? how is that done?
<sergiusens> fginther: you need to offer a stable interface, can't break abi or api after it's in and take it to lool
<fginther> sergiusens, thanks
<sergiusens> fginther: but it's basically a "seed" change
<sergiusens> np
<dbarth> sil2100: it takes an apparmor change; otherwise, we could revert signong-apparmor-extension
<dbarth> which is slightly annoying since it just reached destination...
<davmor2> sil2100: https://bugs.launchpad.net/account-plugins/+bug/1349975 by the way needs tagging for user facing (not blocker) already in the image
<ubot5> Ubuntu bug 1349975 in Online Accounts: Account plugins "OAuth based plug-ins appear to crash under poor network connectivity" [High,Triaged]
<fginther> lool, what are the expectations around build tools inside the click frameworks? If a project wants to use something that's not already in there (such as the go build tools) can that be added?
<jdstrand> I'll have an update soon
<cjwatson> fginther: I think we should add some kind of build-dependency support.  It's not scalable to keep adding everything to the base chroot.  In the meantime you can perhaps use the session support of click chroot.
<cjwatson> There's no reason for build-dependencies to have quite as strict keep-it-simple rules as runtime dependencies.
<fginther> cjwatson, thanks, I'll give that a try. And maybe have more input on build dependencies in a couple weeks
<jdstrand> davmor2: fyi, bug #1377221
<ubot5> bug 1377221 in apparmor-easyprof-ubuntu (Ubuntu) "clipboard denial" [Critical,In progress] https://launchpad.net/bugs/1377221
<jdstrand> davmor2: meant to paste tha tin the other channel
<davmor2> jdstrand: no worries :)
<davmor2> sil2100: another one for you ^
<sil2100> Aw come ooon
<sil2100> davmor2, brendand, robru: be right there
<sil2100> Browser issues
<brendand> dbarth, did i miss an issue with signon-apparmor-extension?
<dbarth> brendand: not on the test plan though; but yeah
<dbarth> brendand: the youtuibe scope is affected by the extension being in place
<brendand> dbarth, i don't think the testing done in this case or test plan provided was satisfactory then
<dbarth> nope
<dbarth> jdstrand: i would vote for reverting the change right now, and land once we can verify more client applications are ready
<dbarth> wdyt?
<dbarth> sil2100: i assume that you have tools to make a package revert not too painful
<brendand> dbarth, at least online-accounts test plan should have been mentioned
<sil2100> dbarth: yes, what package would you want me to revert?
<dbarth> sil2100: signon-apparmor-extension
<sil2100> Sure - but will a revert help? Or will we need to remove it from the image?
<dbarth> brendand: https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings-online-accounts ?
<dbarth> brendand: i ran most of that, but that would not even have caught it
<dbarth> sil2100: remove from image i think
<dbarth> sil2100: do you have an image to roll out soon?
<brendand> dbarth, so if you ran it why didn't you say in the test plans field?
<brendand> dbarth, please - QA *need* to know what testing you've done!
<dbarth> cause i test account settings every time i land sometihng OA
<dbarth> in that case, we haven't done a good job of assessing the impact of the change
<brendand> dbarth, if you list the OA test plan then it helps indicate that the impact of the change could be throughout the entire domain of that component
<brendand> dbarth, if you list bug fixes or mention single test cases then it gives the message that the change is limited in scope/impact
<dbarth> brendand: and honestly that's what we thought
<dbarth> so wrong...
<brendand> dbarth, if you didn't run the OA test plan because you didn't think it was necessary, well that's an oversight, but if you do run it then please list it in the test plan field
<brendand> dbarth, so my point is not about that so much as communication
<dbarth> brendand: ok, nw, i will mark it more systematically when i do
<brendand> dbarth, thanks
<dbarth> jdstrand: are you onboard with the revert request above ^^?
<jdstrand> dbarth: well, it needs to land sometime soon. if that is a revert, then land soon, that's fine with me. fyi, I'll be uplodaing apparmor-easyprof-ubuntu after I finish testing
<dbarth> jdstrand: i want to land it as well; just want to avoid a week-end with a broken image
 * jdstrand nods
<jdstrand> I'll leave it as your call. I only care that it lands before 2014-10-09
<dbarth> jdstrand: mardy has more fixes ready to re-load a silo on monday
<dbarth> jdstrand: +1 for 10-09 yes
<dbarth> before 10-09 even
<dbarth> sil2100: so, it's confirmed, we'd like the package out of the next image, and preferably have that image rolled out asap, to avoid more issues during the week-end
<dbarth> sil2100: actually, since it just landed on RTM, i think that the last RTM image should be fine
<sil2100> dbarth: let me get back to you after I'm finished
<dbarth> sil2100: utopic should be the only one affected
<dbarth> ok, nw
<robru> sil2100: what's the scoop today? You ready to land your publish changes so I can rip out the json stuff?
<cwayne> josepht: hiya, is it at all possible to get a node up on s-jenkins that i can ssh into and experiment with click chroots?
* josepht changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Please inform robru of all silo assignment/reconfigure failures today.
<josepht> fginther: are we able to do what cwayne is asking for?
<fginther> josepht, cwayne, yeah I think I figured out a way to do this for now
<cwayne> fginther: so i think there's something up with the click chroot on exp-slave, as I copied what i have for the job onto my local machine and it works perfectly :/ so I was wondering basically if i could have a node so i could try to make a new chroot and play around with it without polluting yours
<fginther> cwayne, just let me get this configured and I'll let you know the details
<cwayne> fginther: thanks
<robru> sil2100: around?
<sil2100> robru: yeah, I'll get back to you in a moment
<robru> ok
<pstolowski> trainguards, may i ask to resync and rebuild ubuntu-rtm/landing-018?
<robru> pstolowski: what do you mean by resync?
<robru> pstolowski: you just landed a new package in utopic, right>
<robru> ?
<pstolowski> robru, yes, it landed in utopic, but u-rtm/018 has an old version built
<pstolowski> robru, btw, 'reconfigure' link doesn't work for me (points to non existing page)
<robru> pstolowski: right you don't need to reconfigure since you're not changing the source packages being synced. just running the build job is fine, it find the new version and re-copies it.
<robru> so i did that for you, I don't understand the error it's getting, but the new package is in the silo anyway
<robru> so go ahead with testing that
<pstolowski> robru, ok, thanks
<rsalveti> cjwatson: what is the ideal way to update the seeds for the rtm branch?
<robru> pstolowski: not sure what you mean by "points to non-existing page", just clicked it, works fine for me. You have to click the 'Proceed' button there. But don't actually do it because it's not necessary in this case
<rsalveti> I saw people just doing binary copies but afaik you were the one suggesting not to do that last time ogra_ did the package sync
<pstolowski> robru, i'm getting redirected to u1 "lost something?" page
<robru> uh
<robru> u1? are you signed in?
<ogra_> rsalveti, for meta uploading to utopic and once it migrated into the main acrchive binary copy into 14.09-proposed is the right thing
<pstolowski> robru, ah, by bad, noscript is blocking that
<robru> ok
<rsalveti> ogra_: oh, great then
<rsalveti> thought that could cause dependency issues
<rsalveti> because the archive is not exactly the same
<ogra_> rsalveti, it did in the past ... they are fixed now
<rsalveti> awesome :-)
<ogra_> and we want the extra shielding of -proposed for new ones that might show up (because you might add something not in rtm)
<davmor2> ogra_: get out of here you are meant to be unifying
<davmor2> ogra_: go unify ;)
<ogra_> davmor2, done, i'm so united, cant be more :P
<davmor2> ogra_: hahahahaha
<sil2100> ogra_: oh my, done unifying?!
<ogra_> yeah :)
<sil2100> And I bothered poor rsalveti when I could have bothered poor-but-used-to ogra_
<rsalveti> sil2100: no worries, I also thought ogra_ would be off already
<rsalveti> trying to find another german to hug
<ogra_> i was off all day !
<sil2100> hahah
<sil2100> ;)
<davmor2> sil2100: yeah but come on saying rsalveti I know ogra broken this but could you have a look doesn't really count
<ogra_> (well, kind of, as i set up my new router (finally) ... these alix devices are the best since sliced bread !)
<sil2100> robru: so, I might still be able to land this, today's testing revealed some problems so I've been fixing those
<ogra_> whats broken ?
<sil2100> Might still be able to finish before my EOD
<robru> sil2100: ok, no worries. I have tons of time to do what I need, no rush
 * ogra_ reads backlog 
<sil2100> ogra_: so we decided to back out the signon-apparmor-extension from the seeds
<ogra_> sil2100, fine by me, doesnt come from me :P
<ogra_> mvo added it
<sil2100> ogra_: some parts of the issues it caused got fixed, but I guess there are still some problems left
<sil2100> Yeah ;)
<sil2100> We know
<sil2100> So dbarth will most probably resolve all those around Monday
<ogra_> cool
<ogra_> so i guess we'll try re-adding on tue
<sil2100> Once it gets removed from the seed, we'll need a new ubuntu-rtm image
<sil2100> Yeah
 * ogra_ wonders if anyone else sees apps hanging and crashing randomly on image 80 
<dbarth> apologies for the issues
<sil2100> No worries :)
<dbarth> we're assessing the rest of the clients that are affected
<dbarth> this gives us a good map of the other silos / branches we need lined up next
<jdstrand> davmor2, dbarth, cwayne: fyi, uploaded apparmor-easyprof-ubuntu 1.2.33 to utopic
<dbarth> jdstrand: thanks; that will help getting more calls through
<dbarth> sil2100, ogra_; i'm staying around for the evening, just in case you need me
<davmor2> jdstrand: man you're on fire :)
<jdstrand> heh
<cjwatson> rsalveti: yeah, I fixed the problems that were necessitating force when doing the copy.  for the record even at the time I wasn't suggesting not to do a binary copy, I was suggesting not to copy directly into 14.09 rather than 14.09-proposed (for those with privileges to copy to the former)
<rsalveti> cjwatson: got it, thanks :-)
<sil2100> robru: ok, it's late here I don't feel comfortable enough to merge this in today yet - you can change the silo_config bits to SiloState in publish and I'll just rebase on Monday
<sil2100> robru: if you could leave the overall structure intact then it would be awesome
<sil2100> robru: I pushed the branch to LP so you can check the refactoring
<robru> sil2100: ok I'll keep it simple, thanks
<robru> sil2100: feel free to revert me since it's my last day before vacation ;-)
<sil2100> robru: I didn't push the prepare_silo.py bits yet as I didn't commit those
<robru> sil2100: oh, how do you test publisher? is it the case that preprod silos can't publish to distro?
<sil2100> robru: but the more-or-less updated version can be seen here: https://code.launchpad.net/~sil2100/cupstream2distro/cu2d-duallanding-new
<sil2100> robru: I was only testing publishing to PPA's, but I also did one test with hacking the publish job to not 'copy' the rsync file
<sil2100> robru: in that case I could check if the rsync file was generated properly without it getting moved to snakefruit
<robru> sil2100: ah ok, never used DEST before, funny that ;-)
<sil2100> Anyway, it's a very risky piece of code to test, that's why I don't feel comfortable with landing it on Friday yet ;p
<robru> sil2100: yeah curse fridays, worst day to land anything ;-)
<ogra_> rsalveti, did you trigger an rtm image already ?
<ogra_> (seems -meta landed everywhere)
 * ogra_ triggers a build 
<rsalveti> ogra_: not yet, was waiting the migration
<ogra_> well, it is building now
<rsalveti> ogra_: great :-)
<rsalveti> was busy eating a huge steak
<kenvandine> i want some!
<rsalveti> yeah, would be nice to do some south american barbecue during the sprint :-)
 * ogra_ will do some brasilian barbecue on tue.
<rsalveti> awesome
<ogra_> there seem to be a churrasacaria next to the hotel :)
<imgbot> === trainguards: RTM IMAGE 81 building (started: 20141003 20:25) ===
 * ogra_  goes afk again
<imgbot> === trainguards: IMAGE 268 building (started: 20141003 20:30) ===
<ted> rsalveti, Are you planning to land the sound modes silo soon? Would like to start queuing up some other sound stuff on Monday.
<rsalveti> ted: landed that today, just waiting the next image to validate it properly
<ted> Hmm, why didn't the MR get marked?
<ted> rsalveti, Doesn't seem to be merged
<rsalveti> ted: hm, guess the clean step might have failed, let me merge that by hand
<ted> rsalveti, I think we can just push https://code.launchpad.net/~ps-jenkins/indicator-sound/ubuntu-utopic-proposed to trunk.
<rsalveti> ted: yeah
<rsalveti> ted: let me take care of that
<ted> rsalveti, K, thanks!
<oSoMoN> robru, hey, can (utopic) silo 14 be published, please?
<robru> oSoMoN: done
<oSoMoN> robru, thanks! (note that the packaging changes were already reviewed and acked by kenvandine)
<robru> oSoMoN: cool, they seemed trivial anyway
<robru> AlbertA: there's already a dbus-cpp rtm sync in silo rtm1 (along with some other stuff)
<AlbertA2> robru: rtm landing-001?
<robru> yes
<AlbertA2> robru: I'm coordinating with tvoss...
<AlbertA2> robru: he's in and out...
<AlbertA2> robru: can you ignore that landing for now?
<robru> AlbertA2: well you can't both copy the same version of dbus-cpp to rtm, that makes no sense.
<AlbertA2> robru: he'll probably request a reconfig
<AlbertA2> robru: when he's fully back
<AlbertA2> robru: as we already sync'ed it once for media hub fixes
<robru> ok
<robru> AlbertA2: ok you got rtm9
<AlbertA2> robru: thanks!
<robru> AlbertA2: you're welcome
<imgbot> === trainguards: IMAGE 268 DONE (finished: 20141003 22:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/268.changes ===
<imgbot> === trainguards: RTM IMAGE 81 DONE (finished: 20141003 22:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/81.changes ===
<ToyKeeper> I wonder if anyone is still around.
<ToyKeeper> More specifically, I wonder if anyone has filed a bug for the UI locking at random times and getting un-stuck by switching to another app and back.
<ToyKeeper> Jeez...  if even imgbot thinks it's time to go home, perhaps I should start my weekend.  ;P
<boiko> robru: I am trying to reconfigure rtm silo 3, but it is failing
<ogra_> ToyKeeper, haha ... if you file that bug i'll confirm, i saw it too
<robru> boiko: what's the failure? have a log?
<ogra_> (imgbot is a bit unhappy with me rebooting my router ... it will be back soon :) )
<robru> boiko: are you getting an HTTP400 from google when clicking that link? no idea why, anyway that's just google's redirecter thing being stupid, it's possible to extract the real URL from that URL and run it through a urldecoder, try this link:
<robru> https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-003-0-reconfigure/buildWithParameters?REQUEST_ID=1411690437729&DISTRIBUTION=ubuntu-rtm&SERIES=14.09&LANDERS=bfiller&MERGE_PROPOSALS=https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Fdialer-app%2Fsim-lock%2F%2Bmerge%2F236024%20https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Ftelephony-service%2Fsim-lock%2F%2Bmerge%2
<robru> F235505%20https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Ftelepathy-ofono%2Fsim-lock%2F%2Bmerge%2F235506%20https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Ftelepathy-ofono%2Frefresh-emergencynumbers%2F%2Bmerge%2F237076%20https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Fmessaging-app%2Finformation-messageType%2F%2Bmerge%2F235860%20https%3A%2F%2Fcode.launchpad.net%2F~
<robru> tiagosh%2Fhistory-service%2Finformation-messageType%2F%2Bmerge%2F235859%20https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Fmessaging-app%2Fupdate-bottom-edge%2F%2Bmerge%2F235210%0Ahttps%3A%2F%2Fcode.launchpad.net%2F~aacid%2Fdialer-app%2Faddi18ntr%2F%2Bmerge%2F235920%0Ahttps%3A%2F%2Fcode.launchpad.net%2F~boiko%2Ftelephony-service%2Femergency_calls_flight_mode%2F
<robru> %2Bmerge%2F236436%0Ahttps%3A%2F%2Fcode.launchpad.net%2F~boiko%2Fdialer-app%2Ffix_calling_emergency_numbers%2F%2Bmerge%2F236434%0Ahttps%3A%2F%2Fcode.launchpad.net%2F~boiko%2Fdialer-app%2Fupdate_header_label%2F%2Bmerge%2F236573%20https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Fmessaging-app%2Fsim-lock%2F%2Bmerge%2F236595%20https%3A%2F%2Fcode.launchpad.net%2F~tia
<robru> gosh%2Fmessaging-app%2Ffix-image-preview%2F%2Bmerge%2F236918%20https%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Fmessaging-app%2Fheader-visibility%2F%2Bmerge%2F237075%20%0Ahttps%3A%2F%2Fcode.launchpad.net%2F~tiagosh%2Ftelepathy-ofono%2Fsms-timestamp%2F%2Bmerge%2F237148%0Ahttps%3A%2F%2Fcode.launchpad.net%2F~boiko%2Fdialer-app%2Fship_icon%2F%2Bmerge%2F237149%0Ahtt
<robru> ps%3A%2F%2Fcode.launchpad.net%2F~boiko%2Fmessaging-app%2Fship_icon%2F%2Bmerge%2F237152&SOURCES=&SYNC_REQUEST=&delay=0sec
<robru> hmmm, ;-)
<robru> boiko: http://bit.ly/1vASjhQ try this link ;-)
<Ursinha> ogra_: imgbot is in your local machine?
 * ToyKeeper *blink* ...  don't let the HTTP GET cops see that, robru
<ogra_> Ursinha, imgbot is a few shellscripts ... yes, we'll need a proper solution some day, but that needs a proper backend first
 * ogra_ thinks that would be a good sprint topic ;) 
<ToyKeeper> ogra_: I think this is it: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1377332
<ubot5> Ubuntu bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [Undecided,New]
<ogra_> ToyKeeper, hmm, sounds like a duplicate of bug 1375215
<ubot5> Error: Could not gather data from Launchpad for bug #1375215 (https://launchpad.net/bugs/1375215). The error has been logged
<ogra_> bah, what a mess... that got duplicated against a private bug
<boiko> robru: it works, thanks
<robru> boiko: you're welcome! I can only assume that error with the link is some transient google error... was working fine for me yesterday
<boiko> robru: yep, it was working for me too
<robru> boiko: I wonder if it's length-related... *sigh*
<boiko> robru: :)
#ubuntu-ci-eng 2014-10-04
<imgbot> === trainguards: IMAGE 269 building (started: 20141004 02:10) ===
<rsalveti> robru: around?
<robru> rsalveti: not really but kinda. What's up?
<imgbot> === trainguards: RTM IMAGE 82 building (started: 20141004 03:10) ===
<imgbot> === trainguards: IMAGE 269 DONE (finished: 20141004 04:00) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/269.changes ===
<imgbot> === trainguards: RTM IMAGE 82 DONE (finished: 20141004 04:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/82.changes ===
<ogra_> bah, the return of the white stripe (on the left side of the krillin screen)
 * ogra_ files bug 1377427
<ubot5> bug 1377427 in unity8 (Ubuntu) "white 1 pxel line on left edge of the screen since RTM image 81" [Undecided,New] https://launchpad.net/bugs/1377427
<ogra_> (i know we had one bug like that which was closed, but i cant find it anymore)
<olli_> hey, what am i doing wrong if after apt-add-repository ppa:ci-train-ppa-service/landing-004 and apt-get update I am not getting packages of that ppa (on krillin that is)
<ogra_> olli_, is that rtm ?
<olli_> hey ogra_
<olli_> yeah, figured it out
<ogra_> ah, good :)
<olli_> wrong distribution / version in sources.list
<olli_> good problems to have at 7am on a Saturday ;)
<ogra_> haha
#ubuntu-ci-eng 2014-10-05
<imgbot> === trainguards: IMAGE 270 building (started: 20141005 02:10) ===
<imgbot> === trainguards: RTM IMAGE 83 building (started: 20141005 03:10) ===
<imgbot> === trainguards: IMAGE 270 DONE (finished: 20141005 03:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/270.changes ===
<imgbot> === trainguards: RTM IMAGE 83 DONE (finished: 20141005 04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/83.changes ===
#ubuntu-ci-eng 2015-09-28
<sil2100> jibel, Mirv, davmor2: you guys want to have the meeting today? ;)
<jibel> sil2100, no
<jibel> good morning :)
<sil2100> Morning!
<sil2100> Mirv: anything to discuss from your side?
<Mirv> sil2100: nothing in particular. seeing you folks is nice of course, but if there's nothing to discuss... :)
<oSoMoN> trainguards: can the i386 and amd64 builds of webbrowser-app be re-tried in silo 46 (for both series) ?
<sil2100> oSoMoN: sure
<oSoMoN> thanks!
<oSoMoN> jibel, Iâm rebuilding silo 46 with an additional bug fix, it is currently marked as ready for QA in the trello board but Iâll need to revalidate it quickly before itâs actually ready
<jibel> oSoMoN, okay, just add a comment on the card
<sil2100> Done
<oSoMoN> ok
<jibel> oSoMoN, otherwise, remove the status "ready for QA" in bileto and a card will be recreated when you change it to ready again
<oSoMoN> jibel, I just added a comment, hopefully this will be quick enough that it isnât picked up by a QE in the meantime anyway
<oSoMoN> if it turned out to be more time-consuming than I expected, Iâd update the status in bileto
<Mirv> oSoMoN: looks ok now, I'm running watch_only on 46
<oSoMoN> Mirv, thanks
<jibel> sil2100, does phablet-tools has to land in the overlay, shouldn't it be an SRU in vivid?
<jibel> sil2100, silo 51
<jibel> for reference
<sil2100> jibel: from what I know we had a discussion where phablet-tools should be landing
<jibel> sil2100, and the conclusion was to land in the overlay,
<jibel> s/,/?/
<Mirv> jibel: + SDK PPA copy after that, me/bzoltan can handle that
<jibel> Mirv, my question was more how do we decide if a package not seeded on the phone goes to the overlay or should be an SRU? in this case phablet-tools.
<Mirv> jibel: good questoon... SRU would be the best, although fpr dev tools SDK PPA os just as fine. overlay is unneeded for phablet-tools really, could be just wily too.
<Mirv> -typos, walking to lunch. damn ubuntu-keyboard! :)
<jibel> morphis, ^ about silo 51. you can land in wily and the SDK PPA. unless there is a reason I miss to land it in the overlay too.
<morphis> jibel: ok
<morphis> jibel: I think overlay isn't needed
<Mirv> morphis: do you want to still do something with 051 or should it be published?
<morphis> Mirv: no, can be published
<Mirv> morphis: ok, I'll just modify it to be wily only
<morphis> Mirv: great
<Mirv> morphis: nice fixes, appreciated!
<Mirv> and thanks to QA too
<morphis> Mirv: yeah, was really time to get this tool improved
<oSoMoN> jibel, FYI, silo 46 is now ready for QA validation again (I commented on the trello card)
<Mirv> bzoltan_: FYI copying latest phablet-tools for vivid and trusty to SDK Release PPA
<Mirv> bah
<rvr> abeato: Take a look to my comments at https://trello.com/c/BWPvIkY7/2276-269-ubuntu-landing-055-qtubuntu-media-media-hub-jhodapp
<bzoltan_> Mirv:  thank you
<sil2100> slangasek: hey! Could you merge in a system-image branch for me?
<sil2100> slangasek: https://code.launchpad.net/~sil2100/ubuntu-system-image/server-fix-pd-builds/+merge/272445
<sil2100> jibel: ugh, just now I noticed that I answered on a completely unrelated channel, yes, it's like Mirv said ;p geez...
<jibel> sil2100, heh
<sil2100> barry: hey! Could you merge in https://code.launchpad.net/~sil2100/ubuntu-system-image/server-fix-pd-builds/+merge/272445 ? Added changes as per your comment ;)
<barry> sil2100: sure, i can merge it, but i can't publish it.
<sil2100> barry: I'll publish it, no worries :)
<barry> sil2100: i made one minor change to the comments, and i'm running the tests locally.  if they pass, i'll commit and push
<barry> pep8 unhappiness :(
<sil2100> Worked fine here ;)
<sil2100>   fast-py34: commands succeeded
<sil2100>   congratulations :)
<sil2100> PEP8 is not ran as part of this test-suite?
<barry> sil2100: it is apparently when you run `tox`
<sil2100> What made it unhappy?
<barry> sil2100: it's a bunch of the bin scripts and some of the lib/systemimage/testing modules.  i will look at fixing them before i push your branch
<sil2100> But I didn't touch those now did I?
<barry> sil2100: nope
<barry> so clearly the test suite isn't getting run much ;)
<sil2100> ;)
<sil2100> I'm just running the fast ones, though that runs everything
<sil2100> barry: hmm... just checked and it looks like fast-py34 also runs PEP8 tests and it doesn't say anything on my local machine
<barry> sil2100: well, that's interesting
<barry> sil2100: wonder if it's a wily thing?  are you running 15.10?
<sil2100> 15.04 still, maybe that's it?
<sil2100> test_pep8_clean (systemimage.tests.test_static.StaticTests) ... ok
<barry> sil2100: possibly.  but pep8 is the only failures so they should be easy to fix.  i will commit and push your branch, and then do another pep8 fix branch next
<barry> sil2100: weird!
<sil2100> Thanks, I'll try to publish it at s-i :)
<barry> sil2100: merged
<nerochiaro> cihelp: is it just me or is jenkins taking forever to run tests on merge requests today ?
<dbarth_> o/ hi, i need a trainguard to retry a ppa build failing on a unit test on wily (silo 025)
<sil2100> dbarth_: on it!
<sil2100> Webbrowser?
<dbarth_> the i386 and amd64 builds namely; armhf passed already
<dbarth_> sil2100: yeah
<sil2100> Rebuilding itself
<rvr> alf_: kgunn: Approving silo 28
<kgunn> rvr: thanks ....we've got another landing right behind that one :)
<fginther> nerochiaro, there are a couple of makos offline. If you're MPs rely on mako testing, that is likely the problem... Assuming they aren't dead for good, they should be up again soon.
<nerochiaro> fginther: ok. so if they come back up, i don't need to restart the jobs, they will be taken care of
<nerochiaro> ?
<awe_> sil2100, cyphermox, question about NM wily landing ( 010 ); it's currently in the UNAPPROVED queue; can one of you explain?  Is there any action needed for me or cyphermox to move fwd?
<cyphermox> awe_: no actions from you
<sil2100> awe_: wily is now in manual-approve mode
<cyphermox> it's up to an archive admin to review, I already mentioned it to infinity.
<fginther> nerochiaro, correct. In most cases the devices take themselves offline so as not to impact builds and jobs will just wait until a device is available
<awe_> thanks guys
<nerochiaro> fginther: thanks
<awe_> and thanks for the help fri afternoon cyphermox!
<cyphermox> yes
<cyphermox> awe_: NM should be top notch on the phone.
<fginther> nerochiaro, in a few cases, the devices can fail in the middle of a test in which case it will need to be restarted. These will appear as a failed jenkins job.
<awe_> cyphermox, well...we need to land all those changes to the overlay PPA next.  ;)-
<cyphermox> yes, of course.
<awe_> but yes, it continues to improve
<nerochiaro> fginther: also i am having an hard time figuring out what is wrong with the mako failures in thir MR: https://code.launchpad.net/~uriboni/webbrowser-app/topsite-previews/+merge/269771 - i have been told some tests timeout causing the whole to timeout, but that doesn't help me figure out what is actually causing the initial problem
<fginther> nerochiaro, I can't help much on those test failures. The device was provisioned successfully with ubuntu-touch/rc-proposed/ubuntu image 241, the packages from the MP were installed, and the screen was unlocked to run the tests. That's about as far as I can diagnose.
<nerochiaro> fginther: do you know who might be able to help ? to be clear: i don't need help in fixing the tests, but in figuring out which one is making the whole CI run choke
<nerochiaro> fginther: as I understand it, it should not happen. tests that fail should not make the whole fail
<fginther> nerochiaro, Maybe I'm ansering the wrong question. Why wouldn't a failing test not make the whole thing fail? Do you expect CI to mark this MP as PASSED instead of FAILED?
<fginther> nerochiaro, you can also follow the instructions here for re-creating the CI testing locally: http://ubuntu-test-cases-touch.readthedocs.org/en/latest/
<fginther> nerochiaro, testing of MPs is specifically covered here: http://ubuntu-test-cases-touch.readthedocs.org/en/latest/#provisioning-and-executing-autopilot-tests-for-an-mp
<nerochiaro> fginther: i would expect it to mark the failing AP test as failed, but not the majority of AP tests as failed (108 over 150, which were passing in previous runs). but I will try your suggestion and see what I can reproduce locally
<fginther> nerochiaro, Ah, I understand. One failure should not impact the other tests in this case... One thing to aware of is that CI is running both the webapp_container and webbrowser_app tests, with the webapp_container tests running first
<nerochiaro> fginther: i'll keep that in mind
<sil2100> kgunn: hey! Can you approve https://code.launchpad.net/~unity-system-compositor-team/unity-system-compositor/0.1/+merge/272394 ?
<robru> Mirv: can you copy a vivid version of phablet-tools to https://launchpad.net/~phablet-team/+archive/ubuntu/tools please?
<ogra_> robru, why cant you ?
<ogra_> arent you in phablet-team ?
<ogra_> as the quasi maintainer of phablet-tools you should really be i think :)
<robru> ogra_: well somebody deleted the vivid version of the package that I built then published & freed the silo, so...
<robru> ogra_: it's not about permissions it's about "please rebuild the package you deleted"
<ogra_> ah :)
<boiko> robru: any idea on what went wrong here: https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/107/console
<robru> crap
<robru> boiko: hang on
<renatu> robru, what I need to do to get the debug packages for a specific silo available on apt
<robru> boiko: ok I pushed a fix, should be live in 5 minutes.
<robru> renatu: not sure, ask infinity
<boiko> robru, thanks
<robru> boiko: ok try it now
<boiko> robru: now it said the silo is dirty, that I need to rebuild messaging-app, I don't remember anything landing in there
<robru> hmmm
<boiko> robru: or at least it was not showing the silo dirty message when I first tried to publish it
<robru> boiko: yeah, that's a known bug, if the silo is dirty and you rebuild only part of the silo it will report 'packages built' even though the silo is technically dirty. I'm just trying to find why it thinks it's dirty
<boiko> robru: ah ok, well, the last package rebuilt there was messaging-app anyways
<renatu> Ursinha, do you know how I can make the silo/ppa debug packages available on apt list?
<robru> boiko: https://ci-train.ubuntu.com/job/cyphermox-test/1160/console your changelog seems to be missing v 0.1+15.10.20150923.1-0ubuntu1 which is in wily, apparently you never rebuilt since publishing whatever silo that came from on spet 25)
<robru> boiko: so it seems no mistake, you really do need to rebuild.
<boiko> robru: oups, ok, my bad then
<boiko> robru: yep, sorry about that
<robru> boiko: no worries, glad this check saved us from clobbering your previous release ;-)
<boiko> :)
<dobey> trainguards: can someone please cancel all the builds for https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+sourcepub/5415761/+listing-archive-extra ? seems the tests are hanging for some reason :(
<robru> dobey: on it
<robru> dobey: ok done
<dobey> robru: thanks
<robru> you're welcome
<tedg> robru: Do you by change have a script that copies source package from one repo to another?
<tedg> by chance
<robru> tedg: nope I just use the LP web interface when I need to do that
<robru> tedg: IIRC there's a copy-package tool in some kind of archive-tools repo though
<robru> tedg: yeah https://launchpad.net/ubuntu-archive-tools
<tedg> robru: Cool, thanks!
<robru> tedg: you're welcome
#ubuntu-ci-eng 2015-09-29
<robert_ancell> I'm trying to land https://requests.ci-train.ubuntu.com/#/ticket/405 into the overlay PPA. Do I click publish myself or do I need someone to do that?
<bregma> robru^
<robru> robert_ancell: you can probably do it
<robert_ancell> robru, ok, trying. Thanks.
<robert_ancell> robru, do I need to do anything to close that silo now?
<robru> robert_ancell: nope, it's done
<robru> unless the merge fails for some reason
<robru> oh there's no merge
<robru> so it's fine then
<robru> robert_ancell: wait why did you put xorg through a silo? I don't understand a) why that's needed in overlay and b) why you published without QA.
<robert_ancell> robru, it's XMir for the libertine work. They needed it in the overlay PPA - the only process is through silos right? As it's not used anywhere else I just asked the libertine guys to confirm if this version was better than what they had.
<robru> robert_ancell: oh ok, as long as it's not seeded in the phone (yet) I guess that's fine
<robert_ancell> robru, cool. Thought I'd done something wrong there!
<robru> robert_ancell: technically you could just dput directly to the overlay PPA, I don't think using a silo actually did anything meaningful for you here
<robert_ancell> robru, we wanted the silo so people could test before we committed to putting it in there
<robert_ancell> I guess we were just using the CI train as a PPA provider
<robert_ancell> But good practise when this becomes a supported feature.
<robru> robert_ancell: ok no worries then. I just find it strange when people use silos without MPs, in my mind the whole value of the silo is the auto-merging of MPs.
<robert_ancell> Yeah, understood.
<robru> oh god
<robru> I thought I fixed it so it wouldn't spam the channel at startup
<robru> Mirv: watch out for diffs today, i redid the diffing logic from scratch. Should fix the bug where oxide-qt couldn't be diffed but everything else should behave identically, please ping me if anything is different or unusual.
<Mirv> robru: ok
<Mirv> robru: do you think someone still actually uses https://launchpad.net/~phablet-team/+archive/ubuntu/tools ? the phablet-tools is at https://launchpad.net/~ubuntu-sdk-team/+archive/ppa for vivid + trusty which all devs probably use
<Mirv> robru: but no cost either, so I copied from the SDK PPA
<robru> Mirv: tools ppa is the one i use and the only one i ever updated ;-)
<robru> Mirv: am i the only one using it? Yikes
<robru> Mirv: people must be using tools ppa because there were bugs in citrain tool that i fixed and only copied there, nowhere else.
<Mirv> robru: hehe, so many PPA:s :) well at least anyone doing apps would have SDK PPA in use.
<Mirv> robru: I know, many do have the phablet tools PPA in use from the old times too, and not all of them use our SDK so...
<robru> Mirv: yeah citrain tool used more by Canonical people, it's not really relevant for community app devs
<robru> Mirv: oh apparently there is an oxide in silo 21 ^ so I'm just regenerating diffs to be sure
<Mirv> robru: ok!
<robru> Good god it takes forever to diff
<robru> Damn! Still didn't work
<robru> At this point i wonder if debdiff itself is the problem
<robru> Mirv: actually I lied to you, there is a difference in the new diffs. You'll no longer see Makefiles/CMakelists in the "packaging diffs". I ok'd this with steve, as that info is contained in the full diff anyway. so now "packaging diffs" are really just debian/*
<Mirv> robru: thanks, makes sense.
<robru> Mirv: yeah a few people have complained about that, so diffs should be less noisy now.
<robru> just trying to reproduce this oxide issue outside the train, bah
<Mirv> "ok now finally I'll just rebuild... oh crap, oxide-qt has started using private symbols again"
<Mirv> -> repacking 4GB + uploading 400MB + waiting 12h
<Mirv> life of a Qt maintainer
<robru> fun times
<alf_> sil2100: Hi! For ci train request 423, we have know top-approved the MP. Please publish it again (or should I just hit the publish button myself?).
<sil2100> alf_: publishing :)
<alf_> sil2100: thanks!
<sil2100> alf_: published o/
<Saviq> rvr, hey, I'm confirming on a mako now, but I really wouldn't block on the "failure" on silo 38, OOM kills is not an exact science, and you were testing on a device least likely to do it
<Saviq> qtmir in that silo is just a packaging change anyway
<rvr> Saviq: Yeah, I was surprised that the silo had something to do, but I tested without it in the same device, and webbrowser-app was killed. Installed the silo again, and webbrowser (as well as the other apps) weren't killed.
<Saviq> rvr, if *no* apps are killed means we're doing better on memory usage
<Saviq> just launch more of them, open more tabs in the browser, monitor the free memory, it must happen at some point
<Saviq> any case, I'm just trying on mako that's more likely to hit memory limits
<rvr> Saviq: http://paste.ubuntu.com/12610164/
<rvr> Oh, shit, it was cut
<Saviq> rvr, so yeah, unity8 is at 3.2%, dash at 4.1%, apps barely cross the 1% barrier, arale just has plenty of memory is all
<Saviq> `free -m` would say a bit more about how much memory's left
<rvr>              total       used       free     shared    buffers     cached
<rvr> Mem:          1892       1850         42         24         42        106
<Saviq> rvr, yeah, you've still 42 megs available, launch more apps! :)
<Saviq> and actually, IIRC caches will get freed before OOM kicks in
<Saviq> rvr, there was quite a bit of static code fixes in one of our unity8 MPs, that could actually reduce memory usage enough to cause what you're seeing
<rvr> Saviq: Finally, webbrowser-app was killed
<Saviq> \o/
<Saviq> :D
<rvr> lol
<rvr> Saviq: Ok, approving the silo :)
<Saviq> rvr, great, thanks
<Saviq> trainguards, Icanhaspublish here https://requests.ci-train.ubuntu.com/#/ticket/410 please?
<Mirv> Saviq: ok, let's see
<Mirv> Saviq: I wonder why it says on trello both passed and still has "blocked" tag too
<Mirv> rvr: should the tag be removed?
<rvr> Mirv: Yup
<Mirv> yup
<Mirv> thanks
<rvr> jgdx: ping
<Mirv> (just gles)
<Saviq> Mirv, thanks
<oSoMoN> trainguards: can the amd64 and i386 builds of webbrowser-app be retried in silo 16 (for both series), please?
<Mirv> oSoMoN: okay, at it again
<oSoMoN> Mirv, thanks!
<jgdx> rvr, pong
<rvr> jgdx: Hey
<rvr> jgdx: Is there any way to manually check fix in silo 53?
<jgdx> rvr, yeah, it's in the test plan
<jgdx> rvr, step 3
<rvr> jgdx: Oh, cool
<Mirv> oSoMoN: ^
<oSoMoN> Mirv, thanks! out of curiosity, how many attempts did it take to get it to build successfully on all arches?
<Mirv> oSoMoN: well two were fine with the next rebuild, the third after the second and the last one took one more
<Mirv> oSoMoN: so in general it feels roughly 50% change of success
<Mirv> chance
<oSoMoN> Mirv, thanks! I havenât given up on actually fixing the unit test yet, but there are more urgent things for now, unfortunately, so until itâs properly fixed Iâll abuse your patience to retry failed buildsâ¦
<Mirv> oSoMoN: yeah, I can see from the amount of landings you're doing! no problem. the new patch is the way of things in 5.4.3/5.5.1/5.6 so it's useful to look at it eventually, but it seems non-critical enough.
<ChrisTownsend> trainguards: Could you please assign https://requests.ci-train.ubuntu.com/#/ticket/436 ?
<sil2100> ChrisTownsend: on it, bu
<sil2100> s/bu//
<ChrisTownsend> sil2100: Thank you!
<sil2100> ChrisTownsend: done :)
<ChrisTownsend> sil2100: ta!
<mterry> robru, got a few questions for ya.  1) one of silo 51's uploads is in the UNAPPROVED queue.  How can I find out why?
<robru> mterry: if there not a freeze on? Check with #ubuntu-release
<mterry> robru, I thought beta freeze is over once beta is done  :)
<mterry> final freeze doesn't start until oct
<mterry> will ask
<mterry> robru, 2) I would like to squeeze silo 41 in today if possible, to make ota7.  I have specific qa testing steps for the patch that's landing.  I can't edit the silo.  But can you point me at who might be doing QA and I can tell them?  (or let me edit silo somehow)
<mterry> (to add the QA steps)
<robru> mterry: why can't you edit the silo?
<robru> mterry: I'm in a meeting with jibel, in half an hour he should be free to discuss that
<robru> mterry: there's no acl for editing silos just sign in and edit
<mterry> hmm
<mterry> robru, haha, yup.  Wasn't logged in.  :(  I want a big blinking <marquee> at the top for that  :P
<robru> mterry: the "create new request" form is hidden when you're logged out
<mterry> robru, yeah, it's obvious enough if you've had coffee
<rvr> jgdx: Approving silo 53
<sil2100> ~/.~.
<sil2100> uh oh
<ogra_> snakes left and right of walls ?
<sil2100> ~
<sil2100> Darn cat
<ogra_> oh, no morew walls !
 * ogra_ runs from the snake 
 * kenvandine stress tests citrain :)
<alesage> robru, renato adding cmake-extras to his indicator-transfer-buteo project, cmake-extras is in universe, he's wanting to know if that's kosher for a package entering main
<alesage> robru or please redirect my q :)
<renatu> robru, network-indicator already uses that
<alesage> renatu, robru nm, appearing in main IIUC http://pastebin.ubuntu.com/12614769/
<robru> alesage: Projects in main cannot depend on projects in universe, will need a MIR filed
<robru> alesage: note that is universe. PPAs don't count
<alesage> robru ack
<renatu> alecu, should we revert the change in transfer-indicator?
<renatu> alesage, ^^
<renatu> alecu, wrong nick, sorry
<alesage> renatu, up to you, I'll pursue the MIR
<barry> robru: this is quicker than email :)
<barry> robru: your fix-filterdiff-tests branch fails with a ton of pep8 failures
<robru> barry: hey ;-)
<robru> way
<robru> wat
<robru> barry: did pep8 get way stricter in wily?
<barry> robru: it's possible some of the defaults got changed.  you should just suppress E402 (but verify the tons of E402 failures).  most E402 is bogus
<robru> barry: wait but that means that the tests passed, it only runs pep8 if tests pass ;-)
<barry> robru: Ran 408 tests in 7.762s
<barry> so, yes!
<robru> barry: sweet, I'll approve the branch then. I'll have to pull out my wily schroot to check all this pep8 stuff.
<barry> robru: have fun with that :)
<robru> barry: thanks for all your help!
<barry> robru: sure thing!
<slangasek> robru: I'm trying to recall where the latest changes to the train left us as far as being able to see who signed off on a given change; as, for instance, https://launchpad.net/ubuntu/+source/mediascanner2/0.107+15.10.20150922.1-0ubuntu1 which introduces an soname change for a library in wily but is not accompanied by a rebuild of its reverse-dependencies
<slangasek> robru: I understood we were passing the sponsor's name as an argument to copy-package now, so it should be recorded on this page?
<slangasek> robru: but it only lists jamesh, who is not an Ubuntu dev; so either the train didn't properly generate a packaging diff, or it didn't enforce the uploader check correctly
<slangasek> or it didn't put the right name in the field
<robru> slangasek: train has always passed the sponsor name to copyPackage, what changed was that we now enforce checkUpload to allow somebody to be a sponsor at all
<robru> slangasek: if you tell me what silo it published from I'll find the logs and tell you who published
<slangasek> robru: please compare https://launchpad.net/ubuntu/+source/mediascanner2/0.106+15.10.20150917-0ubuntu1 and https://launchpad.net/ubuntu/+source/mediascanner2/0.107+15.10.20150922.1-0ubuntu1 - the first (before the recent changes) doesn't list that this is a sponsored upload at all.  The second does list it as a sponsored upload, but is *not* listing the name in the "sponsored" field that I'm expec
<slangasek> ting to see
<slangasek> launchpad should show me who approved the upload that ci-train-bot sponsored, not who the lander was
<slangasek> (unless the lander is an ubuntu-dev)
<slangasek> (and is also the one who approved the upload)
<slangasek> robru: this appears to be silo 019
<robru> slangasek: published and ACKed by kenvandine https://ci-train.ubuntu.com/view/2.%20Publish/job/ubuntu-landing-019-2-publish/101/console
<slangasek> robru: ok, thanks
<robru> slangasek: also packaging diff looks sensible: https://ci-train.ubuntu.com/view/2.%20Publish/job/ubuntu-landing-019-2-publish/lastSuccessfulBuild/artifact/mediascanner2_packaging_changes.diff/*view*/
<slangasek> robru: that means kenvandine is the one whose launchpad id I want passed to copy-package :)
<robru> slangasek: it should have been. was it not?
<slangasek> robru: what I see on that launchpad page I linked you above was 'jamesh', not 'kenvandine'
<robru> slangasek: dunno what to tell you. copyPackage sets sponsored: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/copy2distro#L116 and sponsored comes from the rsyncfile here:
<robru> https://ci-train.ubuntu.com/view/2.%20Publish/job/ubuntu-landing-019-2-publish/lastSuccessfulBuild/artifact/packagelist_rsync_ubuntu-landing-019/*view*/ where it clearly says ken-vandine. must be a bug in launchpad not displaying the right thing.
<slangasek> robru: ok; I'll open a bug on this against cupstream2distro, and we can figure out if it needs to be reassigned to launchpad
<slangasek> robru: btw you actually call syncpackage rather than copy-package, right?
<slangasek> since that's the one that has the "--sponsor=" option
<robru> slangasek: we use lplib not ubuntu-archive-tools
<slangasek> ok
<robru> although I'm starting to wonder if it wouldn't make more sense to convert copy2distro from python to shell, considering that snakefruit doesn't have python3 and this is a frequent source of problems in the train.
<slangasek> robru: bug #1501036
<ubot5`> bug 1501036 in CI Train [cu2d] "cupstream2distro passes the wrong launchpad id as the sponsoree when uploading to the distro" [Undecided,New] https://launchpad.net/bugs/1501036
<slangasek> robru: mm? snakefruit does have python3
<robru> slangasek: well not a new enough version. it's running precise.
<robru> slangasek: if snakefruit could be upgraded to trusty I'd be so happy
<slangasek> don't count on that
<slangasek> kenvandine: ping, btw :)
<kenvandine> slangasek, pong
<robru> slangasek: no I'm not counting on it but it often causes headaches.
<robru> slangasek: oh, it's not that snakefruit doesn't have python3, it's that snakefruit doesn't have python3-launchpadlib, and my trusty backport is only for trusty, not for precise.
<slangasek> kenvandine: so silo 019 is stalled in -proposed because it introduces an soname change in wily and the reverse-dependencies were not all included in the silo
<slangasek> kenvandine: since you signed off on the packaging changes, I think that means you're responsible for following through ;)
<kenvandine> damn
<kenvandine> slangasek, iirc, it didn't break or conflict with the previous
<kenvandine> so should still be installable, right?
<slangasek> kenvandine: you don't get to have both of them in wily at the same time
<kenvandine> jamesh, ^^
<slangasek> kenvandine: proposed-migration requires all the revdeps to be rebuilt first, and then transition them together - and considering one of the reverse-dependencies is qtubuntu, I'd say there certainly hasn't been a valid integration test of the new lib...
<slangasek> kenvandine: see also related bug #1500859
<ubot5`> bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed] https://launchpad.net/bugs/1500859
<kenvandine> ugh!
<kenvandine> ok
<slangasek> the criticality may be somewhat overstated, but it does require a source fix and upload ;)
<kenvandine> yeah
<slangasek> robru: and there's no chance that copy2distro mistakenly picked up an rsync file from jamesh's previous failed publication attempt because that file is only generated if the acl check succeeds, right?
<robru> slangasek: yes, the acl check happens well before the class that creates that file is even instantiated.
 * slangasek nods
<robru> slangasek: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/publisher.py#L213 line 213 vs 222 in the main() function
<kenvandine> i'm confused...
<kenvandine> this was published to the overlay ppa
<kenvandine> but... there is no libmediascanner-2.0-4 in the overlay
<slangasek> kenvandine: this was landing the merged packaging that generates *different* package names for vivid vs. wily for the g++5 ABI transition
<slangasek> kenvandine: however, it's possible this whole landing was pointless and it should have been left alone - because we already had libmediascanner-2.0-3 in both vivid and wily, and we wouldn't have let that through without a package name change if the ABI had changed, I think
<kenvandine> oh... i see it
<kenvandine> 2015-09-24 18:55:39,811 INFO Copying mediascanner2 0.107+15.04.20150922.1-0ubuntu1 in vivid to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay.
<kenvandine> -Package: libmediascanner-2.0-4
<kenvandine> +Package: libmediascanner-2.0-3
<kenvandine> in the overlay ppa
<kenvandine> jhodapp, what do you know about this issue?
<jhodapp> kenvandine, which issue?
<kenvandine> silo 19
<jhodapp> not a thing
<kenvandine> mediascanner soname bump
<jhodapp> kenvandine, I'd check with jamesh
<kenvandine> you commented about the bug it caused :)
<kenvandine> s/about/on/ :)
<jhodapp> got a link?
<jhodapp> this must have been pre-vacation...everything has since left my brain ;)
<kenvandine> bug 1500859
<ubot5`> bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed] https://launchpad.net/bugs/1500859
<kenvandine> that was caused by this landing
<kenvandine> but.. silo 19 includes magic to provide a different soname version for vivid vs wily
<jhodapp> kenvandine, oh, don't know much yet other than I wanted to know about the MIR landing process
<kenvandine> jhodapp, is qtubuntu-media dual landed? or separate wily and vivid branches?
<jhodapp> kenvandine, separate branches atm
<slangasek> haha of course
<kenvandine> ok, so you could have separate depends for the 2
<slangasek> so you can't include it in a dual landing silo dur
<kenvandine> yeah
<kenvandine> grumble
<slangasek> why is the dep hard-coded at all?
<kenvandine> yeah, i'd think you'd get it with shlibs
<jhodapp> slangasek, you mean libmediascanner being listed for qtubuntu-media?
<slangasek> jhodapp: yes
<jhodapp> I'm pretty sure it can be removed now actually...that is probably a mistake that it's still listed there
<jhodapp> I'm working with qtubuntu-media atm, so I'll check this out
<jhodapp> although I don't understand why having it as a dep is an issue...can someone explain that to me with the knowledge that I have little packaging experience
<kenvandine> jhodapp, silo 19 landed a soname bump of libmediascanner
<kenvandine> so libmediascanner-2.0-4 is the new binary package name
<kenvandine> so depending on libmediascanner-2.0-3 forces it to install the older version
<jhodapp> oh I see, ok
<kenvandine> but i'm thinking slangasek might be right, this whole landing to have different soname versions for the 2 isn't useful
<jhodapp> why is the so-name part of the package name?
<jhodapp> that seems odd
<kenvandine> it's the debian way :)
<robru> kenvandine: oh, this was the landing where the train had that bug that it was diffing the vivid version against the wily version
<jhodapp> really?
<kenvandine> so you can have them installed in parallel
<kenvandine> 2 versions of the same lib installable together
<jhodapp> ah, so instead of using metadata in the package they use the package name
<kenvandine> yup
<jhodapp> seems antiquated now
<kenvandine> slangasek, sorry for letting it in, i thought we only blocked on rebuilding everything if there was a breaks or conflicts with the old soname version
 * kenvandine is glad we have -proposed :)
<slangasek> the use of the soname in the package name is deliberate and not antiquated :)
<kenvandine> not everyone agrees :-D
 * slangasek shrugs
<kenvandine> i'd like parallel installable versions of the same package name :)
<jhodapp> I think it creates a weird situation, like this
<kenvandine> conary did that, it rocked
<jhodapp> exactly
<slangasek> kenvandine: go run Red Hat, I'm sure you'll love it?
<kenvandine> nope :)
<kenvandine> with conary we could do libfoo=2.0-0 and libfoo=2.0-1
<kenvandine> both installed at the same time
<kenvandine> same package name
<kenvandine> it was cool :)
<robru> kenvandine: oh yeah I forgot you're a conary snob ;-)
<kenvandine> anyway...
<kenvandine> not anymore
<kenvandine> we had cool stuff back in the day :)
<jhodapp> makes sense to me, seems to be a style difference/preference
<kenvandine> jhodapp, when does jamesh usually show up?
<robru> kenvandine: yeah conary was a victim of "too technically good to be successful". debian, of course, being *just* good enough, wins out ;-)
<jhodapp> kenvandine, he's UK I believe
<kenvandine> oh?
<kenvandine> australia.. last i heard
<jhodapp> oh nevermind then
<kenvandine> :)
<jhodapp> you know better than me :)
<kenvandine> i figured you worked more closely than me
<jhodapp> not really, I just know he works on mediascanner
<kenvandine> i guess a couple hours
<ahayzen> jhodapp, jamesh is in Australia :-)
<robru> slangasek: hangout issues, just restarting
#ubuntu-ci-eng 2015-09-30
<jamesh> kenvandine: hi
<jamesh> kenvandine: just looking back through scrollback, I thought I'd checked the rdepends when putting the silo together, but looks like I missed qtubuntu-media (it wasn't a dep last time we made such a change)
<kenvandine> jamesh, yeah, but slangasek was also questioning if we need the different sonames for the gcc5 transition
<kenvandine> jamesh, also qtubuntu-media isn't dual landing, so harder to get fixed
<kenvandine> i think we just need that depends dropped from qtubuntu-media and rely on shlibs to properly depend on it
<jamesh> kenvandine: the existing packaging was a problem, since it used the same package name for vivid and wily
<kenvandine> jamesh, yeah, he was questioning if we really needed that
<jamesh> kenvandine: from my reading of the migration docs, it should have had "v5" appended to the end of the package name to make upgrades go smoothly
<jamesh> kenvandine: given that it is an ABI break, it seemed worth doing now rather than later.
<kenvandine> anyway, if we can get the depends dropped from qtubuntu-media it could unblock the packages in proposed
<kenvandine> assuming it properly picks up the depends without the hard coded depends
<jamesh> kenvandine: shouldn't it just require a rebuild?
<jamesh> none of the -dev packages have changed
<kenvandine> qtubuntu-media has a depends on libmediascanner-2.0-3
<kenvandine> specifically
<kenvandine> jamesh, see bug 1500859
<ubot5`> bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed] https://launchpad.net/bugs/1500859
<jamesh> that is surprising
<kenvandine> but we can't build that in the same silo because qtubuntu-media can't handle dual landings right now
<kenvandine> yeah, i don't think it should need that depends
<jamesh> so neither of the .so files in qtubuntu-media link to the library
 * jamesh looks
<kenvandine> oh joy
<kenvandine> so it really shouldn't depend on it
<jamesh> unless they are doing something particularly cunning
<jamesh> (I hope not)
<kenvandine> indeed
<jamesh> it looks like it is used from some source code that may not be linked into the plugin?
<kenvandine> dunno, we should get jhodapp too look at it more closely
<jamesh> it is explicitly linking to mediascanner, but the requirement is likely being removed because the .so doesn't actually use any symbols from the library
<jamesh> I'll add some notes to the bug report.
<kenvandine> jamesh, thanks!
<jamesh> kenvandine: here's what I've added: https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859/comments/3
<ubot5`> Ubuntu bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed]
<Mirv> mornings
<slangasek> jamesh: if it needed v5 appended to the package name, it would have been done already as part of the g++5 rebuilds; you don't need to make an soname change *now* for the g++5 abi transition
<jamesh> slangasek: it definitely had cxx11 tagged symbols, and definitely didn't have the package name changed as part of the transition
<slangasek> jamesh: right; so as I understand it, someone already made the determination that a library rename wasn't needed for this case
<jamesh> slangasek: then they made the determination wrongly.  The library compiled with gcc 5 has a different ABI (it uses std::string, and is compiled with C++11), so the package name needs to be different
<slangasek> std::string is part of the API that it exports?
<jamesh> slangasek: yes.  Here is the debdiff of the update doko pushed: http://launchpadlibrarian.net/213231546/mediascanner2_0.105%2B15.10.20150721-0ubuntu1_0.105%2B15.10.20150721-0ubuntu2~ppa1.diff.gz
<jamesh> you can see many symbols file changes and no binary package name change
<slangasek> hmm, ok
<slangasek> jamesh: looking at that diff I agree with you, so I don't know why it was done without a package name change
<kenvandine> so we just need to sort out the depends in qtubuntu-media to unclog wily
<slangasek> jamesh: still, the package from this silo doesn't appear to change the package name in a predictable way (appending v5), but instead has incremented the soname... what happens if there's an ABI change to the package in vivid?
<slangasek> or maybe this is part of the SDK so that should never happen :)
<slangasek> kenvandine: yes, I think so
<jamesh> slangasek: if there is an ABI change, both sonames would need to change
<slangasek> jamesh: alright, as long as that's understood :)
 * kenvandine heads off to get some sleep, thanks for looking into it
<jamesh> slangasek: I added some notes about the qtubuntu-media problem to the bug report: https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859
<ubot5`> Ubuntu bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed]
<jamesh> slangasek: it looks like there is no code in the binary package that actually uses libmediascanner
 * slangasek nods
<greyback_> cihelp: hey, we're getting "virtual memory exhausted" errors for amd64 builds: https://jenkins.qa.ubuntu.com/job/qtmir-vivid-amd64-ci/148/console
<Saviq> sil2100, we got a silo lined up with a few high prio fixes for qtmir, but we've also planned to land proper mouse pointer/cursor for pocket desktop in that same silo, with OTA7 freeze in effect, shall we pull the mouse bits out?
<Saviq> sil2100, in theory they don't touch phone until you connect a mouse up
<sil2100> Saviq: that's a tricky one
<sil2100> Saviq: so normally I would say: 'just pull it out', but I know we have some pressure on PD recently - I wouldn't include it without Pat's approval though, as he has the exception decisive power
<sil2100> Saviq: maybe for now pull it out so that it doesn't slow you down and you can try re-landing it a bit later, after we get Pat's input here
<Saviq> sil2100, yeah, that's probably best, OTOH means double QA effort
<sil2100> Saviq: true, but I know QA said they even prefer signing off smaller silos instead of big ones - bigger chances of missing stuff
<sil2100> We even had that idea of only limiting to a few bug fixes per silo ;p
<Saviq> sil2100, ack, /me pulls mouse
<sil2100> (which didn't stick)
<Saviq> sil2100, btw, is wily+overlay a thing yet?
<sil2100> Saviq: not yet, but we'll want to have it later today/tomorrow
<sil2100> We have a green light for it though
<Saviq> k
<Saviq> sil2100, my ticket does say overlay as the destination PPA (it didn't before), that expected?
<sil2100> Saviq: let me check, maybe something happened during the night
<Saviq> sil2100, basically, my q is, is https://requests.ci-train.ubuntu.com/#/ticket/420 set up correctly?
<rvr> abeato: I failed the silo. The pause/play button in the indicator doesn't synchronize with the music-app.
<abeato> rvr, thanks, I saw that, music-app still needs some work to get this finally working
<sil2100> Saviq: so, I need to look into the backend, but most probably you assigned the silo when it was still possible to target dual landings for an explicit destination
<Saviq> sil2100, it was like Monday evening or something
<Saviq> actually req says last Thursday, even
<Saviq> sil2100, https://ci-train.ubuntu.com/job/prepare-silo/6246/
<sil2100> Saviq: so, I think it's ok, the destination field should be left empty as for dual silos it's not taken into consideration right now
<sil2100> As we hard code the dest there
<sil2100> For a moment it was switched to be configurable for dual silos, but as per slangasek's recommendations it was switched back to hard-coded
<sil2100> As we don't want people landing things in wrong places by mistake
<sil2100> I'll hard-switch it to the overlay later
<Saviq> sil2100, ack
<alf_> cihelp: Hi! http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-mako/ jobs have a long backlog because of "pending - Waiting for next available executor on mako-mir"
<alf_> cihelp: Any idea what's going on there? It seems that only two mako-mir executors are online...
<alf_> cihelp: This is making CI builds take extremely long (e.g. one job is already "building" for more than 9,5 hours)
<greyback> trainguards: could someone delete the "unity-api" packages from silo15 plz
<sil2100> greyback: on it
<greyback> sil2100: thanks
<sil2100> Done
<jgdx> rvr, thx
<sil2100> dbarth_: if you don't mind I'll play around with landing 005 for a bit
<sil2100> dbarth_: (add some merges, rebuild etc.)
<sil2100> dbarth_: it's the papi landing
<kgunn> sil2100: are we doing dual landing into overlay for wily yet ? or just keep our dual landing silo as is...
<oSoMoN> trainguards: can the failed builds in silo 59 be retried, please?
<dbarth_> sil2100: oh sure, go ahead; it'd be awesome to land that one!
<Mirv> oSoMoN: on it
<oSoMoN> thanks
<sil2100> kgunn: just keep them as is, the transition will be transparent ;)
<sil2100> tvoss, dbarth_: the papi in silo 15 has built successfully \o/
<kgunn> ooo i love it
<dbarth_> sil2100: super !
<tvoss> sil2100, great,thank you
<Mirv> oSoMoN: ^
<Mirv> (built)
<oSoMoN> Mirv, thanks!
<alf_> cihelp: Hi! Any updates about all but one mako-mir builders being offline (see ping earlier today and http://s-jenkins.ubuntu-ci:8080/label/mako-mir/?). This is really hurting our CI/autolanding times.
<rvr> barry: Silo 8 merge proposal needs review and approval
<barry> rvr: yes.  i am currently working through the test plan.  it will need release team approval too (it's targeted at wily)
<fginther> alf_, hello. Sorry for the delay. One of the devices failed and it's coming back up now. I'm also trying to work in some replacements for some devices that are now unusable
<Saviq> fginther, hey, I've seen failures like that in multiple jobs these past few days https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-wily/416/console
<fginther> Saviq, ugh! I'll add that to the list, but I'm not sure that one isn't caused by a test process that doesn't exit properly
<Saviq> fginther, thanks
<jibel> dbarth_, is silo 2 for ota7?  it seems a bit huge to land so late without risk, it doesn't bring features from the features list and no critical bug fixes?
<fginther> I've seen it before, but the solution is escaping me. Will see if I can find some notes on it.
<dbarth_> jibel: not really for ota-7, we should put it aside for now
<dbarth_> jibel: is there a parking lot for silos like these, or i should abandon temporarily to free up silos?
<seb128> jibel, pete-woods, we (desktop) need/want to land unity7 theme fixes (which are in silo 24 as well) to wily, should we just upload to wily (and let you sort out the silo then) or do you plan to QA review/land silo 24 today or tomorrow?
<pete-woods> seb128: I would like to run the silo through QA as fast as possible
<pete-woods> it's been reviewed now
<pete-woods> I was just ill for a couple of days
<pete-woods> can mark as ready
<seb128> pete-woods, that would be nice, I added a bugfix for eog while you were not there, should be a noop for the phone
<pete-woods> seb128: ah yeah
<pete-woods> seb128: does it need rebuilding?
<barry> sil2100: question about landing policy, if you have a few minutes
<sil2100> barry: hey! What's up?
<pete-woods> looks like you already built :)
<seb128> pete-woods, I did rebuild
<seb128> right
<seb128> Laney, did you have one more branch to add to that?
<barry> sil2100: hi!  so silo 8 has s-i 3.0.2.  it's built and i've done qa.  i think it's ready to land, but of course wily is in final beta.  i'd like to get this bug fix into wily.  what do i do next?
<seb128> Laney, or did you just ask about https://code.launchpad.net/~larsu/ubuntu-themes/eog-overlay-buttons ?
<Laney> just that one
<seb128> good
<jibel> dbarth_, we should take a snapshot of the overlay soon to unblock landings like yours
<sil2100> barry: I suppose you can still publish it to wily and poke the release team to review the new upload and move it out from the UNAPPROVED queue
<sil2100> barry: since system-image isn't seeded in any desktop image (besides -next)
<barry> sil2100: okay cool thanks.  i wasn't sure if there was some train station i needed to stop at first
<Laney> You shouldn't poke unless it is taking a long time
<sil2100> barry: no, for wily it's rather just a button press and then poking the release team
<sil2100> barry: ok, so no poking!
<sil2100> As per Laney's response
<Laney> there's a queue that people regularly look at
<Laney> https://launchpad.net/ubuntu/wily/+queue?queue_state=1
<barry> Laney, sil2100 okay, will do thanks!
<Laney> cool
<dbarth_> jibel: ok, that'd be great; feel free to put the silo aside for ota-7 qa already, and we can get back to that when the new overlay opens
<barry> yay! the abyss was not a terrible movie
<jhodapp> kenvandine, slangasek I removed the mediascanner dependencies from qtubuntu-media and it's building in silo 47 now
<kenvandine> jhodapp, thx
<jhodapp> np
<kgunn> ev: fginther not sure who to ping, but mir project ci has kind of ground to a halt...i understand all but 2 makos are down
<kgunn> you guys aware ?
<fginther> kgunn, yes, ev is the right person for this. He should be able to give you an update on where we are with replacing the makos that have died recently
<kgunn> thanks
<kgunn> ev: please let us know, we might need to prioritize some mp's....rate is about 6/7hrs now due to traffic jam
<fginther> kgunn, ev is still in a meeting, but he shot me a quick message to re-allocate some resources to help here. He'll try to follow-up with you a little later
<kgunn> thanks!
<fginther> kgunn, I've added a couple of krillin to the pool of devices. The job name is still "mir-mediumtests-runner-mako" but please note that it could be either a mako or krillin. I'll get the name fixed once the backlog is down
<kgunn> fginther: thanks, hope that works
<robru> to anybody that might be around: I just rolled out a Bileto update, if you get broken links it's because your page is stale, just reload the page and it should work again.
<robru> am I the only one who can't connect to irc.canonical?
<thomi> robru: I'm connected...
<robru> bah
#ubuntu-ci-eng 2015-10-01
<robru> heh
<ev> kgunn: terribly sorry about that. We saw this a mile back, but haven't been able to get an answer on whether we should replace those makos with BQs or somehow find more makos (i.e. build a time machine).
<ev> kgunn: if you want to step in and make the call on that email ("BQ vs Mako", 22 Sept) that would be grand
<ev> as I think Pat is out
<ev> thanks for rescuing this, fginther
<Ursinha> robru, I can't connect either, came here to ask if I was the only one
<fginther> ev, you're welcome
<robru> Ursinha: i got back in after a while, seems intermittent
<Ursinha> still no luck here :/
<robru> ev: i have a personal mako m thinking of upgrading, how much you willing to pay for it? ;-)
<robru> Ursinha: when I lost the connection it took me 2 hours before reconnecting was successful. want me to grab somebody from #webops to find you here on freenode?
<Ursinha> robru: did they have to do anything for you to be able to connect? I think that would be helpful, thanks :)
<robru> Ursinha: nah I just ignored it until it fixed itself. but I'll ask for you
<Ursinha> robru: thank you :)
<robru> Ursinha: you're welcome!
<robru> Ursinha: pjdc referred me to barryprice, hopefully he's around to follow up with you
<Ursinha>  robru, thanks!
<robru> lol, I did a train rollout 2.5 hours ago and nobody has run any train jobs yet to test it.
<robru> stupid lull between US EOD and EU morning
<ev> robru: one loonie
<robru> ev: plus shipping?
<ev> well, I'll put a stamp on the loonie
<robru> Lol
<ev> and we'll just trust the post office
<robru> What could possibly go wrong?
<ev> they could send Benton Fraser down after me for attempting to bribe a Canadian national
<ev> and bed
<Mirv> running some...
<bzoltan_> jibel:  when you see Victor, would you please ping him to check the silo57 UITK. He misunderstood the logs.
<Mirv> jibel: robru: I think we'd need checking for unbuilt revisions before publishing, to avoid spending QA cycles on a silo that would have needed a rebuild. 2/4 of this morning's silos were such.
<Mirv> I guess I'd mean a constantly running job every hour or so, and an indicator on Bileto/Trello.
<robru> Mirv: good call, can you file a bug?
<robru> Mirv: I've been aware of this issue for a while, problem is that nothing runs after build but before publish to detect this stuff.
<robru> Mirv: so something that scans every five minutes and reports these types of problems would be good
<robru> Mirv: maybe check-publication-migration could be expanded to cover this, since it polls PPAs every five minutes but only for silos that were published. Could expand it to pre-publish checks
<Mirv> robru: yeah a scanning one sounds good. I'll file a bug.
<jibel> robru,  auditable logs is a nice new feature, thanks! is it complete or still in progress?
<robru> jibel: well I'm sure there's issues to iron out but it's basically done.
<robru> jibel: it'll look a bit better when I redesign the site. it was just a higher priority to get it functional, can make it pretty later
<robru> jibel: what makes you ask if it's in progress? something wrong?
<robru> I'm afraid certain silos will just be totally spammed with hundreds of messages, might have to simplify the number of status messages that jenkins uses.
<robru> I suppose I should make some attempt to create audit log entries for old requests that don't have any but I'm not sure how feasible that would be, or how much value a "fake" audit log entry would be.
<jibel> robru, there is no entry when the user performs an action for example like changing the status
<robru> jibel: no, entries are only created by jenkins when jenkins is doing something.
<jibel> robru, I'd like to know who marked it ready, failed, passed, ...
<robru> hmmmm
<robru> jibel: that sounds feasible, can you file a bug against lp:bileto and assign it to me?
<jibel> robru, that was the bug you marked as duplicate
<jibel> robru, bug 1496432
<ubot5`> bug 1491163 in CI Train [cu2d] "duplicate for #1496432 Auditable Publish logs." [Critical,Triaged] https://launchpad.net/bugs/1491163
<jibel> I'll add more info
<jibel> not this one but the dupe
<robru> jibel: ah it was ambiguous, I interpreted "actions" as "jenkins jobs", didn't consider also changing qa_signoff state.
<jibel> robru, no, for the user jenkins is a transparent piece of machinery
<jibel> robru, I'll deduplicate and add more info
<robru> jibel: I think jenkins is maybe as transparent as mud ;-)
<jibel> :)
<jibel> robru, bug 1496432
<ubot5`> bug 1496432 in Bileto "Add status changes to the audit logs" [Undecided,New] https://launchpad.net/bugs/1496432
<robru> jibel: ok I can probably do that during my shift tomorrow
<jibel> robru, not urgent but nice to have and useful to understand how things happen
<robru> jibel: yeah it's a good idea, didn't even occur to me
<Saviq> Mirv, hey, we'll pull the qtmir commit out when greyback's around, don't wanna waste the testing and QA time, and the additional change is rather small
<Saviq> Mirv, unless you can force publish anyway?
<Mirv> Saviq: please pull it, there's no force option for that
<Mirv> (for publishing)
<Mirv> ogra: when around, please run https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/ job (no packaging changes, but manually uploaded main package)
<robru> ogra: and for the first time ever, train generated a real live diff for oxide, which you can review at https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/94/artifact/oxide-qt_content.diff/*view*/
<Saviq> greyback, hey, can you pull the last change from qml cache branch, I didn't notice and didn't rebuild when you pushed it
<greyback> Saviq: you want me to revert that change? What's wrong with rebuilding it (you'd need to retest?)
<Saviq> greyback, me, and QA team
<greyback> Saviq: alrighty. Will need you to reapprove the MP
<Saviq> greyback, so yes, please revert, and we'll land separately (with a test verifying you only clear cache once?)
<Saviq> ack
<greyback> Saviq: pushed
<Mirv> trying again
<Saviq> greyback, you'll need to uncommit and overwrite instead
<Mirv> right
<greyback> Saviq: ah ok
<Saviq> greyback, otherwise train's always gonna find new commits
<Mirv> so rev 380
<greyback> done
<Saviq> greyback, thanks
<Saviq> Mirv, ok, last time (fingers crossed)
<Mirv> the second last time already
<robru> Mirv: wat
<Mirv> looking good now
<Mirv> robru: just a new commit that needed uncommitting so that train can publish what was built
<sil2100> robru: nothing to worry about
<robru> Mirv: oh ok. I was just looking at the audit log and I was like "you didn't build this, stop it"
<Mirv> Saviq: greyback: it's good now.
<Saviq> Mirv, great, thanks
<robru> a single publication just marked 8 silos dirty, good god people
<robru> Mirv: hmmm, so if I implement a continuous scanning check that would mark silos dirty due to having unbuilt revisions, removing the offending commit wouldn't un-mark it dirty... you'd be forced to rebuild.
<sil2100> Saviq: hey! Did you talk with Pat about the cursor changes in unity8 in the end?
<Saviq> sil2100, forgot, will do so this afternoon, we've a few more PD-geared things that we might land along side
<Mirv> robru: watch only would work though? the most usual use case is that the new build really needs to be done (before submitting to QA)
<robru> Mirv: nope, watching a dirty silo does not make it clean. you need to really do a build to clear the dirty state.
<robru> Mirv: oh, you might be thinking that watching a silo will set the status to 'packages built'. that's true. but the files that indicate dirty state are still on disk
<Mirv> robru: hmm, maybe it's better anyway. or we need a "clean dirty flag" to build job.
<robru> Mirv: please god no more flags I'm sick of flags, there should be fewer flags
 * sil2100 likes flags
<Mirv> robru: well hmm how it'd work for manual uploads then? yes, I thought that.
<robru> Mirv: not sure. I think the current implementation would clear the dirty status if you rebuild a manual source even without uploading a new package. it would have no way of knowing.
<Mirv> robru: my Qt 5.5 silo would get marked dirty several times a week and I mostly upload just new packages manually.
<Mirv> robru: ok, so for manual uploads watch_only provavly clears the flag.
<robru> Mirv: right, there's no requirement to reupload every time it gets dirty, just in between getting dirty and when you want to publish. if you don't do it then you'll revert whatever release made it dirty in the first place
<robru> Mirv: no, watch_only will never clear the flag
<robru> Mirv: you would need to run the build as if it was a real build, it would clear the flag that way even though it doesn't actually upload a new package for you
<robru> Mirv: the flag gets cleared in the 'clean' phase which does not run during watch_only.
<Mirv> ah, ok.
<Mirv> so build without watch_only ok :)
<Mirv> robru: I think we want more to prevent this kind of problem (like Saviq's and pete-wood's todays silos) than we want to allow the uncommit dance
<Mirv> I mean, Saviq wouldn't have put the silo towards QA if it would have been flagged dirty
<robru> Mirv: in the bad old days you needed to use WATCH_ONLY on manual sources but for a while now the train knows what to do if you do a "real" build but you only have manual sources in the silo
<robru> right
<Mirv> now if we don't give more flags for sil2100 to love, the downside is if greyback decides to accidentally push a commit to the MP during QA
<robru> Mirv: ok I really like the idea of train automatically marking silos dirty when new commits appear, not sure when I'll have time for that though
<Mirv> I'm not sure how often accidental commits + uncommits + force push:s happen
<robru> me either.
<Mirv> robru: right, so in principle it's the right thing to do but there's no hurry
<robru> Mirv: what we'll do is make sure to put a BLACK MARK on their PERMANENT RECORD whenever it happens
<greyback> and I'll do it again too, mwahahaha
<Mirv> bad greyback, bad!
<dbarth> hey guys; i have a couple of manual upload requests for my silos (i guess that's trainguard material)
<sil2100> dbarth: yep, what's up? :)
<dbarth> in silo-005, in the ppa specifically, adding a webbrowser-app upload, to test the fix in platform-api
<robru> ok good night, gotta be up early for that meeting tomorrow
<Mirv> robru: night!
<dbarth> it would be a no change uplaod, to get the build dependency in
<Mirv> dbarth: you could do an empty MP if you want to control it yourself
<dbarth> and in silo 21, we have the final 1.9.4 build availble (replaces 1.9.3 with an extra security fix from upstream)
<dbarth> Mirv: so i need to bzr branch lp:trunk bzr push to a personal branch and then create the empty mp from there, right?
<Mirv> dbarth: exactly
<dbarth> i tried the other day but it wouldn't work without an actual 1 line change; well trying again l)
<dbarth> ;)
<sil2100> dbarth: in the past it worked fine :)
<sil2100> Since LP allows for pushing no-change merges
<Saviq> Mirv, robru, it'd definitely be helpful, but sounds overkill, that the train would monitor all the involved branches
<Saviq> this case was my fault since I added/built the MP before it was top-acked
<Saviq> should've monitored it more closely
<dbarth> ok, that seems to work
<Mirv> Saviq: the problem is that it happens often, and more often in that way it really needs a rebuild. wasting QA resources is bad.
<Saviq> Mirv, totally, OTOH this should never happen if the lander's doing his job right
<Mirv> the tools are there to help lander to do the job right. currently this seems a bit too common.
<Saviq> true
<dbarth> Mirv: for oxide 1.9.3, is there something i need to do to have it published and ready for ota-7?
<dbarth> Mirv: 1.9.4 is here, but oSoMoN righfully suggested to get 1.9.3 published first, just to be sure we have a recent oxide available in the image
<Mirv> dbarth: ping ogra more to publish it :)
<Mirv> or some other core-dev
<Mirv> dbarth: 1.9.3 is approved and ready to land
<dbarth> ah ok
<dbarth> fine, then i should create a new silo request for 1.9.4, it's safer
<Mirv> I wonder if eg Laney would like to run https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/build (no packaging changes, but a manual upload of a main package - full diff at https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/94/artifact/oxide-qt_content.diff)
<Mirv> dbarth: yes, please
<Laney> Mirv: I don't think this policy applies to non-Ubuntu
<Laney> does the train enforce it?
<Mirv> Laney: non-Ubuntu? so yes, train enforces that if the package is not built via MP:s but manually uploaded to the PPA, a main package always needs to be published by a core dev even if it would not have packaging changes.
<Mirv> oxide-qt is a bit special since it's so huge (4GB unpacked) that it's a bit hard to maintain it via MP:s
<Laney> Mirv: I mean that the sign-off policy doesn't apply to the PPA which isn't really Ubuntu itself
<Laney> DMB doesn't have authority over it anyway
<Laney> but yes, can publish
<Laney> done
<Mirv> Laney: thank you. it's just that non-coredev:s can't run the publish jobs anymore in case they don't have the permissions on the Ubuntu side.
<Laney> Mirv: I think you *do* have the permissions for the PPA
<Mirv> Laney: https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/94/console "timo-jyrinki not authorized to upload oxide-qt"
<Laney> that is the ~ci-train-ppa-service team, not ~ubuntu-core-dev or anything else
<Mirv> Laney: for the PPA, but not PPA -> archive
<Laney> this was -> PPA
<Laney> at least I hope so!
<sil2100> The thing is that the current CI Train permission checks always check permissions against the main archive
<sil2100> Even if you publish to a PPA (like the overlay)
<Laney> OK, that's probably a bit stricter than is necessary
<sil2100> Yeah, I wanted it to do 'the right thing' and check against the destination, but slangasek said this way is good as well
<Laney> It's fine, just you might have to get someone else in cases you don't strictly have to
<Mirv> Laney: ah, right, that's what you meant, sorry. yes, it's a bit strict, but we treat the overlay PPA pretty much as an archive.
<dbarth__> trainguards: there is now a release of oxide 1.9.4 ready for manual upload to silo 16; thanks
<sil2100> dbarth: requiring a rebuild against the overlay, right?
<dbarth> sil2100: exactly
<sil2100> dbarth: I'll try to pick it up in a moment then o/
<dbarth> ty
<Mirv> sil2100: just tell if you want me to
<sil2100> dbarth: in what PPA is it available? In phablet I only see 1.10.1
<sil2100> Mirv: if you know where to get it from then you can pick it up ;)
<Mirv> sil2100: ok then :) fetching it from https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa
<sil2100> Ah, tha one ;)
<greyback> Anyone happen to know what ordering that the train uses with multiple MPs? It doesn't appear to be the order they are listed
<sil2100> greyback: in the past it was using the order listed, not sure how it looks like now though
<greyback> I'm not sure I understand the order any more. In silo22, qtmir, small-refactoring-of-MirWindowManager is applied *after* liveCaption
<greyback> but listed before. And I think approved before.
<sil2100> greyback: let me look into that in a moment
<greyback> sil2100: it's not urgent, just would be good to understand
<dbarth> sil2100: oops sorry, yeah, what Mirv said
<Mirv> Oxide is what I have all the CPU:s, SSD:s and 100/100 network connection for...
<brendand> any new arale image being built soon?
<sil2100> brendand: what's up?
<brendand> sil2100, oh i'm just having some troubles with our test suite and the normal workarounds aren't working
<brendand> sil2100, we get some issues updating when the archive moves on from the image
<brendand> sil2100, so a new build solves it for sure
<sil2100> brendand: we might kick a new image in ~1 hour if you're ok with that, as I'm investigating some changes in livecd-rootfs
<sil2100> But you'd need to wait a bit
<sil2100> Would that be fine?
<brendand> sil2100, yeah no rush
<Mirv> robru: FYI I tried comment silo 054 multiple times but the comments seemed to go to /dev/null
<Mirv> just wondering if they show in any log or such
<alf_> jibel: Hi! I have top approved all the branches for citrain request 343. Please try again. About the changelog conflict, it seems to be a bzr/lp glitch not a real conflict. We had the same problem for USC 0.1.3 (entry 423) but it went through fine.
<alf_> kgunn: ^^ FYI
<jibel> alf_, okay, thanks.
<rvr> bzoltan_: Approving silo 57
<rvr> alf_: jibel: I already checked that they were approved
<Mirv> rvr: bzoltan_ oSoMoN: what's up with 57 really, QA has checked it but webbrowser never built in the PPA for any of the archs, on Tuesday? is it supposed to be published by first removing the webbrowser-app, or...?
<Mirv> so the silo status was never "Packages built" even though it was sent to QA
<Mirv> 5 failed QmlTests on each arch
<rvr> Mirv: Hmm
<Mirv> if the UITK is good to go as is too, maybe it's ok to publish but it's clearly not "clear" as is
<oSoMoN> Mirv, webbrowser-app needs to be published together with uitk, I expected bzoltan_ to handle that silo
<oSoMoN> Mirv, can you please retry the failed builds for webbrowser-app there?
<oSoMoN> Mirv, note that itâs only autopilot tests changes for webbrowser-app, so rebuilding shouldnât invalidate all the testing done so far
<Mirv> oSoMoN: since it failed tests on all archs on both releases, I assume it's not really going to work... but ok, rerunning them
<Mirv> QmlTests::TabsBar::test_context_menu_close() Uncaught exception: Cannot read property 'x' of undefined
<oSoMoN> huh, let me check the failures, IÂ assumed it was only the favicon fetcher unit test failing
<Mirv> no, nothing to do with those
<oSoMoN> Mirv, would you mind re-running them anyway, to get fresh failures?
<Mirv> rvr: bzoltan: oSoMoN: ok, AP only fix at least make the situation much easier, no wasted resources from QA etc
<Mirv> oSoMoN: ok
<Mirv> oSoMoN: I find it weird also it seems the favicon test passed on all on the first run :S
<oSoMoN> Mirv, thereâs definitely something fishy there!
<Mirv> oSoMoN: oh, ok, no it didn't
<Mirv> oSoMoN: just luck I guess
<Mirv> oSoMoN: the first two x86 I checked were ok, but found one where there were both qmltests and favicon failing
<Mirv> oSoMoN: ok, retrying all 6 builds now
<oSoMoN> thanks
<oSoMoN> Mirv, bzoltan_: wow, indeed unit tests reliably fail, looking into it
<brendand> sil2100, are those images on their way?
<sil2100> brendand: in one moment :)
<oSoMoN> bzoltan_, maybe we should add to your test plan: rebuild webbrowser-app with the new UITK, as there are a growing number of autopilot tests that are being replaced by unit tests
<boiko> robru: on silo 11, bileto is showing 3 times the status for the same build job, is that expected?
<kenvandine> sil2100, is the ubuntu-pd image manually created or is it scheduled?
<sil2100> kenvandine: we manually kick those for now, but I can add it to the crontab if it's useful :)
<kenvandine> could you spin another?
<kenvandine> there are a ton of updates that take ages to apply :)
<sil2100> kenvandine: yeah, I want to do that as I modified the seeds :)
<kenvandine> but of interest is the update for libertine :)
<sil2100> I'll kick one in a moment
<kenvandine> thx
<rvr> alf_: Where can I see the unity8 autopilot test results for silo 14?
<rvr> alf_: Ok, found. There are two failures in Wily https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/461/
<dbarth> o/ trainguards, i need the account-polld packages to be removed from ppa 040 to release a landing
<sil2100> kenvandine: an image should be building soon... there's ubuntu-touch building now as well so I'm not sure if this won't slow things down
<sil2100> brendand: new image building
<sil2100> Damn, I was too fast, just hope it'll pick my new livecd-rootfs :|
<kenvandine> sil2100, thx
<alf_> rvr: ok, I will take a look, although these don't seem related to my changes...
<sil2100> Yeah, I think I kicked it too soon, bleh
<alf_> greyback_: I have been getting some autopilot testing instability with unity8 CI causing it to fail, and making the QA team nervous (https://code.launchpad.net/~afrantzis/unity8/power-state-change-reason-snap-decision/+merge/272233).
<alf_> greyback_: How do we deal with this? I have retriggered another CI run hoping it will pass this time...
<sil2100> brendand: hope you won't mind another ubuntu-touch image a bit later
<greyback_> tsdgeos hey, would your experienced eye notice anything obvious wrong with the above ^^
<greyback_> those 2 tests have nothing in common afaict
<tsdgeos> greyback_: the autopilot are a bit unstable still
<greyback_> alf_: ^
<tsdgeos> unless both wily and vivid fail in the same spot or you see a direct correlation with the code changed
<tsdgeos> it's most probably just noise
<oSoMoN> Mirv, bzoltan_: I can reproduce the unit test failures locally, looking into fixing them
<tsdgeos> alf_: greyback_: the vivid autopilot succeeded so i'd say that's just fine
<tsdgeos> alf_: in fact you were the sole lucky person with a total green in the last runs afair :D
<alf_> tsdgeos: greyback_: ok, so I will tell QA to just ignore this
<alf_> rvr: ^^
<rvr> alf_: tsdgeos: Isn't it a dual landing?
<tsdgeos> rvr: i don't understand the question
<rvr> tsdgeos: Silo is marked for dual landing, wily and vivid. Vivid passes, wily fails.
<tsdgeos> yes
<rvr> tsdgeos: What's the rationale for ignoring it?
<tsdgeos> as i've said our autopilot tests are unstable
<tsdgeos> i don't know why you'd be blocking this and not any of the 100 previous landings of unity8 because of that
<oSoMoN> Mirv, bzoltan_:Â ok, IÂ think IÂ know how to fix this, and the good news is that it wonât involve changing actual app code, only unit tests, but I have to go to a doctor appointment now, Iâll get back to it in the evening, and will request a new build in the silo once fixed
<rvr> tsdgeos: It may be unfair to get a ticket on a highway for going at high speed, when usually no one is ticketed. It's called bad luck ;)
<Saviq> rvr, can you see a reliable failure, or is it just a flaky test (i.e. does the test work when you try it again alone?)
<rvr> alf_: I won't be blocking the silo, if the failure is not related
<rvr> Saviq: Sorry, which silo are you talking about now?
<Saviq> rvr, alf_'s
<rvr> Saviq: Ok. I just checked the silo results, didn't check previous runs.
<Saviq> rvr, alf_, when testing a unity8 silo I always run the whole suite and then re-run any initially failed tests, there often is one or two that fail but pass when re-ran
<Saviq> I can help with that if you need
<Saviq> it's a relatively new situation that we have to look into still
<rvr> Saviq: Do you know whether these tests usually fail? https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/461/
<Saviq> rvr, there is no "usually fail" currently, they are unfortunately random
<rvr> Saviq: I see
<Saviq> rvr, also, that's wily, they passed on vivid
<Saviq> rvr, basically, I re-confirm manually every time when landing
<Saviq> but we do need to understand where those failures are coming from
<rvr> Saviq: Yeah, I saw they are passing in vivid
<alf_> rvr: Saviq: also, fwiw, the previous revision of the branch managed to pass all tests (which I understand is quite rare), and the latest revision (the one we are discussing) didn't actually change any behavior, it added a (currently) unused value to an enumeration which shouldn't affect anyone/thing
<Saviq> indeed
<rvr> alf_: Saviq: Ok, thanks for the insight. I'll begin the silo validation.
<alf_> rvr: great, thanks
<alf_> rvr: Also note that we do appreciate your concern about unstable tests and thanks for keeping an eye open for them. Unfortunately, it seems that for the time being we need to be a bit less strict, until we find the cause of the instability.
<rvr> alf_: No problem.
<sil2100> robru: pong
<sil2100> robru: ok, since I wasn't able to finish this up during my day today... could you switch dual landings to land wily to the overlay automatically?
<robru> boiko: yep the audit log for 11 looks as expected to me. Each status is recorded
<boiko> robru: yeah, I saw your mail about that after I had already complained, sorry for the noise :)
<robru> Mirv: I see your comments https://requests.ci-train.ubuntu.com/#/silo/54
<robru> boiko: no worries
<robru> sil2100: can do, just need to find some coffee
<Mirv> robru: I don't see them under https://requests.ci-train.ubuntu.com/#/user/timo-jyrinki , but yes under your direct link
<Mirv> robru: nor in main view. I think comments used to be shown without opening the direct link before?
<Mirv> robru: it was confusing since I entered a comment, clicked the button and it just disappeared
<sil2100> Mirv: it changed with recent changes, from what I remember from the e-mail
<robru> Mirv: yes I mentioned in the email that comments are hidden if more than 4 requests are displayed to cut down on massive amounts of audit log spam. when I redesign the site I'll be sure to prevent you from being able to add comments on pages where they won't be shown
<Mirv> robru: ah right, now I remember, didn't connect! thanks :)
<sil2100> ogra, pmcgowan: the livecd-rootfs change for the apt lists removal made the rootfs tarball smaller by 11.8 MB - didn't check how much real space we got, but it's still pretty nice
<pmcgowan> sil2100, thats a good direction and on disk is more
<pmcgowan> real space was 60-80 as I recall
<Saviq> robru, hey, is it on purpose that the build job complains about packages missing in the PPA even though I only built a subset?
<Saviq> https://requests.ci-train.ubuntu.com/#/ticket/445
<robru> Saviq: yes, that is on purpose. it used to be that the status would say 'packages built', which is wrong because not all packages are built.
<Saviq> robru, but the build job completed, maybe it should be less error-y?
<Saviq> robru, basically, sure, I'd like a note that some packages should be, but are not, available in the ppa, but the build job actually completed fine
<robru> Saviq: I consider packages not being built to be an error condition :-P
<Saviq> robru, it might be I'm abusing the packages field in the build job, because I'm building dependencies first, only then the dependents
<Saviq> robru, which means it will always complain in that sense
<robru> Saviq: yes, if you set the correct versions in your Depends: in the packaging then the PPA should be able to work out what order to build them in
<Saviq> maybe I should just rely on dependency waits, but historically I remember that taking a long time :P
<Saviq> but also sometimes there's no hard dependency on a new version
<Saviq> but you want a rebuild to let debsyms do its thing
<robru> Saviq: but if you're depending on a new feature in a new version, it's kinda broken not to specify that version in your Depends:
<Saviq> robru, not what I meant, if you're depending, obviously you need a Depends, I was rather thinking if the dependency changes ABI in a backwards-compatible way... but then there's no rebuild necessary
<Saviq> because it's backward compatible, and through .symbols file the resulting dependency should be as appropriate anyway
<Saviq> so ok, dependency waits it is then
<robru> Saviq: well no, if you want to selectively build parts of the silo that is a supported thing to do. it's just that now it helpfully tells you which packages you didn't build yet :-P
<Saviq> robru, yeah, I just wouldn't call that an error condition :)
<Saviq> rather the "helpful notice"
<robru> Saviq: it's tough to get right, since everything that gets reported from that part of the code is considered an error
<robru> not sure how I'd fix that, I'd have to define a new exception that isn't considered an error. would rather keep it an error, makes the code simpler.
<Saviq> robru, ack, was just scared that there was an actual build error, and the "None" bits in it suggested something broken even more
<robru> Saviq: actually the part I thought was weird was that it was looking for a specific qtmir version, not sure where it got that version number from
<Saviq> robru, I think that's because there was an actual failed build before
<robru> ah ok
<Saviq> in that same silo/assignment
<robru> audit logs don't go back that far ;-)
<Saviq> yup
<jhodapp> robru, can you please dput qtmultimedia source package from ppa:jhodapp/ubuntu/ppa to the silo 55 PPA
<robru> jhodapp: done
<jhodapp> robru, thanks man!
<robru> jhodapp: you're welcome
<bdmurray> bug 1469398 is being fixed in the overlay PPA and doesn't need SRU'ing to vivid right?
<ubot5`> bug 1469398 in Canonical System Image "Push-client should be disabled when no network connection" [High,Fix committed] https://launchpad.net/bugs/1469398
<Guest97502> bdmurray, yes
<jhodapp> robru, one more time for dput qtmultimedia source package from ppa:jhodapp/ubuntu/ppa to the silo 55 PPA, the build failed last time but I verified locally it builds now
<robru> k
<robru> jhodapp: done
<jhodapp> robru, think I have a good process recorded for this now that will alleviate errors in submitting and building a new qtmultimedia :)
<jhodapp> robru, thanks
<robru> jhodapp: cool, you're welcome
<robru> jhodapp: what are you doing? You can't mix syncs and merges... I'm not sure that will do what you expect
<jhodapp> robru, who's syncing?
<oSoMoN> Mirv, bzoltan_: if youâre still around, I fixed the webbrowser-app unit tests in the branch thatâs in silo 57, and IÂ just triggered a new build
<jhodapp> robru, I'm just trying to get a build where it doesn't try and build -gles
<jhodapp> robru, which IGNORE_MISSING_TWINS doesn't seem to be honoring
<robru> jhodapp: you request is configured to sync from silo 29.
<robru> "Not found in archive" means it is failing to sync the package from that ppa
<robru> See the log for details
<jhodapp> robru, huh, seems the silo config changed while I was away
<robru> jhodapp: to bad it doesn't say who. I have a branch that would record that but it's not in production yet
<jhodapp> robru, oh it's xavi with indicator-sound
<jhodapp> robru, that's a weird setup then...29 has indicator-sound in it, 55 has media-hub, qtubuntu-media and qtmultimedia in it
<robru> jhodapp: are they supposed to all be the same?
<jhodapp> robru, well before my holiday I had told xavi to just put indicator-sound into 55 as well, not sure why he set it up to sync instead
<jhodapp> robru, so I guess I can just have 55 build everything except indicator-sound and -gles, that should work right?
<robru> jhodapp: yeah that's weird and wrong, if you want the package copied let me know, take the sync out of the request
<jhodapp> robru, yes please, there's no reason to have it separate since it's not going to land independently of the other things like media-hub, etc
<robru> jhodapp: OK one sec
<jhodapp> thanks
<robru> jhodapp: oh 29 has a merge, why not just put the merge into the right request?
<robru> jhodapp: I thought 29 would have a manual source that would need manual copying
<jhodapp> robru, yeah I can do that
<jhodapp> robru, I thought it did too, it was listed as a source package in 55
<robru> jhodapp: currently it's listed as a *sync* package, but yeah
<robru> jhodapp: yeah please clear out the sync_request, drop indicator-sound from source package list, move the MP from silo 29 to 55, rebuild 55, and abandon 29.
<jhodapp> robru, ok, did that, building now
<robru> jhodapp: ok, request looks good
<jhodapp> robru, so since pressing save while editing a config automatically reconfigures, do I need to give it some time before doing a build or is it ready to go right away after save?
<robru> jhodapp: it's ready to go right away. there's no "automatically reconfigures", I just made jenkins load data directly from bileto instead of storing a "config" that requires "reconfiguring". basically reconfiguring isn't a thing.
<jhodapp> robru, nice, I like that :)
<robru> jhodapp: thanks, yeah there's lots of things like that I'm trying to streamline
<robru> jhodapp: one day jenkins itself will go away and bileto will just absorb it all
<robru> but that's a ways off yet
<jhodapp> robru, nice, your own CI tool
<robru> jhodapp: good god it sounds terrifying when you say it like that ;-)
<jhodapp> lol
<jhodapp> robru-ci
<jhodapp> :)
<robru> that would sure look good on my resume!
<jhodapp> no doubt
<jhodapp> robru, any way to force that version for indicator-sound?
<robru> jhodapp: no, your trunk is wrong, you need to fix it
<jhodapp> robru, oh, hmm...will need xavi to take a look then
<robru> jhodapp: or rather, are you sure this should be a vivid silo and not a dual silo?
<robru> jhodapp: the error is that you have a wily trunk and you're trying to build it for vivid which is bad and wrong
<robru> you're not allowed to go backwards
<jhodapp> robru, perhaps that's why it was separate then, the media stuff can't be dual landing yet
<jhodapp> right
<robru> jhodapp: so you need to either s/15.10/15.04/ in your trunk changelog (eg, branch for vivid), or make it dual
<jhodapp> robru, but indicator-sound probably is
<robru> jhodapp: what's holding it back from dual?
<robru> oh because it's manual sources
<jhodapp> robru, vivid doesn't have the same wily gstreamer or platform-api for starters, which the wily media stuff uses
<jhodapp> robru, once gstreamer 1.6.x releases we'll sync wily and vivid for the media stuff
<jhodapp> let me go back to using silo 29 then
<robru> jhodapp: ok so since silo 29 is dual and built (and you were smart enough not to abandon it like I told you to do), I can just copy the vivid package from there
<jhodapp> robru, well can't I just go back to a sync from 29, and only request 55 to build qtmultimedia, media-hub and qtubuntu-media and not hit an error with indicator-sound then?
<robru> jhodapp: no, because syncs & merges can't coexist, the train will become very confused. you need to leave 55 as "some merges and some manual sources" and then I can just copy that one package when you need it
<jhodapp> robru, alright, that'll work
<robru> jhodapp: brb tho
<jhodapp> k
<Saviq> robru, just noticed, what tz are the comments in?
<robru> Saviq: should all be UTC unless there's a bug
<robru> jhodapp: sorry did you want that copy now?
<Saviq> robru, they're not https://requests.ci-train.ubuntu.com/#/ticket/445
<jhodapp> robru, yes please
<Saviq> robru, unless it's missing am/pm and is written in 12h clock
<robru> Saviq: that's possible. if you look at the raw json (s/#/v1/ in the URL) it looks to have correct UTC timezones
<robru> Saviq: so just a display issue
<robru> Saviq: will fix, and roll it into a larger rollout later today
<Saviq> kk
<Saviq> robru, it could probably even display in local time (not to mention human-readable times)
<robru> jhodapp: oh, copying failed because that version number already exists in silo 55. LP claims they have different contents though. if you want me to copy you'll need to rebuild 29
<robru> Saviq: what do you consider human readable?
<jhodapp> robru, rebuild with a new version I assume?
<Saviq> robru, 5 mins ago, yesterday etc.
<robru> jhodapp: yeah, rebuilding 29 will make a new version number that I can copy
<robru> Saviq: oh, twitter style.
<robru> Saviq: not sure if I'll implement twitter style timestamps today but I'll at least fix the display
<jhodapp> robru, ok, will have to ask xavi...it's not my MR
<Saviq> robru, sure, nw
<jhodapp> I'll write him an email
<Saviq> robru, I'd put the actual timestamp in a tooltip probbaly
<Saviq> probably, even
<robru> Saviq: lol, js thinks it's localtime but it's not
<robru> Saviq: ok, trunk is fixed to show 24h clock in local time, hoping to roll out in a few hours with some other features.
<Saviq> robru, great, tx
<robru> yw
<oSoMoN> robru, can the failed builds for webbrowser-app in silo 57 be retried, please?
<robru> oSoMoN: sure
<oSoMoN> thanks!
<robru> you're welcome
#ubuntu-ci-eng 2015-10-02
<Mirv> robru: diff:ing errors in publishing https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/120/console
<Mirv> robru: and then it fails apparently on assuming the diff would have packaging diff, while the mir seemingly would not have
<Mirv> just in case, I try to watch_only build
<Mirv> robru: yeah the diff:s are zero sized https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/248/
<robru> Mirv: oh god. Let me look
<robru> Mirv: oh, I see
<robru> Mirv: sil asked me to flip the switch so that dual silos always publish to overlay now. so what's happening is those packages aren't in the overlay so it fails to find any old version, which is why the diff is 0
<robru> Mirv: if you look at the packaging diff it says it's a new package
<robru> Mirv: should this silo go to overlay?
<robru> i guess so if it's just phone stuff
<robru> I'll whip up some code to make it fall back on main archive if it can't find the package in the ppa.
<Mirv> robru: ah...
<Mirv> robru: so. if sil wanted to flip the switch, then yes I guess we want everything to dual land to overlay now.
<robru> Mirv: hmm actually there's already code that says "if version not found, check main archive", not sure why that didn't trigger...
<oSoMoN> bzoltan_, Mirv: hey, IÂ fixed webbrowser-app in silo 57 last night, as far as Iâm concerned itâs good to go, feel free to publish if youâre not waiting on anything else
<Mirv> robru: hmmkay.
<Mirv> oSoMoN: sure, we just have a slight breakage :)
<Mirv> oSoMoN: plus the UITK has packaging changes so it'll need a core-dev.
<oSoMoN> right
<robru> Mirv: check if those packages are already in overlay ppa, it should be publishable if they are
<oSoMoN> Mirv, where is that breakage? in the train itself?
<robru> oSoMoN: yeah I broke the train so it can't publish things if they don't already exist in overlay ppa
<robru> working on it
<Mirv> robru: they are actually, it's still 0 size
<Mirv> robru: so it's not the fallback
<Mirv> robru: oh right but not wily, sorry
<Mirv> robru: of course there's nothing for wily in the PPA
<robru> Mirv: oh right, nothing would be there for wily
<robru> Mirv: yeah the "0 size" is not particularly meaningful, python creates those files first before debdiff gets involved, content diff being 0 size just means "debdiff had unknown errror"
<robru> Mirv: ok, I think I see what's happening. when it decides whether to use the overlay ppa vs the archive, it doesn't specify the series, so the vivid package says 'yep theres a package in the overlay ppa' then later when trying to diff it specifically says'ok overlay pp, gimme the wily version' and that fails
<robru> Mirv: so if I specify the series in the initial check it should work
<Mirv> right! thanks for looking into it. we could have workarounded by manual copying but it'll be good to have train back too.
<robru> Mirv: you're welcome. ok, fix pushed to trunk, will hit production in 20 minutes, try it again then and ping me if it still doesn't work.
<Mirv> ok
<bzoltan_> Mirv: robru: an we merge the landing MR to the trunk before the package is acked and published to Wily?
<Mirv> bzoltan_: no, packages aren't going to wily anymore, they go to overlay for wily series too
<bzoltan_> Mirv:  ohh, how shame
<robru> Mirv: should be safe to publish now
<Mirv> robru: hmm, looks good now. but I wonder why ^ without packaging changes and with a MP upload?
<robru> Mirv: is it in main?
<Mirv> robru: yes, in main, but I thought the exception still was canonical upstream projects handled with MP:s without packaging changes can be uploaded.
<Mirv> since I remember being mentioned that manual main uploads always require core dev publishing while MP ones wouldn't
<robru> Mirv: the artifacts have packaging changes
<Mirv> robru: sorry for firing so many questions, but I also think that https://ci-train.ubuntu.com/job/ubuntu-landing-057-2-publish/9/console - a main package _with_ packaging changes, used to complain about the need of an "ack" before failing about no right
<Mirv> robru: yes, but not for mir: https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/
<Mirv> robru: the others are universe packages
<robru> Mirv: packaging changes prevent the whole silo from being published
<Mirv> robru: yes, but it didn't complain about packaging changes but the upload rights.
<robru> Mirv: when deciding to publish it doesn't consider each package individually, you need to have permission to upload everything
<Mirv> robru: I'll try 014 with 'ack' checked, since that's what it'd require for the universe packages.
<Mirv> robru: yes, but the one main package without packaging changes would also be allowed by current policy.
<robru> Mirv: that's just how the check works. If there are packaging changes and you don't have rights, it says "not authorized", it only says "need ack" if you have the ability to give an ack
<Mirv> robru: it seems 014 worked with 'ack', right. I think functionally it's all good, just a bit confusing it complains about no rights to upload mir package while actually there are rights to upload that one, and the real erroring out reason was the lack of an ack for packaging changes in universe package.
<robru> Mirv: yeah that could be reported better i guess. Right now the error just goes by the first wrong thing it sees
<Mirv> robru: so in case of 014, I did have the ability to 'ack', and the error it gave was not really a problem since mir didn't have packaging changes itself.
<robru> 7 silos marked dirty by that, jeez people are really abusing conflicting silos these days.
<Mirv> robru: but no problem, understood again
<Mirv> oh really...
<Mirv> there's also huge amount of webbrowser silos
<Mirv> robru: aaaaanyway, everything good, logic understood, I'll just need to find a core-dev for 057.
<robru> When i wrote the dirty logic i expected any silo to have at most one other conflicting one
<robru> Lol, audit logs are online for a day and we're already up to comment id 397, i should figure out how postgres stores primary keys, check at what point it will integer overflow
<oSoMoN> robru, Mirv: QA is the bottleneck here, there wouldnât be so many webbrowser-app silos if there was more throughput
<oSoMoN> and also the fact that I noticed only yesterday that webbrowser-app was failing to build in silo 57
<robru> Mirv: strange that 14 didn't migrate yet, it should copy & merge immediately (no proposed in overlay)
<robru> Mirv: can you check that all the packages are in overlay and if so, manually merge silo? And file a bug that migration is broken.
<robru> Mirv: i assumed it would check the dest ppa but i guess something isn't using the right archive property.
<seb128> Mirv, is there a way to make packages go to wily rather than the overlay?
<seb128> seems weird to force the overlay, some bugfixes can still be useful to wily
<robru> seb128: i had fixed that but slangasek requested all packages go to overlay. If you really want a train fix in wily you can copy from ppa yourself
<seb128> I don't want a train fix, I just discuss the principle behind the decision
<seb128> but I guess I should discuss it with slangasek
<Mirv> robru: seems they are all there, merging + filing
<robru> seb128: i mean, if you have a bugfix in a train silo and you want this in wily, you can copy the package to wily yourself for now. But yes, take it up with slangasek because i had enabled users choosing where to publish to and then he told me to enforce it train-wide
<seb128> k
<robru> seb128: oh actually also this enforcement is only for dual silos, so if you are just working on some desktop only stuff you can just have a wily silo and publish to wily, i forgot about that
<jibel> robru, thanks for the auditable logs. One more thing though bug 1502018
<ubot5`> bug 1502018 in Bileto "Differentiate automated comments from user comments" [Undecided,New] https://launchpad.net/bugs/1502018
<seb128> yeah, that makes sense
<robru> jibel: the ones that have the "log" link are generated ones ;-)
<jibel> robru, nope
<robru> jibel: is it enough to make the user comments bold or something? Man you're picky!
<jibel> robru, if it's a status change there is no indication
<robru> jibel: but the status change is always just "Updated x" it's short...
<jibel> robru, I think this comments are useful to understand what happens with a landing but most of the time they are not useful to the lander and could be hidden
<Mirv> seb128: if you have time, please check the UITK diff and publish 057 since it's a main package https://ci-train.ubuntu.com/job/ubuntu-landing-057-2-publish/9/ (adds dependency on liblttng-ust-dev which is in main, and adds two new binary packages)
<jibel> robru, like, it is a bit like it's very useful to have a syslog but you don't want it all time on your terminal :)
<robru> jibel: well I'm halfway through a full site redesign so i guess it's a good time to consider these things. I'll have a live demo up next week, we can iterate on it before going live
<jibel> robru, sure
<jibel> robru, sounds good to me
<robru> Alright goodnight everybody!
<Mirv> robru: good night!
<Mirv> and thanks for the fixes and features!
<jibel> godd night robru
<jibel> good*
<seb128> Mirv, looks fine to me
<robru> You're welcome!
<Mirv> seb128: you need to run the publish job too, nowadays just verbal ack is not enough
<Mirv> seb128: train checks whether the person would have archive rights for the packages in question (if their MP:s have packaging changes)
<seb128> Mirv, even if you don't upload to the archive?
<seb128> Mirv, done
<seb128> looks like oSoMoN and dbarth like to claim silos for webbrowser ;-)
<bzoltan_> seb128: Thank you a bunch :)
<seb128> bzoltan_, yw!
<dbarth> yeah
<dbarth> cool, so now i go first for the next webbrowser-app landing ;)
<bzoltan_> dbarth:  sorry mate :) I had to push a fix for the browser to prevent AP breakage with the new UITK. I take all blames :)
<oSoMoN> dbarth, yep, silo 25 then 59
<dbarth> yup; bzoltan: nw
<Mirv> seb128: thanks a lot! yes, it's enforced even for overlay which is thus treated like on archive (even though in reality we could copy packages there manually).
<Mirv> sil2100: hey just FYI auto-mergeclean is busted at the moment probably due to the switch to overlay-only, so one needs to check everything landed to overlay and run merge & clean manually
<Mirv> dbarth: hey, the webbrowser-app trunk was not pushed yet...
<Mirv> dbarth: now it is, aborting your 025 build and rerunning
<jibel> dbarth, silo 16 is for OTA7?
<dbarth> trying, but just in the middle of a call
<dbarth> ok, so i need to wait a bit still
<dbarth> jibel: hopefully, silo 16 contains the memory limits improvements
<dbarth> we need to test it a bit, but based on initial reports, that's the one to take
<sil2100> Mirv: ACK!
<jibel> dbarth, very nice, thanks!
<bzoltan_> Mirv:  we need this project on the train and land it on the Vivid Overlay PPA - https://launchpad.net/ubuntu-sdk-qmake-extras What should I do?
<Mirv> bzoltan_: set owners/managers/members correctly, I can do that after this hangout
<Mirv> (if there's something to do)
<Mirv> bzoltan_: + packaging with .bzr-builddeb etc from https://wiki.ubuntu.com/DailyRelease/InlinePackaging in the code
<bzoltan_> Mirv: Ok, thanks for reminding me :)
<Mirv> bzoltan_: the .bzr-builddeb needs to be in /, not debian/
<bzoltan_> Mirv:  Of course
<Mirv> bzoltan_: so.. I think the project might be just good to go as is. I think it's better to try and see if anything fails, but the ci-train user that's needed is in SDK team so it should be ok.
<sil2100> Oh no, the buteo silo has a lot NEW packages
<Mirv> sil2100: I've saved a note from cjwatson "I think we should stop bothering with preNEW for new sources, and only keep it for new binaries"
<Mirv> since train does not bypass src NEW queue
<Mirv> I don't at least misquote him, hopefully also I don't misuse the quote :D
<Mirv> sil2100: but the packagings should be reviewed normally as for universe packages of course
<sil2100> ;)
<sil2100> Indeed, yeah
<sil2100> Most of the packaging was prepared by kenvandine, so this should be relatively fast
<Mirv_> dbarth: 025 is now ready (just one i386 still building), please hand it over to QA swiftly so that the big webbrowser queue can be processed...
<dbarth> Mirv_: cool; thanks for that
<dbarth> i know webbrowser-app builds take some manual care currently
<Mirv_> jibel: I bootstrap flashed latest rc-proposed and upgraded to a silo (which dist-upgraded, so new mir etc too), and I've Unity 8 restart loop now even after purging my PPA. Care to double-check?
<sil2100> Mirv_: I'm still thinking about requesting a preNEW review here though
<cjwatson> Mirv_: you do not misquote me
<sil2100> Mirv_: since... it's a dual silo, so the change gets directly to the overlay
<sil2100> It bypasses the NEW queue and will be picked up only when we copy to W+1
<cjwatson> right, preNEW is for cases where NEW ought to exist but doesn't
<jibel> Mirv_, sure, which silo? which device?
<Saviq> sil2100, wily images don't have overlay enabled yet?
<Mirv_> sil2100: does the copy to W+1 bypass the queue any more than train?
<Mirv_> jibel: what I meant is: use current rc-proposed and dist-upgrade (to get today's landings like 014) and try that. I'm on mako.
<sil2100> Saviq: no, not yet, but will be now - Robert was switching to overlay-only landings when I was EOD already
<Saviq> kk
<sil2100> Mirv_: ok, the packaging looks okay to me so far, it's been worked on/reviewed by kenvandine and seb128 for most cases too
<jibel> Mirv_, yeah but I'd also like to check if any leftover from the silo would cause the reboot loop
<sil2100> seb128: hey! Could you perform a few preNEW reviews in the buteo silo for us? :)
<Mirv_> jibel: well it's my 032 which is not going to land any time soon (if ever, before Qt 5.5)
<sil2100> seb128: the links are: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-034 for the PPA and https://ci-train.ubuntu.com/job/ubuntu-landing-034-2-publish/6/ for the artifacts
<Mirv_> sil2100: ok then
<jibel> Mirv_, which channel exactly rc-proposed/ubuntu?
<Mirv_> jibel: ubuntu-touch/rc-proposed/ubuntu
<seb128> sil2100, can try this afternoon yes
<sil2100> seb128: thanks!
<sil2100> davmor2: ^ the buteo silo will wait a bit before landing, we need a preNEW review
<sil2100> But I think it should still be ok to test it live today
<davmor2> sil2100: sure just give me a ping I'll make sure I have images ready
<jibel> sil2100, we are already far past feature freeze, if it doesn't land today, it will be for OTA8
<dbarth> jibel, davmor2: ticket 412 / silo 25 re-tested here; on to you now
<seb128> yw!
<jibel> dbarth, thanks, unblocking
<dbarth> jibel: however oxide 1.9.4 has a regression; we're investigating :/
<dbarth> but memory usage doesn't balloon as high as before
<sil2100> jibel: +1 on that
<jibel> Mirv_, it looks bad, unity8 crashes apparently
<jibel> sil2100, don't rebuild any image yet there is something broken in the ovelay
<jibel> overlay*
<sil2100> Oh
<jibel> sil2100, it would be the last unity8/mir/powerd landing
<jibel> https://requests.ci-train.ubuntu.com/#/ticket/343
<jibel> Mirv_, did you collect any info about the crash?
<jibel> I'll try on krillin
<sil2100> Do you know already which image was the one first broken?
<jibel> sil2100, the broken image doesn't exist yet, it'll be next one
<rvr> jibel: I approved last night silo 15, which contains unity8, powerd, mir, system-compositor
<jibel> rvr, on which device
<jibel> ?
<rvr> jibel: arale
<jibel> maybe it's only a problem on mako
<jibel> I'm trying krillin now
<rvr> Remember that powerd needs manual fix to properly install
<rvr> the ppa packages may not finish installing
<Mirv_> jibel: I tried looking at the logs but reflashed already (but obviously can easily get it back to broken state)
<Mirv_> rvr: jibel: rvr's point might be the thing, I just used citrain tool
<Mirv_> so it might be all resolved with the next image
<Mirv> sil2100: if ^ that's the thing, it might be useful to have a new rc-proposed image since otherwise people flashing latest image + upgrading to their newest silo will experience that
<Mirv> but let's confirm first
<sil2100> Ok, once you confirm we'll kick a new image
 * Mirv has to eat late lunch
<sil2100> ogra_: hey hey, could you review+merge https://code.launchpad.net/~sil2100/livecd-rootfs/fix-apt-lists-rm-hook/+merge/273117 ? This is the hook that works ;p
<sil2100> cjwatson: hey! Could you take a look in a free moment at https://code.launchpad.net/~sil2100/ubuntu-cdimage/enable_wily_overlay/+merge/273208 ?
<cjwatson> sil2100: isn't there somebody else who could be the routine cdimage reviewer?
<cjwatson> I'm not a good candidate
<cjwatson> because I don't do most of the day-to-day stuff of keeping cdimage running any more
<sil2100> cjwatson: not sure, I guess I might poke infinity as he has the most commits (but he's a different TZ) - not sure if stgraber is still working on it anymore
<cjwatson> sil2100: I'll do it this time, but please try to find somebody who isn't me for the next one
<sil2100> cjwatson: will do, thanks!
<jibel> sil2100, Mirv krillin is not affected by the shell crash, only mako apparently
<cjwatson> sil2100: merged and deployed, thanks
<cjwatson> including manual crontab edit
<sil2100> Thank you again!
<sil2100> jibel: so it's unrelated to powerd?
<rvr> sil2100: Apparently not
<jibel> sil2100, there is no problem with the upgrade of powerd on mako because the configuration file is not mounted
<jibel> unlike krillin or arale
<jibel> sil2100, Mirv bug 1502093
<ubot5`> bug 1502093 in unity8 (Ubuntu) "unity8 crash on mako rc-proposed/ubuntu with latest unity8/mir/powerd" [Undecided,New] https://launchpad.net/bugs/1502093
<jibel> kgunn, ^ with silo 15 that landed yesterday on mako only
<rvr> Mode argument was not provided or was set to an illegal value. Using default value of --mode= "full-greeter"
<Mirv> jibel: thanks! right, so mako only which probably explains why it wasn't caught.
<jibel> Mirv, thanks for catching it!
<sil2100> Still, we'll need this fixed
<oSoMoN> seb128, is it known and on purpose that https://code.launchpad.net/~seb128/ubuntu-system-settings/location-desktop-usr/+merge/272711 is in two silos?
<kgunn> jibel: ack getting someone on it
<jibel> kgunn, I didn't find anything useful but the phone is still in this state if someone needs more info
<kgunn> jibel: but bascially we can just do a dist-upgrade and see the same thing right
<kgunn> on rc-proposed
<kgunn> rvr: is this relevant "Mode argument was not provided or was set to an illegal value. Using default value of --mode= "full-greeter""
<jibel> kgunn, yes
<jibel> yes to install latest rc-proposed on mako + dist-upgrade
<sil2100> jibel, kgunn: I poked alf_ on ubuntu-mir already
<kgunn> sil2100: thanks
<seb128> oSoMoN, unsure, to check with kenvandine, but if you want to land a silo with it feel free, we can rebuild the other one
<Mirv> davmor2: trello claims 025 was moved to Under Testing in the Activity, but still it's in "Ready for Testing" on the board. it also has Blocked tag, and you mentioned it's working fine. Can you try to fix the status of the card?
<davmor2> Mirv: we will move the card once we know it is working with the ota test if that fails it needs to move over to failed
<oSoMoN> seb128, none of them is mine, just saw it and I thought IÂ would ask
<Mirv> davmor2: thanks, I was just puzzled by the Trello showing contradicting information
<oSoMoN> seb128, but I would need to add the branch to silo 59 if it didnât land before that
<davmor2> Mirv: no worries there is a comment on the card but I'm happy to clarify :)
<seb128> oSoMoN, let's wait for kenvandine, we can maybe land the settings one today
<oSoMoN> seb128, thatâd be great
<seb128> unsure about the unity8-dash profile
<seb128> pstolowski, ^ what's the status of silo 3?
<pstolowski> seb128, we need bigger fix as it uncovered an issue with location. tvoss is going to work on location service changes
<seb128> k
<seb128> so settings is going to be ready first most likely
<pstolowski> seb128, yeah, but we cannot release it as is. feel free to land you change at any point though
<seb128> right
<davmor2> Mirv: sorry I think we were talking at cross purposes, silo025 is under test now, silo 34 is the one that should have the mixed state
<davmor2> Mirv: silo34 is the one that is good and sil2100 will be landing in an image asap for me to test upgrades
<sil2100> Yeah, waiting on a preNEW review for 34
<Mirv> davmor2: no, I just meant that on my trello view 025 was in a different place than the activity showed, now it's corrcet
<davmor2> Mirv: so the blocked tag was removed because it has been rebuilt, it was therefore ready to test so I moved it to under testing because I'm testing it
<Saviq> sil2100, should we pull the silo before it reaches an image?
<Saviq> https://requests.ci-train.ubuntu.com/#/ticket/433 is the offending landing
<sil2100> Saviq: I think we could soft revert this, it only touches 2 projects
<sil2100> Let me try that, need to check if webbrowser-app is revertable still
 * sil2100 got back from lunch
<Saviq> sil2100, no need to revert webbrowser even I think, it doesn't depend on new UITK it doesn't seem
<sil2100> I was worried by the merge description though, it being: "Do not select labels by their class name, as this is changing in the newest UITK."
<Saviq> sil2100, I think the change (in webbrowser) is backwards compatible, and if it's not, someone's missing deps
<sil2100> Saviq: I guess anyway even if the AP test suddenly fails it's still better than having a broken image
<Saviq> indeed
<pmcgowan> Saviq, whats the deal?
<Saviq> pmcgowan, latest UITK crashes QML (so unity8) on mako and flo
<pmcgowan> thats bad
<Saviq> https://launchpad.net/bugs/1502093
<ubot5`> Ubuntu bug 1502093 in ubuntu-ui-toolkit (Ubuntu) "UbuntuShape crash with latest UITK on mako/flo" [Undecided,Confirmed]
<pmcgowan> that would have been my guess
<Saviq> pmcgowan, greyback_'s suspecting driver bug at that point
<pmcgowan> yep
<Saviq> OTOH wily is fine
<sil2100> Good, then I'll only have to revert it for the overlay then?
<sil2100> I mean, for vivid-overlay
<Saviq> sil2100, it's in wily overlay, too, let me verify quickly wily is indeed fine
<sil2100> Ah, right, this was already after the switch
<pmcgowan> that wouldn't make sense to me
<Saviq> +1, but that's what it looked like before, I was focused on unity8 at that point, so might've not paid enough attention
<Saviq> so confirming on flo now
<Saviq> and mako for good measure
<Saviq> pmcgowan, off topic, did you hear about anyone losing the ability to adb into recovery on a manta (and hence the ability to flash it)?
 * Saviq can sideload, flash in fastboot, and adb to android, but no adb to recovery :/
<pmcgowan> Saviq, I have not
<pmcgowan> Saviq, my manta goes into a funny loop witht he screenn flashing, and will never shut down
<Saviq> pmcgowan, yup, saw that with flo as well
<Saviq> as if some input caused it to wake up
<pmcgowan> I suspect it needs an udpated device tarball
<pmcgowan> if I could find someone to update them
<Saviq> sil2100, pmcgowan, ah d'oh, no overlay on wily images yet, is why it was fine
<Saviq> greyback_, â
<Saviq> sil2100, yup, wily+overlay broken, too
 * sil2100 sighs
<sil2100> Ok, I'll revert it too
<sil2100> First, vivid
<sil2100> Saviq, Mirv, pmcgowan: reverting UITK vivid
<Saviq> bzoltan_, â
<sil2100> bzoltan_: ^
<sil2100> hmmm, some strange things with the wily part I see
<Mirv> sil2100: ok
<kenvandine> oSoMoN, it shouldn't be in 2 silos :)
<jhodapp> sil2100, can you please dput qtmultimedia source package from ppa:jhodapp/ubuntu/ppa to the silo 29 PPA?
<sil2100> jhodapp: sure, any re-versioning needed?
<jhodapp> sil2100, also, is it possible to remove qtmultimedia from the silo 55 PPA?
<kenvandine> oSoMoN, i created silo 49 for it yesterday
<jhodapp> sil2100, shouldn't be any need
<sil2100> jhodapp: sure
<oSoMoN> kenvandine, are you planning on landing silo 49 soon-ish ?
<kenvandine> yes... after 41
<kenvandine> which is being verified right now
<jhodapp> sil2100, trying to craft things in such a way that we can build indicator-sound and the source package for qtmultimedia in silo 29, then sync those two to silo 55
<Saviq> Mirv, sil2100, any updates on bug #1378245? with overlay citrain just dist-upgrades everything from the overlay ppa
<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
<oSoMoN> kenvandine, ok, thanks, so definitely in time for ota7, right?
<kenvandine> oSoMoN, oh, it's in a silo with unity8 too
<kenvandine> yeah, assuming qa verifies it in time :)
<oSoMoN> kenvandine, yes, thatâs why I was asking, it currently is in two silosâ¦
<kenvandine> oSoMoN, i'll make sure it's in ready for qa today
<oSoMoN> cheers
<kenvandine> it's unrelated to the unity8 fix in silo 3, so i'll remove it from that
<rvr> kenvandine: Hey. Does adb reboot recovery work for you in arale? I'm trying to install lxc-android-config, and after adb reboot recovery, I can't adb shell to the device
<kenvandine> rvr, no... you need to boot a special recovery
<Saviq> kenvandine, what's in silo with unity8?
<kenvandine> saviq some apparmor profile ?
<kenvandine> rvr, but... jibel pointed out you can install lxc-android-config without recovery
<rvr> kenvandine: jibel: With citrain or using another trick?
<sil2100> jhodapp: package removed and copied
<sil2100> Saviq: I don't have any news regarding that one sadly...
<Saviq> kenvandine, I'm worried the package in silo 41 conflicted with a landing from yesterday
<jibel> rvr, you unmount the file that breaks on upgrade then use citrin
<kenvandine> just unmount something...
<jibel> citrin
<jibel> citrain*
<rvr> jibel: Ok
<Saviq> kenvandine, train says unity8 is dirty, and I'd say it's likely true
<kenvandine> jibel, which file does he need to umount?
<Saviq> there's too many peoples landing unity8 at the same time...
<kenvandine> saviq: i'll rebuild unity8 in silo 41
<kenvandine> i already did that a couple times :)
<kenvandine> we have to get that wizard fix in
<kenvandine> Saviq, can i have a unity8 landing lock until rvr is done testing? :-D
<jibel> kenvandine, I never remember which one is powerd which one is lxc-android-config, let me check
<Saviq> kenvandine, yeah, sure, /me needs to start looking at silos in flight apparently
<Saviq> robru, what's the workflow with conflicting silos these days?
<kenvandine>  /lib/udev/rules.d/70-android.rules
<kenvandine> maybe that one?
<jibel> kenvandine, /lib/udev/rules.d/70-android.rules
<jhodapp> sil2100, thanks!
<sil2100> Saviq: I think everything is now handled by the 'silo is dirty' feature
<kenvandine> rvr,  sudo umount /lib/udev/rules.d/70-android.rules
<Saviq> sil2100, /me worried that's too late
<kenvandine> it won't let us publish if it's dirty
<Saviq> yeah
<Saviq> but that means you have to re-test
<Saviq> and potentially QA, too
<kenvandine> potentially
<kenvandine> but depends on the change too
<kenvandine> like silo 41 only changes one page of the wizard
<pmcgowan> sil2100, dont bother with the change to the watchdog until I talk to tony
<Saviq> kenvandine, well, sure, but what if the landing in the mean time changed it too, not even in a way that it conflicted VCS-wise, but runtime
<kenvandine> sure
<kenvandine> there is risk especially when APIs change, etc
<Saviq> which is why I mean "silo dirty" is too late
<Saviq> like with silo 22 it's not even dirty atm
<kenvandine> rvr, so after you umount that file, you can use citrain to install
<rvr> kenvandine: Thanks
<sil2100> Mirv, bzoltan_: hmmm... do you guys know what happened to the 1.3.1641+15.10.20150922-0ubuntu1 landing of UITK for wily?
<Saviq> but we've spent a good hour testing it, and we'd conflict with you if we wanted to put it under QA
<Saviq> now we're just gonna wait instead
<Saviq> it's fine in this case because we investigated a UITK breakage most of the time
<Saviq> but I'd be unhappy if we actually wanted to put it in under QA and only then realized there's another unity8 landing there first
<kenvandine> Saviq, i guess you can search for silos with unity8 and check the status
<kenvandine> and see there's another in ready for qa
<kenvandine> but... maybe that should be kind of like the dirty flag
<kenvandine> so you don't have to look for it
<Saviq> kenvandine, not even ready for qa, anything in flight
<Saviq> because someone else might be testing it by now
<sil2100> Mirv, bzoltan_: yyh, so it seems that landing was only released to vivid?
<kenvandine> just show another silo is in the qa queue
<Saviq> sil2100, ?
<kenvandine> Saviq, true
<Saviq> sil2100, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay?field.series_filter=wily
<Saviq> (if that's about uitk still)
<sil2100> Saviq: unrelated to the UITK regression, I'm talking about the previous UITK version
<kenvandine> Saviq, but even more of an issue for silos that have already been tested, like 41 has been in ready for qa for 24 hours
<Saviq> sil2100, right ok sry :)
<sil2100> Saviq: the previous one was a dual landing and only released to vivid (probably manually, I see errors in the publish job and a manual m&c)
<sil2100> And that makes me a sad panda!
<Saviq> kenvandine, yeah, which is why I will be manually looking for conflicting silos from now on, but feels like some wasted manhours
<sil2100> Mirv, bzoltan_: uuuh, and I see that the latest UITK-gles version is older than the UTIK main version that got released!
<sil2100> Mirv, bzoltan_: that's bad
<bzoltan_> sil2100: I am no sure what does that happen?
<sil2100> Mirv, bzoltan_: generally it's safer when normal and -gles packages have the same versions, as some packages can hard-dep on the specific version
<sil2100> And if -gles has a lower one, it can cause a FTBFS
<sil2100> Anyway, trying to revert it as well
<sil2100> bzoltan_: anyway, this means that whenever you rebuild UITK in a silo, be sure to also re-build the -gles version
<Mirv> sil2100: it might be this was the webbrowser-app rebuild that bzoltan_ didn't do
<Mirv> sil2100: if it wasn't run by specifying webbrowser-app only
<Mirv> sil2100: 20150922 was when gcc was broken, so it was on purpose only released to vivid, to catch up with the next release
<sil2100> Ok
<sil2100> Actually
<sil2100> hah, I'll revert the wily versions by removing the wily packages from the overlay!
<sil2100> Since it's the first wily-overlay release
<sil2100> phew, saves me some time
<kenvandine> seb128, i'm about to land the silo with all those new packages i had you review months ago :)
<seb128> kenvandine, \o/
<seb128> kenvandine, lucasz pinged me to preNEW review earlier
<seb128> trying to have a look today still
<kenvandine> seb128, you already did that :)
<sil2100> kenvandine: the buteo silo?
<kenvandine> you've reviewed all of these already :)
<seb128> yeah, unsure if things changed since
<kenvandine> sil2100, yes
<kenvandine> not packaging
<seb128> good
<sil2100> Yeah, I asked seb128 to do a preNEW review :)
<seb128> so one thing less to do ;-)
<kenvandine> really what's changed was our existing packages using it
<sil2100> If it's good, then please release!
<kenvandine> i am :)
<kenvandine> bfiller, renatu: i clicked publish on silo 34!  long time coming :)
<bfiller> kenvandine: woohooo!
<renatu> kenvandine, \o/, thanks
<kenvandine> DON!
<kenvandine> DOH!
 * renatu runs
<kenvandine> one package has an unbuilt revision :)
<kenvandine> indicator-transfer-buteo
<renatu> kenvandine, what is that?
<kenvandine> Revert cmake-extras usage.
<kenvandine> is the commit message
<kenvandine> not built in the silo
 * kenvandine rebuilds
<brendand> kenvandine, who's don and what did he do?
<kenvandine> haha
<Trevinho> trainguards, what's wrong here https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/304/consoleFull ? network issues?
<sil2100> Trevinho: hm, no, that looks like an error when building the package
<sil2100> I'll look at it in a moment
<Trevinho> sil2100: thanks, it went fine on previous rebuilds, not sure what happened
<rvr> kenvandine: Did you see this when installing lxc-android-config? http://paste.ubuntu.com/12638463/
<sil2100> Trevinho: you didn't change anything in the packaging, right?
<kenvandine> cp: cannot stat â/usr/lib/lxc-android-config/70-arale.rulesâ: No such file or directory
<kenvandine> not sure about that, i tested on mako
<kenvandine> the other messages are normal
<Trevinho> sil2100: nope, I just triggered a rebuild since mesa fixed an issue that caused us to fail testing on ppc64el
<kenvandine> jibel, ^^ thoughts?  sorry, you seem to know more about testing lxc-android-config than i do :)
<sil2100> Trevinho: could you re-build again? I suppose it might be something transient - if not, I'll then dig deeper
<Trevinho> ok
<jibel> kenvandine, you don't need that on mako only krillin and arale
<kenvandine> right
<kenvandine> just what should rvr do about that error?
<jibel> kenvandine, when you upgrade lxc-android-config on mako how does it fail?
<kenvandine> nope
<kenvandine> it doesn't fail
<kenvandine> although i did it in recovery
<jibel> it's all good then :)
<kenvandine> rvr saw that in his testing on arale
<rvr> Yup
<rvr> jibel: That was doing a manual pinning and apt-get upgrade
<jibel> rvr, silo 41?
<rvr> jibel: Yes
<jibel> rvr, that pastebin is when you installed from recovery?
<jibel> rvr, or a full session
<jibel> ?
<rvr> jibel: Nope, pinning and upgrade
<rvr> full session
<jibel> let me try
<Trevinho> sil2100: went good ^
<sil2100> \o/
<jibel> rvr, your pastebin is strange, this is error you should get if the file is still mounted http://paste.ubuntu.com/12638536/
<rvr> jibel: I unmounted the file
<rvr> That error is expected
<jibel> rvr, yeah, what is the problem then?
<rvr> jibel: If you unmount the file and install the package, do you see the warnings that I got?
<jibel> rvr, yes
<rvr> Ok. So my question is if they are harmless or not.
<jibel> rvr, it's telling you that it doesn't remove non-existing diversions and doesn't touch already existing diversions
<rvr> jibel: There is also "cp: cannot stat â/usr/lib/lxc-android-config/70-arale.rulesâ: No such file or directory"
<Saviq> Ursinha, hey, are you guys having stakeholder meetings these days?
<Ursinha> Saviq: nope; we have two different squads now: tanuki, that works on snappy product integration, and kitsune, that works on jenkaas and legacy CI
<Ursinha> Saviq: what would you need?
<Saviq> Ursinha, I'd need kitsune, then, wanted to bump the heat on staging branch support in ci-train and legacy CI / jenkaas in the future
<Saviq> smaller projects like qtmir get bitten by conflicts between MPs quite a lot
<Ursinha> Saviq: ci-train isn't really kitsune, for legacy CI we're not taking feature requests, but focusing on handing over jenkaas instances to teams so they can fix the problems they understand way better than we do :) btw, mir is the next one in line
<Ursinha> I'll be sending weekly emails for the people waiting for jenkaas so it's clearer what's up next
<Saviq> Ursinha, must say I don't agree with the idea of jenkaas, not outside of quite specific environment requirements
<Ursinha> Saviq: why so?
<Saviq> we were supposed to converge on autopkgtests for all that it can be used for, I don't see why we'd need to maintain our own CI jobs for that
<Saviq> and everyone will be solving the same problems separately
<Ursinha> Saviq: we are providing example jobs for whoever is using jenkaas, what we finally acknowledged is that the former CI team was a bottleneck and it just couldn't scale for the number of teams using the infrastructure
<Saviq> Ursinha, well, sure, but the example jobs are one-off, then every team will solve their problems for themselves, when other teams could benefit from that
<Ursinha> we noticed all jobs *look* the same but they actually aren't :) most have specifics for testing and it creates a lot of overhead
<Saviq> Ursinha, that's likely because we never had a common denominator, which autopkgtests are supposed to be
<Ursinha> (not that I'm in a position to change jenkaas plans, this is my understanding of the reasoning for this -- the best person for that is beuno (that isn't here))
<Saviq> anyway, I understand this is basically a done deal, we'll just have to agree to disagree
<Saviq> IMO it will cause more troubles than solve
<Ursinha> Saviq: some tests require different slave configurations, and it's really hard to be reliable and diverse
<Saviq> Ursinha, key word is "some"
<Saviq> Ursinha, for those, jenkaas is probably a solution, for *most* projects we just need some CPU
<Ursinha> Saviq: I hope not (cause more troubles than solve), I think it's a bet to try and solve the previous problem we already knew existed, that is CI not being as close as acceptable to attend all stakeholders
<Saviq> Ursinha, dumping the work on the stakeholders, which is what jenkaas feels to be, isn't a solution IMO
<Ursinha> not saying is perfect
<Ursinha> Saviq: do you have any suggestions? honestly asking
<Saviq> Ursinha, I probably don't have enough background (didn't hear all the requirements you did), but doesn't autopkgtest fall under the same exact problem? and we've not dropped that, but consequently extend it to cater for more and more common needs?
<Ursinha> it's not really dumping work on stakeholders because we're not turning our backs to the existing situation; we're making sure we can move the existing setting to a more reliable setup, that can be IS maintained
<Ursinha> we're just not committing to new feature work
<abeato__> Laney, hey, I need some help to upload a source package to silo 28
<abeato__> Laney, concretely https://chinstrap.canonical.com/~abeato/gst-plugins-bad1.0/
<Saviq> Ursinha, that's hardware, but maintaining what runs on that hardware, above jenkins instances, you're ultimately leaving to respective teams
<Saviq> Ursinha, unless I misunderstand and you'll be maintaining the jobs running on jenkaas
<Saviq> I'm just worried this will lead to even more fragmentation and we'll never get testing on silos, images, every project will just test themselves without a holistic approach
<Saviq> I just was under the impression that our target was autopkgtests as a standard wherever possible
<Ursinha> Saviq: hardware is maintained by the certification team
<Ursinha> Saviq: the whole idea is to separate the concerns as close to the expertise as possible
<Saviq> Ursinha, and I disagree with that idea, because that makes me effectively unable to test another project without learning how they do it
<charles> Wellark, does ^ have the more-cleanups branch?
<Ursinha> this means we're handling the "testing silos" around the products, so you can ensure the tests will cover the desired product, not the isolated parts like happens now
<Saviq> not sure I understand
<Ursinha> the tests are currently conflated in a way we think they are cohesive but they are only sharing the same jenkins
<Saviq> Ursinha, in a jenkaas world, if I want to release 10 MPs for unity8 along with 5 MPs for mir and 1 for UITK, how do I test that silo coherently?
<Ursinha> Saviq: you're talking about ci-train, right? how do you do that today?
<Saviq> Ursinha, I can't, that's the problem
<Saviq> Ursinha, I need to run all the test suites manually, following the manual test plans
<Ursinha> so jenkaas won't cause a problem, it will only not solve it (ultimately, I'm not saying this is entirely true)
<Saviq> Ursinha, there's no auto-testing done on silos, and I can't see how it will happen with jenkaas, where every team has separate jobs that don't think about the world
<Saviq> Ursinha, oh it will totally cause problems, because it will fragment how we run tests even more
<Ursinha> Saviq: ci-train is apart from what we're doing with jenkaas, I think this is the misunderstanding
<Saviq> Ursinha, no, don't think about ci-train, just think about testing multiple projects that need to be released together
<Ursinha> that's what ci-train is about, no?
<Ursinha> integrating changes into the product?
<Saviq> it's just one solution that we currently use
<Saviq> Ursinha, what I'm asking is, after building (today in citrain, later in ciairline or some other solution)
<Ursinha> Saviq: I can appreciate the problems you understand exist and I don't, I don't want to give you the impression I'm disregarding what you're saying
<Saviq> Ursinha, what I want to convey is that I think the jenkaas approach will have a detrimental effect on our testing abilities
<Saviq> because with every team maintaining their own testing environment, there will be no way of putting multiple teams' projects to test in one go
<Ursinha> and I can understand that
<Ursinha> but there are other problems that exist that we have to fix, and jenkaas is a tentative solution for some of them, I don't think we ever thought we would be fixing all of the existing missing features with that
<Saviq> Ursinha, but you say that jenkaas is effectively the only road planned going forward (as legacy ci jobs will not be developed, just maintained)
<abeato__> robru, could you upload a rource package to silo 28 ?
<abeato__> *source
<Ursinha> Saviq: for the legacy CI yes
<Ursinha> Saviq: that's beuno plan
<Ursinha> Saviq: jenkaas is ultimately a self-service jenkins, that gives you the ability to use hardware from the lab if needed; thinking now I don't see a reason not to have a jenkaas instance to run such integration jobs
<abeato__> robru, https://chinstrap.canonical.com/~abeato/gst-plugins-bad1.0/
<Saviq> Ursinha, ok I'll raise this with other folk, thanks
<Ursinha> Saviq: more than that I think we need to involve beuno in the conversation
<Saviq> yeah, that's my plan
<charles> :P
<Wellark> charles: no idea
<rvr> kenvandine: There is something fishy
<kenvandine> :/
<rvr> kenvandine: Do you have silo 41 installed?
<kenvandine> yes
<rvr> kenvandine: Ok, reboot the phone. Then, go to bluetooth indicator and tap on "Bluetooth settings"
<rvr> kenvandine: Then, open the network indicator and tap on "Wifi settings"
<kenvandine> rvr, done... both worked fine
<rvr> kenvandine: The second time it is opened, the title is gone from system settings
<kenvandine> not for me
<rvr> kenvandine: Which image are you using?
<kenvandine> and that really couldn't be from silo 41
<kenvandine> rvr, mako r41
<rvr> kenvandine: the report switch works fine
<kenvandine> rvr, the only change to settings in this silo is fixing the property used for setting auto reporting of crashes
<kenvandine> it was using canReportCrashes instead of AutoReportCrashes
<kenvandine> nothing else changed in settings
<jibel> rvr, btw the error message  when you install lxc-android-config is harmless. It is not displayed in recovery because the script doesn't even reach this line, and with the session it fails. So the result is the same
<rvr> jibel: Ok, thanks
<kenvandine> rvr, but let me try the same steps on my arale
<rvr> kenvandine: I'm going to investigate this without the silo
<kenvandine> also fine on my arale
<kenvandine> title is showing
<kenvandine> arale r128
<kenvandine> rvr, thx
<kenvandine> so you get to the wifi page, just the title is blank?
<rvr> kenvandine: At some point, the indicators don't even open system settings
<rvr> kenvandine: sound indicator
<kenvandine> url-dispatcher problems?
<kenvandine> dunno
<kenvandine> sound indicator just launched it here
<rvr> kenvandine: I had crashes from the indicators
<kenvandine> good, so crash files?
<kenvandine> that would be super useful
<kenvandine> and what crashed? the indicator services?  url-dispathcer? settings?
<rvr> services
<rvr> _usr_lib_arm-linux-gnueabihf_indicator-sound_indicator-sound-service.32011.crash
<kenvandine> ok, i haven't seen those crash
<rvr> _usr_lib_arm-linux-gnueabihf_indicator-power_indicator-power-service.32011.crash
<kenvandine> interesting
<rvr> _usr_lib_arm-linux-gnueabihf_indicator-network_indicator-network-service.32011.crash
<kenvandine> file those bugs
<rvr> DuplicateSignature: /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-net
<rvr> work-service:url-dispatcher-bad-url
<kenvandine> ah, i think maybe your url-dispatcher db might be hosed
<kenvandine> rvr, so silo 41 is good?
<jibel> rvr, did you try to enable apport, remove the flag ( kenvandine will tell you which) replace rc-proposed by stable in channel.ini and reboot, then change the autoreporting setting and reboot again
<kenvandine> rvr, i think there's a bug about that db getting out of whack
<jibel> rvr, there is specific code if the channel is stable or rc-proposed
<kenvandine> you can edit /etc/system-image/channel.ini and replace rc-proposed with stable
<rvr> jibel: kenvandine: The test that I did was to enable/disable appport switch in system settings and SIGSEGV gallery app, and looked whether appport was triggered or not
<kenvandine> then remove /var/lib/apport/.apport-config-has-run
<kenvandine> that's a good test too
<kenvandine> but testing the default when on stable is good
<kenvandine> after removing the file, reboot
<kenvandine> when the device boots, you should see only one file in that dir
<kenvandine> /var/lib/apport/.apport-config-has-run
<kenvandine> not /var/lib/apport/autoreport
<rvr> Looking
<rvr> kenvandine: Only that file
<rvr> -rw-r--r--  1 root root    0 Oct  2 15:32 .apport-config-has-run
<kenvandine> great
<kenvandine> :)
<kenvandine> also
<kenvandine> cat /proc/sys/kernel/core_pattern
<kenvandine> should just contain "core"
<rvr> /bad_core_pattern
<kenvandine> rvr, it shouldn't container apport
<jibel> rvr, /bad_core_pattern is fine, it means apport didn't set it up
<kenvandine> yeah
<kenvandine> good to go!
<rvr> Ok
<kenvandine> sil2100, exception publishing 34 :(
<jibel> sil2100, did you revert uitk?
<sil2100> jibel: yeah, I hope so
<sil2100> kenvandine: uuuh?
<sil2100> robru: ^
<jibel> davmor2, how far are you from laindg 25?
<sil2100> kenvandine: I think it published good, just the final status steps failed
<jibel> landing*
<dobey> trainguards: isn't there some way to force ci train to merge branches in the order listed in the request?
<jhodapp> sil2100, to build the two packages in silo 55 and then to sync silo 29's contents into 55, what do I need to do?
<Laney> abeato__: can do in a bit
<Laney> abeato__: I'm getting build failures from the arm-dev PPA, is that related?
<Laney> also, can you put it somewhere that's not behind SSO please?
<Laney> annoying to download it from there
<Laney> and presumably not secret if you want it on a public PPA :)
<sil2100> jibel, davmor2: since it's close to EOD... let me maybe build the buteo stuff in rc-proposed, since I don't think I'll be around to switch the channels back once it's built
<kenvandine> sil2100, so you think silo 34 published fine?
<kenvandine> looks like it's all there in the overlay ppa
<sil2100> kenvandine: yeah, I think it only didn't get merged - I see all the packages in the overlay
<kenvandine> ok
<kenvandine> i'll merge
<sil2100> jhodapp: once you build all the packages in silo 29 then I a simple build should build everything
<sil2100> jhodapp: but I would do that when the -gles packages are inside as well
<jhodapp> sil2100, yeah I don't fully understand the -gles part
<rvr> kenvandine: jibel: I can't reproduce the crashes. But there is problem opening system-settings from indicators in image 129. Filling bug report.
<rvr> kenvandine: jibel: It's related, some how, to report settings page.
<sil2100> jhodapp: the -gles packages have usually the same contents as the main ones but different packaging - those are used for x86/amd64 systems
<jhodapp> sil2100, yeah, so last time I did a qtmultimedia landing I didn't have to do anything with -gles
<davmor2> jibel: 25 passed on arale now I`m testing on krillin it is looking god here too so not too long
<jhodapp> should be the same for this landing
<sil2100> jhodapp: usually Mirv handled the -gles bits for Qt packages I suppose
<kenvandine> rvr, oh i see something weird with the indicators on 129
<jhodapp> sil2100, that's probably what happened, yeah
<kenvandine> rvr, when i open any of the settings pages, it doesn't hide he indicator
<rvr> kenvandine: o_O
<kenvandine> but under the indicator, it is switching to the right settings page
<kenvandine> that isn't happening on my mako with image 41
<rvr> kenvandine: Doesn't hide indicator or doesn't show settings?
<kenvandine> that has to be an indicator bug, in unity8
<kenvandine> doesn't hide the indicator
<rvr> kenvandine: Oh, haven't seen that
<kenvandine> settings changes to the right page under the indicator
<kenvandine> but the indicator is over top
<kenvandine> if i swipe the indicator away, settings is showing the right page
<kenvandine> it's happening on all of them
<kenvandine> rvr, ok.. weird
<kenvandine> i rebooted
<kenvandine> now it's working properly again
<kenvandine> indicator hides when the page changes in settings
<kenvandine> so the shell must have been in some funky state or something
<kenvandine> rvr, but none of that weirdness is related to silo 41
<rvr> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1502223
<ubot5`> Ubuntu bug 1502223 in ubuntu-system-settings (Ubuntu) "Delay in opening system-settings from indicators" [Undecided,New]
<rvr> kenvandine: Yeah, I don't think so
<abeato__> Laney, well, I did not have any other place to upload :)
<rvr> kenvandine: But it's weird that, for me, to trigger this bad behavior, I have to go to report settings page
<abeato__> Laney, yes the failures are related: the problem is that it won't build in vivid, only in vivid+overlay ppa
<abeato__> Laney, which is really annoying
<kenvandine> rvr, it's possible the crash report settings page has some bugs, i don't think it's been used much
<kenvandine> considering before my fix in silo 41, it was reading the wrong property on dbus :)
<kenvandine> it changed the correct property, but read the wrong one :)
<jibel> sil2100, once silo 25 and 41 land can you trigger an image so we have a build with all the fixes for the week end?
<rvr> kenvandine: How can the report settings page interfere with the url-dispatcher or indicators?
<Laney> abeato__: lillypilly.canonical.com:public_html/
<abeato__> Laney, but nonetheless you can download it from ppa:canonical-arm-dev
<Laney> that's people.canonical.com
<kenvandine> rvr, it can't
<kenvandine> nothing in system-settings can really
<Laney> but I suppose I can scp it
<sil2100> jibel: sure, I should be around for a quick image build - I already kicked one for buteo
<rvr> kenvandine: But I can reproduce this problem
<sil2100> But I can kick one later
<abeato__> Laney, thanks, I'll try uploading to that other place too anyway
<kenvandine> rvr, that other bug you has to be url-dispatcher
<rvr> kenvandine: So something is going on :-/
<kenvandine> yeah, i think your url-dispatcher db is messed up somehow
<kenvandine> it's been happening more and more lately, it seems
<rvr> kenvandine: I have reflashed the phone
<rvr> kenvandine: There is no silo 41 here
<kenvandine> with wipe?
<rvr> kenvandine: Yes
<kenvandine> but since then you aren't getting the crash caused by url-dispatcher
<kenvandine> i think the other thing you reported is different
<davmor2> jibel: I found my first issue using the tablet as a desktop replacement I can`t move tickets on the trello board :(
<kenvandine> the crashes you were seeing was because it couldn't looking the handler in url-dispatcher
<kenvandine> this delay thing is different
<rvr> kenvandine: Yeah, I see no title disappearance problem
<abeato__> Laney, http://people.canonical.com/~abeato/gst-plugins-bad1.0/
<rvr> There aren't crashes now
<kenvandine> because the db got wiped :)
<Laney> thx
<jibel> davmor2, are you logged into trello?
<jhodapp> sil2100, ok package version number issue here, why does it have an issue with the standard qtmultimedia version format? https://ci-train.ubuntu.com/job/ubuntu-landing-055-1-build/39/console
<sil2100> jhodapp: argh, crap, yeah... damn, manual uploads aren't handled by syncs, we'll need someone to copy the package there for you
<sil2100> But in this case it needs to be re-versioned
<Laney> abeato__: can you remember where ubuntu7 is?
<Laney> doesn't appear to be in the overlay ppa
<jhodapp> sil2100, yeah ugg, in which case I should probably just move everything into silo 55 if I'm going to bump the version number of qtmultimedia
<abeato__> Laney, never arrived there, only in wily
<jhodapp> sil2100, let me just do that
<sil2100> jhodapp: I'm a bit EODish right now - I can help you with that but only in some minutes sadly
<jhodapp> and you can dput qtmultimedia into silo 55
<kenvandine> rvr, so can we pass silo 41?
<abeato__> Laney, latest in vivid and overlay is ubuntu2 I think
<jhodapp> sil2100, sure no worries, I'll ping you when I've bumped the version
<abeato__> Laney, this updates to ubuntu7 + a bug fix
<sil2100> jhodapp: thanks :) I can do the copies then and assist you with the landing itself
<jhodapp> sil2100, awesome thanks
<abeato__> Laney, the update is needed to get these changes in ubuntu-platform
<Laney> ok
<abeato__> Laney, ubuntu2 does not compile now in the ppa because of that change
<Laney> I just wanted to see the diff
<jhodapp> sil2100, ok version bumped, you can dput from here ppa:jhodapp/ubuntu/ppa into silo 55 when you get a chance
<davmor2> jibel: sorted I can move it via the ticket itself it does however add it to the bottom of the queue :)
<davmor2> jibel: so 25 passed, I have no issue with the proximety sensor here though
<davmor2> jibel: on dogfood or rc-proposed
<Mirv> (lurking) so which was the next webbrowser-app landing to land? 059 seems ota-8?
<Mirv> there's still 5 webbrowser landings...
<Mirv> dbarth_: is there a rough order for silos 059, 044, 005, 017 and 001 webbrowser landings?
<Laney> abeato__: landing-028 yes?
<abeato__> Laney, yes
<rvr> kenvandine: Approving silo 41
<kenvandine> rvr, thx
<rvr> kenvandine: No crashes after reinstalling the silo
<rvr> kenvandine: But there is something weird with the Report settings page, take a look to the bug report
<kenvandine> yeah, those crashes were caused by a corrupt db, i'm quite sure... no idea how they got messed up though so quickly
<kenvandine> rvr, will do
<kenvandine> or maybe jgdx can look at it, since i'll be gone next week :)
<rvr> kenvandine: Holidays?
<kenvandine> yup!
<rvr> kenvandine: Enjoy!!
<davmor2> sil2100: so building in rc-proposed then dude right?
<kenvandine> heading to universal studios for a week!
 * kenvandine is excited
<sil2100> davmor2: yeah, it's still building tho!
<rvr> kenvandine: Greetings to Harry Potter! ;)
<kenvandine> indeed
<kenvandine> jgdx, can you take a peek at bug 1502223 ?
<ubot5`> bug 1502223 in ubuntu-system-settings (Ubuntu) "Delay in opening system-settings from indicators" [Undecided,New] https://launchpad.net/bugs/1502223
<kenvandine> while i'm out
<jhodapp> sil2100, just let me know when you've done the dput into silo 55 so I can kick off the build
<sil2100> jhodapp: doing it now :) One moment
<sil2100> jhodapp: hm, ok, you bumped the version but built it for vivid?
<sil2100> jhodapp: you wanted this package in wily, right?
<jhodapp> sil2100, no, vivid
<sil2100> jhodapp: ah, ok
<davmor2> sil2100 no worries just checking I have a horrible feeling that I might be end of day, which I hope isn`t the case
<dobey> i guess not?
<sil2100> jhodapp: ok, copy done, it should pop up soon
<jhodapp> sil2100, nice thanks!
<jhodapp> hopefully everything is happy now
<sil2100> yw :)
<Laney> abeato__: done
<Laney> goodnight!
<abeato__> Laney, thanks!
 * Mirv -> movie
<dobey> hmm
<kenvandine> trainguards:  silo 41 is in the abyss, but it's dual landing and all the packages are in the overlay ppa for both wily and vivid
<kenvandine> is citrain waiting for them in wily-proposed?
<sil2100> kenvandine: I think that's a bug in the train still after yesterday's changes
<sil2100> robru: ^
<kenvandine> that's my thinking too
 * kenvandine merges
<robru> sil2100: kenvandine: yeah I'm not sure why that's happening, will take a look
<dobey> trainguards: isn't there some way to force ci train to merge branches in the order listed in the request?
<robru> dobey: no. if you are not happy with the order the branches are being merged, remove the prerequisites from your MPs
<dobey> the prerequisites are there for a reason. what i'm not happy with is having added a new branch, and rebuilding, and it gets merged before a much earlier branch, and causes a conflict.
<dobey> i guess i'm going to have to merge them all into one big branch and use that for the silo then
<robru> dobey: the merge-ordering logic just merges prerequisites before the ones that require them.
<robru> dobey: does the new branch not have any prerequisites? maybe define the earlier one as a prerequisite then
<dobey> it does have it defined
<robru> dobey: you must have two independent chains of prerequisites then
<dobey> the problem is when you end up with two branches of prerequisites, and they're not all in one single chain
<robru> dobey: if you switch the order of the "leaf" nodes the rest should fall into line
<dobey> it'll probably be easier for me to just make a new branch that contains all the others at this point
<robru> dobey: I'm considering just ripping this sorting logic out since this is the second complaint I've had in 2 days (after a year of nobody complaining, sigh)
<dobey> we have like 35 MPs now :-/
<dobey> robru: i'm not really complaining. i just thought there used to be some way to force it to use the order listed in the request
<dobey> and my case is hardly the norm (at least, it shouldn't be. if it is, we have much larger problems than the prerequisite ordering)
<robru> dobey: there did used to be a way to force that, but only because the sorting algo used to be so bad that it would randomly shuffle your merges if you didn't define any prereqs. when I cleaned up the algo to preserve the order of branches that don't define prereqs, I took away that option. that was a whole year ago
<dobey> oh
<dobey> i'm not sure it would fix my issues here, but i think it would have made them clearer if i could have done that
<robru> dobey: you may not be "complaining" but I'm getting the impression that the train is hurting more than it's helping. the algo is only there to "help" you get your merges in the right order.
<dobey> anywya, i guess i'll just make one big MP for this, as it will make it easier, especially since i'm sure we'll have a few more changes
<robru> ok, sorry that didn't work out
<dobey> well, if you have multiple MPs that should have prerequisites, but you didn't define them, then that's not the ci train's fault
<dobey> doing that only makes life harder for the people reviewing the branches
<dobey> or if you screw up and get into a criss-cross merge situation, again, ci train can't fix that
<dobey> and it shouldn't try to. it requires manual intervention
<robru> kenvandine: hmmm I'm not sure why the train is failing to track migration of wily packages to overlay, the code says that it's looking at the "dest" archive (which would be the overlay PPA in this case...)
<kenvandine> robru: dunno, i just went ahead and merged it
<kenvandine> but it was in the abyss for quite a long time
<robru> kenvandine: yes copying to overlay should be basically instant, so manual merging is fine. I'm just troubleshooting why it's doing this, there's nothing in the code that obviously indicates why it would fail to notice the copy to overlay ppa
<boiko> robru: would it be possible to have the audit lot information in an expandable box or in a separate page? for silos that require lots of iterations until landing it starts to get noisy
<boiko> robru: s/lot/log/
<robru> boiko: yes I'm working on that
<boiko> robru: cool! :)
<dobey> robru: ugh, weird changelog again: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+sourcepub/5474358/+listing-archive-extra
<robru> dobey: yep, train only knows how to make changelogs when you have small branches. it can't handle megabranches, you have to make your own changelog
<dobey> why can't it use the commit message for the branch like it does when i have 35 branches?
<robru> dobey: because it doesn't use the commit message from the branch, it uses the commit message for the MPs.
<robru> which it no longer has because you took those away
<robru> dobey: that changelog is definitely a bug, if you file it I'll look into it later, I'm swamped with other stuff right now. for now the workaround is to write your own changelog into your megabranch
<dobey> that's what i meant, from the MP
<dobey> i didn't take them away
<dobey> there is one MP, and it has a commit message
<dobey> ok
<dobey> i  think i did file a bug already about this
<robru> kenvandine: finally figured it out, there's a bug in the publish job that makes it record the vivid version over the wily version, so it's correctly looking at the overlay PPA but it's expecting to find the vivid version in wily, and fails, that's why it's in the abyss forever
<dobey> trainguards: ping, hi, can i get some retries clicked for a few builds?
<dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082507
<robru> dobey: sure, which ppa / which builds?
<dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082509
<dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082510
<robru> dobey: done, feel free to WATCH_ONLY build
<dobey> those three. the arm64/ppc builds will fail anyway
<dobey> robru: thanks
<robru> dobey: your'e welcome
<dobey> robru: can you retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082509 again? seems it's dep wasn't actually published yet when it ran, for some reason, so it managed to get an older version.
<dobey> thanks
<robru> dobey: done
<robru> brb
#ubuntu-ci-eng 2015-10-03
<bzoltan_> jibel: I have a super high priority landing in the silo31. That is fixing a critical OTA7 bug we have just captured https://bugs.launchpad.net/canonical-devices-system-image/+bug/1502093 This bug forced us to revert the previous UITK landing. So this landing has other 3 OTA7 bugfixes. I would like to ask you to push this silo to QA validation as first on Monday.
<ubot5`> Ubuntu bug 1502093 in ubuntu-ui-toolkit (Ubuntu) "UbuntuShape crash with latest UITK on mako/flo" [Critical,Confirmed]
#ubuntu-ci-eng 2016-10-03
-queuebot:#ubuntu-ci-eng- tvoss morphis, https://bileto.ubuntu.com/#/ticket/1623 Abandoning ticket
<oSoMoN> ubuntu-qa: autopkgtests have been marked as "running" for 4 days now on https://bileto.ubuntu.com/#/ticket/2010, but those that arenât finished yet are obviously not running, I suppose thereâs been a glitch with the infrastructure?
<oSoMoN> can the ticket be marked ready for QA?
<jibel> oSoMoN, done
<ToyKeeper> Any idea what the story is there?  Looks like unity8 and webbrowser app got stuck on i386?
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 QA Signoff: Ready
<ToyKeeper> (yakkety only)
<oSoMoN> jibel, thanks!
<jibel> ToyKeeper, no idea, maybe a problem with the workers. pitti would know
<jibel> they are not even marked as running or queued in the status page
<ToyKeeper> Nope, probably just a message dropped somewhere.
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Needs rebuild due to new commits (yakkety/online-accounts-api). Successfully built (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts, yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2019 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Failed to build (yakkety/online-accounts-api). Pending binary packages (vivid/online-accounts-api, xenial/online-accounts-api). Successfully built (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts, yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2036 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
<rvr> mardy: ping
<mardy> rvr: hi!
<rvr> mardy: https://trello.com/c/8n6FyKj4/3662-1962-ubuntu-1962-ubuntu-system-settings-online-accounts-mardy-dbarth
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Pending binary packages
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Preparing packages
<mardy> rvr: added a comment
<rvr> mardy: What do you mean by empty window?
<mardy> rvr: IIRC, a window with just the title
<mardy> rvr: well, it's something you'd notice for sure :-)
<rvr> mardy: What should I see?
<mardy> rvr: nothing: this is how I reproduced the bug: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1594944/comments/6
<ubot5> Ubuntu bug 1594944 in ubuntu-system-settings-online-accounts (Ubuntu) "Setup.exec() for existing account type results in blank full screen window" [Critical,In progress]
<rvr> mardy: "go to login.ubuntu.com and delete the authorization" I went there, but wasn't sure where I could delete the auth
<mardy> rvr: https://login.ubuntu.com/+applications, remove the "ubuntu-phablet" one
<rvr> mardy: Thanks, let me see
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2019 Publishing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 yakkety/unity-settings-daemon: Failed to commit https://code.launchpad.net/~mitya57/unity-settings-daemon/start-only-on-unity. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2019 Release pocket (vivid/ubuntu-ui-toolkit, vivid/ubuntu-ui-toolkit-gles, xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles). UNAPPROVED queue (yakkety/ubuntu-ui-toolkit, yakkety/ubuntu-ui-toolkit-gles)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Successfully built
<rvr> mardy: Ok
<rvr> mardy: So it shows the login window :)
<rvr> mardy: And after that the purchase screen
<mardy> rvr: ok, that's fine
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Dependency wait (yakkety/indicator-bluetooth). Pending binary packages (yakkety/unity-control-center, yakkety/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Dependency wait (yakkety/indicator-bluetooth). Destination version missing from changelog (yakkety/unity-control-center). Successfully built (yakkety/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 yakkety/unity8: Failed to merge https://code.launchpad.net/~lukas-kde/unity8/hideCursorFullscreen
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1962 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Preparing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2019 Merging branches
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1962 Publishing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts). Successfully built (vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety/signon-apparmor-extension). UNAPPROVED queue (yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2036 Ready to build
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Needs rebuild due to new commits (yakkety/ubuntu-ui-toolkit). Successfully built (vivid/ubuntu-ui-toolkit, vivid/ubuntu-ui-toolkit-gles, xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles, yakkety/ubuntu-ui-toolkit-gles)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1960 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Dependency wait (yakkety/indicator-bluetooth). Successfully built (yakkety/unity-settings-daemon). Uploading build (yakkety/unity-control-center)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Ready to build (vivid/golang-any-shared-dev, xenial/golang-any-shared-dev, xenial/golang-github-mattn-go-sqlite3, xenial/golang-github-pborman-uuid, yakkety/golang-any-shared-dev, yakkety/golang-github-mattn-go-sqlite3, yakkety/golang-github-pborman-uuid). Successfully built (vivid/golang-github-mattn-go-sqlite3, vivid/golang-github-pborman-uuid, vivid/ubuntu-push, xenial/ubuntu-push, yakkety/ubunt
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1962 Release pocket (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts). UNAPPROVED queue (yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2034 Publishing packages
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2034 Proposed pocket
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Dependency wait (yakkety/indicator-bluetooth). Successfully built (yakkety/unity-control-center, yakkety/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2015 Release pocket
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1949 Currently building (yakkety/qtdeclarative-opensource-src). Diff missing (yakkety/qtbase-opensource-src). Failed to build (yakkety/qtquickcontrols2-opensource-src). Ready to build (xenial/qtbase-opensource-src, xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src, xenial/qtdeclarative-opensource-src-gles, xenial/qtquickcontrols2-opensource-src, yakkety/qtbase-opensource-src-gles, y
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2034 Release pocket
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/1995 Preparing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2038 Preparing packages
<rvr> Wellark, charles: Silo 1988 approved
-queuebot:#ubuntu-ci-eng- Wellark charles, https://bileto.ubuntu.com/#/ticket/1988 QA Signoff: Approved
<Wellark> rvr: <3 <3 <3
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1949 Diff missing (yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src). Failed to build (yakkety/qtquickcontrols2-opensource-src). Ready to build (xenial/qtbase-opensource-src, xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src, xenial/qtdeclarative-opensource-src-gles, xenial/qtquickcontrols2-opensource-src, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/1995 Failed to build (yakkety/unity-scope-click). Successfully built (xenial/unity-scope-click)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2038 Diff missing
<dobey> trainguards: hi, can someone please hit retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/1995.1/+build/10983734 ? thanks
<cjwatson> dobey: done
<dobey> thanks
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/1995 Successfully built
<oSoMoN> Mirv, the amd64 build in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2036/+packages failed, can you re-trigger it?
<oSoMoN> alternatively, I can try to build it locally with tests disabled
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Dependency wait (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
<slangasek> Wellark, charles: does https://bileto.ubuntu.com/#/ticket/1988 just need someone (e.g., me) to sign off on the packaging changes and publish?
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2032 Dependency wait (yakkety/unity8). Failed to build (xenial/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/qtmir, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles)
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Dependency wait (yakkety/unity8). Pending binary packages (yakkety/lightdm). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session, xenial/unity8, xenial/unity8-desktop-session, yakkety/gsettings-ubuntu-touch-schemas, yakkety
<slangasek> Wellark, charles: well, I don't see any blockers for publishing this, and it's on the critical path for u8 in yakkety ISOs, so I'm pushing the button :)
-queuebot:#ubuntu-ci-eng- Wellark charles, https://bileto.ubuntu.com/#/ticket/1988 Publishing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2024 Dependency wait (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Dependency wait (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles, yakkety/unity-notifications)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (yakkety/unity8). Needs rebuild due to new commits (yakkety/qtubuntu). Successfully built (vivid/qmenumodel, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity8, xenial/qmenumodel, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, yakkety/qmenumodel, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Dependency wait (yakkety/indicator-bluetooth, yakkety/indicator-keyboard, yakkety/indicator-power, yakkety/indicator-sound). Destination version missing from changelog (yakkety/indicator-network, yakkety/indicator-session). Needs rebuild due to new commits (yakkety/indicator-display). Pending binary packages (yakkety/libindicator). Successfully built (yakkety/hud, yakkety
<Wellark> slangasek: thanks!
-queuebot:#ubuntu-ci-eng- Wellark charles, https://bileto.ubuntu.com/#/ticket/1988 Proposed pocket (yakkety/indicator-network). Release pocket (vivid/indicator-network, xenial/indicator-network)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 QA Signoff: Ready
<oSoMoN> trainguards: can https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2036/+build/10983437 be retried, please?
<robru> oSoMoN: done
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2032 Destination version missing from changelog (yakkety/unity8). Failed to build (xenial/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/qtmir, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles)
<oSoMoN> robru, thanks!
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Destination version missing from changelog (yakkety/unity8). Pending binary packages (yakkety/lightdm). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session, xenial/unity8, xenial/unity8-desktop-session, yakkety/gsettings-ub
<robru> oSoMoN: you're welcome
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2024 Destination version missing from changelog (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Destination version missing from changelog (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles, yakkety/unity-no
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Destination version missing from changelog (yakkety/unity8). Needs rebuild due to new commits (yakkety/qtubuntu). Successfully built (vivid/qmenumodel, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity8, xenial/qmenumodel, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, yakkety/qmenumodel, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Destination version missing from changelog (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 yakkety/libertine: Failed to merge https://code.launchpad.net/~townsend/libertine/support-non-container-apps
<dobey> oh britney, where have you gone
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Needs rebuild due to new commits (yakkety/libertine). Pending binary packages (vivid/ubuntu-app-launch). Successfully built (vivid/libertine, xenial/libertine, xenial/ubuntu-app-launch, yakkety/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Preparing packages
<rvr> jgdx: Take a look to https://trello.com/c/63HzjuqE/3669-2021-ubuntu-2021-ubuntu-push-jgdx
<rvr> jgdx: Are you aware of any problem with hello app?
<robru> dobey: britney runs are currently 1.5 hours
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts, yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety/signon-apparmor-extension)
<dobey> hmm, i wonder what the landing plan is, come thursday.
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Destination version missing from changelog (yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts, yakkety/online-accounts-api)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Pending binary packages (vivid/libertine, xenial/libertine, yakkety/libertine). Successfully built (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch, yakkety/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1962 Proposed pocket (yakkety/ubuntu-system-settings-online-accounts). Release pocket (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts)
<sil2100> robru: ping, meeting!
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/1943 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1964 Merging branches
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles, yakkety/unity-notification
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1964 Ready to build
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1964 Ready to build (xenial/qtbase-opensource-src-gles). UNAPPROVED queue (xenial/qtbase-opensource-src)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Pending binary packages (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles, yakkety/unity-notifications). Uploading build (vivid/unity8, xen
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Preparing packages
<jgdx> rvr, hey you still around?
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Pending binary packages (vivid/unity8, xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles, yakkety/unity-notifications)
<jgdx> ubuntu-qa, hey, 2021 is blocked due to a non-regression. See the card for details.
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 Pending binary packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Pending binary packages (vivid/libertine, xenial/libertine, yakkety/libertine). Successfully built (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch, yakkety/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Destination version missing from changelog (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles, yakkety/unity-no
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Destination version missing from changelog (yakkety/unity8). Pending binary packages (vivid/unity8, xenial/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 Successfully built
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Pending binary packages (yakkety/unity8). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, xenial/unity8, yakkety/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Destination version missing from changelog (yakkety/unity8). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, xenial/unity8, yakkety/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1962 Release pocket
<robru> sbalda: hey, how's it going with ust?
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- Wellark charles, https://bileto.ubuntu.com/#/ticket/1988 Release pocket
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Needs rebuild due to new commits (yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts, yakkety/online-accounts-api)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts). Needs rebuild due to new commits (yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety/signon-apparmor-extension)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Dependency wait (yakkety/indicator-bluetooth, yakkety/indicator-keyboard, yakkety/indicator-power, yakkety/indicator-sound). Destination version missing from changelog (yakkety/indicator-session). Needs rebuild due to new commits (yakkety/indicator-display, yakkety/indicator-network). Pending binary packages (yakkety/libindicator). Successfully built (yakkety/hud, yakkety
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Pending binary packages (xenial/unity8, yakkety/unity8). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Destination version missing from changelog (yakkety/unity8). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, xenial/unity8, yakkety/ubuntu-settings-components)
<justinmcp_> robru: is 1823 ok to build as is?
<robru> justinmcp_: yeah sorry i didn't follow up with those oxide uploads, i figured you'd get a European to do that
<robru> justinmcp_: let me try uploading those oxides again
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2027 UNAPPROVED queue
<justinmcp_> robru: looks like its just the yakkety that didnt work?
<robru> justinmcp_: yakkety is the only one that did work. it's just missing the diff. "Diff missing" implies it has built successfully
<justinmcp_> robru: ah
<robru> justinmcp_: "ready to build" means that there is no package there at all
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Preparing packages
<robru> justinmcp_: ok, vivid uploaded, working on xenial now
<justinmcp_> robru: you can do it :)
<robru> justinmcp_: the little laptop that could ;-)
#ubuntu-ci-eng 2016-10-04
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Pending binary packages (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch, yakkety/ubuntu-app-launch). Successfully built (vivid/libertine, xenial/libertine, yakkety/libertine)
-queuebot:#ubuntu-ci-eng- justinmcp, https://bileto.ubuntu.com/#/ticket/1823 Generating diffs
<robru> justinmcp_: ok, upload looks good, just generating diffs now, let me know if you need anything else
<justinmcp_> robru: thanks muchly
<robru> justinmcp_: you're welcome
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Pending binary packages (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch). Successfully built (vivid/libertine, xenial/libertine, yakkety/libertine, yakkety/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Successfully built
<robru> justinmcp_: ugh i screwed up the vivid build! Look at that giant diff
<justinmcp_> robru: build is fine?
<robru> justinmcp_: it built but it has the wrong contents. If you release the ppa as is your introducing a lot of changes to vivid that aren't part of your media hub release
<justinmcp_> robru: ah.. does Oxide have to be moved into a release from here?
<robru> justinmcp_: well i suppose it doesn't HAVE to but it will automatically if you click publish
<justinmcp_> robru: it shouldn't really, chris manages securiry updates and I believe there is/was one soon
<robru> justinmcp_: ok well just be sure to get oxide deleted from your ppa once you're done validating whatever you needed it for
<robru> It'll be Very Not Good if that vivid build is released to overlay ppa
<robru> I should just fix it...
<justinmcp_> robru: hmm. thats not up to me though is it? If I click 'ok' the process from then on is handled by qa
<robru> justinmcp_: once qa approves it's your job to publish
<justinmcp_> robru: true, and its ok to remove oxide at this time?
<robru> justinmcp_: ah that probably doesn't make a lot of sense.
<robru> justinmcp_: it's not clear to me what you're doing with oxide. you needed oxide to be recompiled against your media-hub? and then you want to not release that package along with your media-hub? that would mean that the oxide in the overlay won't have been compiled with your media-hub
<justinmcp_> robru: yes, it would mean that, but it would be compiled with the MH that has the binary break
<justinmcp_> my changes are binary compatible
<robru> justinmcp_: so if your changes are binary compatible then why was it necessary to rebuild oxide for your silo? shouldn't the existing oxide in the overlay have successfully tested against your new mh?
<justinmcp_> robru: its hard for me to avoid grumbling here; between when I submited the ticket and when it was almost approved
<justinmcp_> the BIC change went in
<robru> justinmcp_: is that what Mirv's comment is referencing?
<justinmcp_> so that breaking change should of had Oxide added to it
<justinmcp_> but it didnt, so now; my changes are blocked
<justinmcp_> I would have to search for the comment
<robru> justinmcp_: I mean on the ticket: https://bileto.ubuntu.com/#/ticket/1823 mirv mentions doing a rebuild
<justinmcp_> robru: yes
<robru> justinmcp_: so what do you need to get unblocked?
<justinmcp_> robru: well QA (rightly) reject the change because it doesnt fix the attached bug
<justinmcp_> but it does - its just a new bug caused by the BIC
<justinmcp_> so I need a oxide in there, built against it, so it can pass
<robru> justinmcp_: ok, so if you need a new oxide build that fixes a problem, then QA verifies that the problem is fixed, you can't delete oxide after that ;-)
<robru> justinmcp_: so I'm going to re-upload a corrected vivid oxide and then I guess you're on your way to verifying that it fixes the issue
<justinmcp_> robru: it all sounds so wrong :)
<robru> justinmcp_: what point don't you get? I don't really understand how/why oxide depends on media-hub, but if indeed there's an issue and you need a new oxide build to fix it, and qa is going to verify the new oxide build, you can't just get their approval and then discard the oxide build and go back to the old broken build
<justinmcp_> robru: it was more frustration expressed through amusement, afaict I understand the process
<robru> justinmcp_: alright, sorry it took me so long to get that sorted. I'm just redownloading the correct oxide package to start from, will have that uploaded in an hour or so...
-queuebot:#ubuntu-ci-eng- justinmcp, https://bileto.ubuntu.com/#/ticket/1823 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2027 Needs rebuild due to burned version number
<Mirv> oxide uploads are fun... good network connections are useful
<Mirv> well, just unpacking and repacking oxide gives you a good benchmark if your SSD shines or not
<robru> Oh god it's still building
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts). Needs rebuild due to new commits (yakkety/signon-apparmor-extension, yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/signon-apparmor-extension, xenial/signon-apparmor-extension)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Preparing packages
<oSoMoN> vigo, how is testing of silo 2010 going? let me know if you have questions or if you encounter issues
<vigo> oSoMoN, so far so good!
<vigo> don't worry I'll let you know :)
<oSoMoN> cool
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2040 Preparing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2040 yakkety/lxc-android-config: Failed to commit https://code.launchpad.net/~vicamo/lxc-android-config/fix-systemd-service-startup. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- michi jamesh marcustomlinson gary-wzl charles xavigarcia, https://bileto.ubuntu.com/#/ticket/1791 Abandoning ticket
<oSoMoN> Mirv, it looks like the amd64 build of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2036/+packages fails reliably, Iâm currently building it locally to test
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2040 Preparing packages
<Mirv> oSoMoN: oh, right, now the others running tests finished too so the patch is actually causing a problem. right. the tests can be disabled too for testing.
<oSoMoN> yes, I disabled the tests to build locally
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 Pending binary packages
-queuebot:#ubuntu-ci-eng- justinmcp, https://bileto.ubuntu.com/#/ticket/1823 Failed to build (vivid/oxide-qt). Successfully built (vivid/media-hub, xenial/media-hub, xenial/oxide-qt, yakkety/media-hub, yakkety/oxide-qt)
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 Successfully built
-queuebot:#ubuntu-ci-eng- pstolowski marcustomlinson, https://bileto.ubuntu.com/#/ticket/1785 Abandoning ticket
-queuebot:#ubuntu-ci-eng- pstolowski marcustomlinson, https://bileto.ubuntu.com/#/ticket/1785 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2041 Abandoning ticket
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Preparing packages
-queuebot:#ubuntu-ci-eng- pstolowski marcustomlinson, https://bileto.ubuntu.com/#/ticket/1785 Successfully built
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Pending binary packages (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts, yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/online-accounts-api, xenial/online-accounts-api, yakkety/online-accounts-api)
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Successfully built
<rvr> jgdx: Silo 2021 approved
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Publishing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Publish failed: Ready to build
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Ready to build (xenial/golang-github-mattn-go-sqlite3, xenial/golang-github-pborman-uuid, yakkety/golang-github-mattn-go-sqlite3, yakkety/golang-github-pborman-uuid). Release pocket (vivid/golang-github-mattn-go-sqlite3, vivid/golang-github-pborman-uuid, vivid/ubuntu-push, xenial/ubuntu-push). UNAPPROVED queue (yakkety/ubuntu-push)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 QA Signoff: Approved
<oSoMoN> trainguards: can someone please publish silo 2010 on my behalf?
<sil2100> oSoMoN: on it
<Mirv> oSoMoN: ok 2036 is now ready (tests disabled)
<sil2100> oSoMoN: publishing
<oSoMoN> thanks!
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 Publishing packages
<oSoMoN> Mirv, E: The repository 'http://ppa.launchpad.net/ci-train-ppa-service/2036/ubuntu xenial Release' does not have a Release file.
<oSoMoN> N: Updating from such a repository can't be done securely, and is therefore disabled by default.
<oSoMoN> ever seen that?
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 Proposed pocket (yakkety/webbrowser-app). Release pocket (vivid/qtubuntu, vivid/qtubuntu-gles, vivid/webbrowser-app, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/webbrowser-app). UNAPPROVED queue (yakkety/qtubuntu, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Destination version missing from changelog (yakkety/webbrowser-app). Failed to build (vivid/webbrowser-app). Successfully built (xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- alex-abreu, https://bileto.ubuntu.com/#/ticket/1879 Failed to build (yakkety/webbrowser-app). Successfully built (vivid/webbrowser-app, xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Proposed pocket (yakkety/ubuntu-push). Ready to build (xenial/golang-github-mattn-go-sqlite3, xenial/golang-github-pborman-uuid, yakkety/golang-github-mattn-go-sqlite3, yakkety/golang-github-pborman-uuid). Release pocket (vivid/golang-github-mattn-go-sqlite3, vivid/golang-github-pborman-uuid, vivid/ubuntu-push, xenial/ubuntu-push)
<jgdx> rvr, wee. Do you know if there's a bug for the hello app issue? If not, I'll file
<Mirv> oSoMoN: uh oh, why is my build for yakkety... sorry
<rvr> jgdx: I guess there is an confinement problem
<oSoMoN> Mirv, ah, right, I should have spotted thatâ¦
<rvr> jgdx: And I didn't fill a bug for that
<Mirv> oSoMoN: I've been in the same situation, trying to understand the cryptic messages..
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Destination version missing from changelog (yakkety/qtubuntu, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubuntu-gles, yakkety/unity-no
<jgdx> ralsina, hey, where's the source+bug tracker for the hello app? It seems to have been broken by some update
<Mirv> oSoMoN: xenial uploaded now too
<oSoMoN> thanks!
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 Proposed pocket (yakkety/qtubuntu, yakkety/qtubuntu-gles, yakkety/webbrowser-app). Release pocket (vivid/qtubuntu, vivid/qtubuntu-gles, vivid/webbrowser-app, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 Proposed pocket (yakkety/qtubuntu-gles, yakkety/webbrowser-app). Release pocket (vivid/qtubuntu, vivid/qtubuntu-gles, vivid/webbrowser-app, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/webbrowser-app, yakkety/qtubuntu)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Ready to build (xenial/golang-github-mattn-go-sqlite3, xenial/golang-github-pborman-uuid, yakkety/golang-github-mattn-go-sqlite3, yakkety/golang-github-pborman-uuid). Release pocket (vivid/golang-github-mattn-go-sqlite3, vivid/golang-github-pborman-uuid, vivid/ubuntu-push, xenial/ubuntu-push, yakkety/ubuntu-push)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Preparing packages
<ralsina> jgdx: not really. What's broken? it's probably that the server is down (it runs in a VPS I own)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 Proposed pocket (yakkety/webbrowser-app). Release pocket (vivid/qtubuntu, vivid/qtubuntu-gles, vivid/webbrowser-app, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/webbrowser-app, yakkety/qtubuntu, yakkety/qtubuntu-gles)
<jgdx> ralsina, can't log in. Log: http://pastebin.ubuntu.com/23271716/
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Publishing packages
<ralsina> jgdx: yes, that's it then
<ralsina> jgdx: I'll kick it in a few minutes
<ralsina> jgdx: digitalocean is down, tho
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Publish failed: Dependency wait
<ralsina> jgdx: can you try again?
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Pending binary packages
<jgdx> ralsina, same apparmor complaint, but I am able to log in. Thx
<jgdx> ralsina, do you recommend that hello app is removed from the test plan of u-push?
<jgdx> since it's a private server
<Laney> do I need to resolve depwaits before bileto will let me publish?
<ralsina> jgdx: or we should move it to a real canonical server somewhere
<jgdx> ralsina, or that :)
<ralsina> jgdx: the server is the example server in the push sources, nothing magical there :-)
<ralsina> jgdx: if we put it in a real server there should be a new release of hello, which should not be hard for someone who still has the dev env setup
<jgdx> ralsina, that would prob be a good exercise, but I don't have the dev env set up
<ralsina> jgdx: that's two of us
<jgdx> ralsina, is the app closed source?
<ralsina> jgdx: in the meantime, I'll make the server more robust (currently is running as "screen nodejs server.js")
<ralsina> jgdx: no, the app is the example client app in the docs
<jgdx> ah, okay
<jgdx> ralsina, i guess the least stable there is nodejs :)
<jgdx> i have several screen sessions that are year old
<jgdx> *years
<ralsina> jgdx: well, every 3 months or so I reboot the server and forget to restart this one :-)
<jgdx> ralsina, oh :) I'll talk to Bill about maybe inheriting this to unload you and your server
<ralsina> jgdx: awesome, thanks!
<ralsina> jgdx: in the meantime, if anything breaks just ping me, I can fix it quick
<jgdx> ralsina, will do, thank you!
<jgdx> rvr, ^ I will add that to the test plan for now
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Dependency wait (yakkety/indicator-bluetooth). Successfully built (yakkety/unity-control-center, yakkety/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Diff missing
<rvr> jgdx: Ack
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Pending binary packages (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2032 Failed to build (xenial/qtmir-gles). Pending binary packages (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/qtmir, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Dependency wait (yakkety/indicator-keyboard, yakkety/indicator-power, yakkety/indicator-sound). Destination version missing from changelog (yakkety/indicator-session). Needs rebuild due to new commits (yakkety/indicator-display, yakkety/indicator-network). Pending binary packages (yakkety/libindicator). Successfully built (yakkety/hud, yakkety/indicator-application, yakke
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 QA Signoff: N/A
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 Ready to build (vivid/lxc-android-config). Successfully built (xenial/lxc-android-config, yakkety/lxc-android-config)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Destination version missing from changelog (yakkety/qtubuntu, yakkety/unity8). Needs rebuild due to new commits (yakkety/qmenumodel). Successfully built (vivid/qmenumodel, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity8, xenial/qmenumodel, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Destination version missing from changelog (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Failed to build (xenial/online-accounts-api, yakkety/online-accounts-api). Pending binary packages (vivid/online-accounts-api). Successfully built (vivid/signon-apparmor-extension, vivid/ubuntu-system-settings-online-accounts, xenial/signon-apparmor-extension, xenial/ubuntu-system-settings-online-accounts, yakkety/signon-apparmor-extension, yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2032 Destination version missing from changelog (yakkety/unity8). Failed to build (xenial/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/qtmir, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- Mirv jhodapp ahayzen, https://bileto.ubuntu.com/#/ticket/1972 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Destination version missing from changelog (yakkety/qtubuntu). Pending binary packages (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubu
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Preparing packages
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Destination version missing from changelog (yakkety/qtubuntu). Needs rebuild due to new commits (yakkety/qmenumodel, yakkety/unity8). Successfully built (vivid/qmenumodel, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity8, xenial/qmenumodel, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1949 Diff missing (yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src, yakkety/qtquickcontrols2-opensource-src). Failed to build (xenial/qtquickcontrols2-opensource-src). Ready to build (xenial/qtbase-opensource-src, xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Failed to build (xenial/online-accounts-api, yakkety/online-accounts-api). Successfully built (vivid/online-accounts-api, vivid/signon-apparmor-extension, vivid/ubuntu-system-settings-online-accounts, xenial/signon-apparmor-extension, xenial/ubuntu-system-settings-online-accounts, yakkety/signon-apparmor-extension, yakkety/ubuntu-system-settings-online-accounts)
<dobey> mterry: hi, can you maybe do packaging ack/publish of https://bileto.ubuntu.com/#/ticket/1995 please? it re-enables the autopkgtests in unity-scope-click
<rvr> mardy: ping
<mterry> dobey: nice.  publishing
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/1995 Publishing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
<dobey> mterry: thanks!
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2010 Release pocket
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Failed to build (xenial/ubuntu-download-manager, yakkety/ubuntu-download-manager). Successfully built (vivid/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/1995 Proposed pocket (yakkety/unity-scope-click). Release pocket (xenial/unity-scope-click)
-queuebot:#ubuntu-ci-eng- alex-abreu, https://bileto.ubuntu.com/#/ticket/1879 Needs rebuild due to new commits (yakkety/webbrowser-app). Successfully built (vivid/webbrowser-app, xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Dependency wait (vivid/unity8, xenial/unity8, yakkety/unity8). Needs rebuild due to new commits (yakkety/qtubuntu). Pending binary packages (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xe
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Needs rebuild due to new commits (yakkety/qmenumodel, yakkety/qtubuntu, yakkety/unity8). Successfully built (vivid/qmenumodel, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity8, xenial/qmenumodel, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Failed to build (vivid/webbrowser-app). Needs rebuild due to new commits (yakkety/webbrowser-app). Successfully built (xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Failed to build (xenial/ubuntu-download-manager, yakkety/ubuntu-download-manager). Pending binary packages (vivid/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2036 Diff missing (xenial/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2021 Merging branches
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 Publishing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Failed to build (xenial/ubuntu-download-manager, yakkety/ubuntu-download-manager). Successfully built (vivid/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2043 Diff missing (xenial/openssl-ibmca). Pending binary packages (yakkety/openssl-ibmca)
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 Proposed pocket (yakkety/lxc-android-config). Release pocket (xenial/lxc-android-config)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2043 Diff missing
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2024 Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/qtubuntu, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, 
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2032 Failed to build (xenial/qtmir-gles). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/qtmir, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles)
<rvr> mardy: I fail to verify that the fix for "&" characters in owncloud accounts work https://trello.com/c/aUCHPcWW/3664-1992-ubuntu-1992-account-plugins-mardy-dbarth
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Publishing packages
<rvr> jgdx: How is this tested? https://trello.com/c/nv0rVKVx/3670-1943-ubuntu-1943-ubuntu-system-settings-jgdx
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Needs rebuild due to new commits (yakkety/unity8). Pending binary packages (yakkety/lightdm). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session, xenial/unity8, xenial/unity8-desktop-session, yakkety/gsettings-ubuntu-touch
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 yakkety/qtubuntu: Failed to merge https://code.launchpad.net/~gerboland/qtubuntu/rasterGLSurface
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2043 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2043 Diff missing
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 yakkety/qtubuntu: Failed to merge https://code.launchpad.net/~gerboland/qtubuntu/rasterGLSurface
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2044 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2043 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/qtubuntu, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, 
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/qtubuntu). Pending binary packages (vivid/unity8, xenial/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakke
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/qtubuntu, yakkety/ubuntu-settings-components). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/uni
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Needs rebuild due to new commits (yakkety/ubuntu-settings-components). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, xenial/unity8, yakkety/unity8)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 PPA/bzr version mismatch (yakkety/qtubuntu, yakkety/ubuntu-settings-components). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yak
<ChrisTownsend> rvr: Hi!  I see you are testing the libertine silo now.  Do you think you'll get that finished today?
<ChrisTownsend> rvr: Just planning since there is another libertine landing in the pipeline and need to coordinate:)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/ubuntu-settings-components). Pending binary packages (yakkety/qtubuntu). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety/unity-notifications, yakkety/unity8). Uploading build (vivid/qtubuntu, 
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Pending binary packages (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components). Successfully built (vivid/unity8, xenial/unity8, yakkety/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/ubuntu-settings-components). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yakkety/qtmir
<rvr> ChrisTownsend: Maybe I will land it tonight, but not sure
<ChrisTownsend> rvr: Ok, thanks.
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Successfully built
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Ready to build
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Failed to build (xenial/unity-scope-click). Successfully built (yakkety/unity-scope-click)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Pending binary packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Pending binary packages (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Successfully built
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Generating diffs
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Successfully built
<jgdx> rvr, basically just regression testing for a select pair of panels, including the main panel
<jgdx> rvr, how can I communicate this to you? What do you need to test it?
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/1919 Needs building (vivid/oxide-qt, xenial/oxide-qt). Ready to build (yakkety/oxide-qt)
<jgdx> rvr, added notes on what's affected, at least
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Failed to build
-queuebot:#ubuntu-ci-eng- sil2100 vicamo, https://bileto.ubuntu.com/#/ticket/2040 Release pocket
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Dependency wait (yakkety/indicator-keyboard, yakkety/indicator-power, yakkety/indicator-sound). Destination version missing from changelog (yakkety/indicator-bluetooth, yakkety/indicator-session). Needs rebuild due to new commits (yakkety/indicator-display, yakkety/indicator-network). Pending binary packages (yakkety/libindicator). Successfully built (yakkety/hud, yakkety
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Proposed pocket (yakkety/indicator-bluetooth). UNAPPROVED queue (yakkety/unity-control-center, yakkety/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Destination version missing from changelog (yakkety/unity-scope-click). Failed to build (xenial/unity-scope-click)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Proposed pocket (yakkety/indicator-bluetooth, yakkety/unity-control-center). UNAPPROVED queue (yakkety/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2044 Ready to build
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Proposed pocket (yakkety/unity-control-center, yakkety/unity-settings-daemon). Release pocket (yakkety/indicator-bluetooth)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 QA Signoff: Approved
#ubuntu-ci-eng 2016-10-05
-queuebot:#ubuntu-ci-eng- justinmcp, https://bileto.ubuntu.com/#/ticket/1823 Failed to build (vivid/oxide-qt). Successfully built (vivid/media-hub, xenial/media-hub, xenial/oxide-qt, yakkety/media-hub, yakkety/oxide-qt)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Proposed pocket (yakkety/unity-control-center). Release pocket (yakkety/indicator-bluetooth, yakkety/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/1919 Diff missing (xenial/oxide-qt). Pending binary packages (vivid/oxide-qt). Ready to build (yakkety/oxide-qt)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/1919 Diff missing (vivid/oxide-qt, xenial/oxide-qt). Ready to build (yakkety/oxide-qt)
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/1995 Release pocket
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2037 Release pocket
-queuebot:#ubuntu-ci-eng- bregma, https://bileto.ubuntu.com/#/ticket/2020 Publishing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1964 REJECTED queue (xenial/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Failed to build (xenial/unity-scope-click). Needs rebuild due to new commits (yakkety/unity-scope-click)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Dependency wait (yakkety/indicator-keyboard, yakkety/indicator-power, yakkety/indicator-sound). Destination version missing from changelog (yakkety/indicator-session). Needs rebuild due to new commits (yakkety/indicator-bluetooth, yakkety/indicator-display, yakkety/indicator-network). Pending binary packages (yakkety/libindicator). Successfully built (yakkety/hud, yakkety
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2012 Proposed pocket
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Destination version missing from changelog (yakkety/unity8-desktop-session). Needs rebuild due to new commits (yakkety/unity8). Pending binary packages (yakkety/lightdm). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session,
-queuebot:#ubuntu-ci-eng- bregma, https://bileto.ubuntu.com/#/ticket/2020 Proposed pocket (yakkety/unity8-desktop-session). Release pocket (xenial/unity8-desktop-session)
<mardy> rvr: ping
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1949 Currently building (xenial/qtbase-opensource-src, xenial/qtdeclarative-opensource-src). Diff missing (yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src, yakkety/qtquickcontrols2-opensource-src). Failed to build (xenial/qtquickcontrols2-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, y
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1949 Currently building (xenial/qtdeclarative-opensource-src). Diff missing (yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src, yakkety/qtquickcontrols2-opensource-src). Failed to build (xenial/qtbase-opensource-src, xenial/qtquickcontrols2-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, y
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1949 Diff missing (yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src, yakkety/qtquickcontrols2-opensource-src). Failed to build (xenial/qtbase-opensource-src, xenial/qtdeclarative-opensource-src, xenial/qtquickcontrols2-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-
<rvr> mardy: pong
<mardy> rvr: sorry, didn't hear the pong :-)
<mardy> rvr: about the owncloud silo... are you 100% sure that the plugin got uprgaded?
<rvr> mardy: Yes
<rvr> mardy: Well, I installed the packages in the silo
<mardy> rvr: do you have it installed right now?
<rvr> Hmm
<rvr> These are not the packages I were expecting
<rvr> I was
<rvr> mardy: Seems you are right
<mardy> rvr: maybe you installed another silo by mistake?
<rvr> Seems so
<mardy> rvr: you owe me three cookies and one castle
-queuebot:#ubuntu-ci-eng- bregma, https://bileto.ubuntu.com/#/ticket/2020 Release pocket
-queuebot:#ubuntu-ci-eng- anpok, https://bileto.ubuntu.com/#/ticket/2003 QA Signoff: Approved
<rvr> mardy: lol
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/1925 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Needs rebuild due to new commits (yakkety/unity8, yakkety/unity8-desktop-session). Pending binary packages (yakkety/lightdm). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session, xenial/unity8, xenial/unity8-desktop-session
<oSoMoN> trainguards: could you please finalize silos 1821 and 1925 ? I abandoned them, but I donât seem to be able to finalize them myself
<oSoMoN> vigo, can you confirm whether with the latest webbrowser-app package your builtin webcam is detected? should we re-open bug #1626611 ?
<ubot5> bug 1626611 in webbrowser-app (Ubuntu) "camera not detected when running confined on desktop" [High,Fix released] https://launchpad.net/bugs/1626611
<vigo> oSoMoN, I'll try it later :)
<oSoMoN> vigo, thanks, please keep me posted
<vigo> oSoMoN, sure ;)
<sil2100> oSoMoN: you want to finalize abandoned silos?
<sil2100> oSoMoN: finalize means merging the changes to trunk, if a silo is abandoned then the idea is that you don't want the silo and its contents
<sil2100> So if you abandoned the requests, then why would you want to suddenly merge those changes?
<oSoMoN> sil2100, no, IÂ donât want to merge the branches, I just want the silos to be freed :)
<oSoMoN> those requests have been superseded by others, it doesnât make sense to keep them in the dashboard
<sil2100> oSoMoN: abandoning a silo also frees the PPA, so just an abandon should be fine :)
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Currently building (vivid/webbrowser-app). Failed to build (xenial/webbrowser-app, yakkety/webbrowser-app)
<oSoMoN> sil2100, ok
<oSoMoN> trainguards: Iâm seeing arm64 builds fail for webbrowser-app in xenial and yakkety (unit tests segfault), they passed last week, is there a known regression?
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2027 Abandoning ticket
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2038 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2038 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Failed to build (xenial/webbrowser-app, yakkety/webbrowser-app). Successfully built (vivid/webbrowser-app)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2038 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2048 Ready to build
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2048 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Successfully built
<Mirv> oSoMoN: I heard of similar problem two hours ago, so I guess there is a problem. does it look like related to qmlplugindump? there was qtdeclarative update that fixed an important desktop bug #1613670
<ubot5> bug 1613670 in oxide-qt (Ubuntu) "Webview turns white after clicking on it" [High,Confirmed] https://launchpad.net/bugs/1613670
<Mirv> oSoMoN: there was also a critical qtbase QDBus fix but I hope it's at least not related to that bug #1618590
<ubot5> bug 1618590 in Canonical System Image "scoperunner crashed with SIGSEGV in QObject::disconnect()" [Critical,Fix committed] https://launchpad.net/bugs/1618590
<Mirv> the problem of course is that they are very important for desktop to have... but first we'd need to know what is causing the problem
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2048 Pending binary packages
<oSoMoN> Mirv, I have no idea whatâs causing them for now, will need to try and reproduce them locally
<Mirv> oSoMoN: yeah, for starters I uploaded qtdeclarative with the last patch commented out at https://bileto.ubuntu.com/#/ticket/2049 for xenial and yakkety
<Mirv> but if it's that, I'd like to do some hack to not apply it on arm64 only
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2048 Successfully built
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1992 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 Publishing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Currently building (yakkety/qtdeclarative-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src). Ready to build (xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Currently building (vivid/unity8, xenial/unity8). Failed to build (yakkety/unity8)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 Release pocket (vivid/libertine, xenial/libertine). UNAPPROVED queue (yakkety/libertine)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/unity8)
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Preparing packages
<Mirv> oSoMoN: the revert seems to be failing to build on arm64! https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2049/+packages it's almost as if something else changed, but I can't figure out what that could be
<Mirv> or there's a segfault during tests, in other words
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/unity8)
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Currently building (vivid/webbrowser-app). Failed to build (xenial/webbrowser-app, yakkety/webbrowser-app)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2042 Abandoning ticket
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 QA Signoff: Approved
<rvr> mardy: Silo 1817 approved
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Currently building (xenial/qtbase-opensource-src, yakkety/qtbase-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Failed to build (xenial/webbrowser-app, yakkety/webbrowser-app). Pending binary packages (vivid/webbrowser-app)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Ready to build
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Failed to build (xenial/webbrowser-app, yakkety/webbrowser-app). Successfully built (vivid/webbrowser-app)
<mardy> rvr: thanks
<mardy> Mirv: hi! Do I need to do something on https://bileto.ubuntu.com/#/ticket/1992 and https://bileto.ubuntu.com/#/ticket/1817 ?
<Mirv> mardy: 1992 you need to publish (yourself), for 1817 you will need to find a friendly core-dev and I can be that
<mardy> Mirv: I totally accept your nomination :-) thanks!
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Publishing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Diff missing
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1992 Publishing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Failed to build (xenial/unity8, yakkety/unity8). Needs rebuild due to new commits (yakkety/ubuntu-settings-components). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Release pocket (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts). UNAPPROVED queue (yakkety/online-accounts-api, yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/ubuntu-settings-components, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Failed to build (xenial/online-accounts-api, yakkety/online-accounts-api). Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts). Successfully built (vivid/online-accounts-api, vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety/signon-apparmor-extension). UNAPPROVED queue (yakkety/ubun
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1992 Release pocket (vivid/account-plugins, xenial/account-plugins). Successfully built (yakkety/account-plugins)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Pending binary packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/1675 Bad merges (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles)
-queuebot:#ubuntu-ci-eng- zhangew401, https://bileto.ubuntu.com/#/ticket/2014 QA Signoff: Ready
<tedg> sil2100: Do you know if we can force merge a silo when the packages are in the unapproved queue?
<tedg> Will the next silo build with the right revision?
<tedg> Specifically talking about: https://bileto.ubuntu.com/#/ticket/2039
<tedg> I'd like to land another libertine branch.
<sil2100> tedg: no, that's not allowed
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Successfully built
<sil2100> tedg: so the only way you can merge a silo is to finalize it, where finalize means removing the PPA
<sil2100> And until the packages are in a real pocket, the packages need to stay in the PPA
<tedg> Ah, so the queue is a queue of the copy command not a queue of the packages themselves.
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
<sil2100> tedg: yeah, sadly, it's not a separate pocket, we learned it the hard way once already
<sil2100> That's why we disabled finalizing in such cases even
<tedg> Ah, okay.
<tedg> Thanks sil2100 !
<tedg> ChrisTownsend: FYI ^
<ChrisTownsend> tedg: ack, thanks
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/unity8)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components). Successfully built (vivid/unity8)
<oSoMoN> Mirv, could https://launchpad.net/bugs/1630510 be another regression introduced by the QtDBus patches that recently landed?
<ubot5> Ubuntu bug 1630510 in webbrowser-app (Ubuntu) "webbrowser-app crashed with SIGSEGV in QNetworkSession::~QNetworkSession()" [Medium,Confirmed]
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Currently building (xenial/qtbase-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, yakkety/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Currently building (vivid/unity8). Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/qtmir, xenial/qtmir, yakkety/qtmir). Successfully built (vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-not
<cjwatson> oSoMoN,Mirv: one possibility is that we upgraded the arm64 builder images to be xenial rather than wily a day or two ago, so they're now running on a 4.4 kernel rather than 4.2
<cjwatson> oSoMoN,Mirv: really don't want to go back to wily unless there's very widespread breakage though, for obvious reasons
<cjwatson> oSoMoN,Mirv: (and if the tests fail just due to a newer kernel, that seems like something you'd want to investigate anyway)
<oSoMoN> ack
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles). Uploading build (xenial/qtbase-opensource-src)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/qtmir, vivid/unity8, xenial/qtmir, yakkety/qtmir). Successfully built (vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/q
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Diff missing (xenial/qtbase-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Preparing packages
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 yakkety/qtubuntu: Failed to merge https://code.launchpad.net/~nick-dedekind/qtubuntu/menuTheme
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Failed to build (xenial/online-accounts-api, yakkety/online-accounts-api). Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts, yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/online-accounts-api, vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety/signon-app
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/unity8)
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Proposed pocket (yakkety/online-accounts-api, yakkety/ubuntu-system-settings-online-accounts). Release pocket (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Destination version missing from changelog (yakkety/libertine). Successfully built (vivid/libertine, vivid/ubuntu-app-launch, xenial/libertine, xenial/ubuntu-app-launch, yakkety/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 Proposed pocket (yakkety/libertine). Release pocket (vivid/libertine, xenial/libertine)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Preparing packages
<tedg> sil2100: So you think we're cool to force merge this now? https://bileto.ubuntu.com/#/ticket/2039
<sil2100> tedg: ok, just be sure to watch it move out of -proposed
<sil2100> On it
<tedg> Ah, cool. I could do it, just wanted to make sure I wasn't going to screw everything up :-)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2039 Merging branches
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/q
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src). Pending binary packages (xenial/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN Kaleo, https://bileto.ubuntu.com/#/ticket/1873 Failed to build (xenial/webbrowser-app). Needs rebuild due to new commits (yakkety/webbrowser-app). Successfully built (vivid/webbrowser-app)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubunt
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (vivid/unity8, xenial/unity8, yakkety/unity8). Failed to build (vivid/qmenumodel, xenial/qmenumodel, yakkety/qmenumodel). Pending binary packages (vivid/qtubuntu, vivid/qtubuntu-gles, xenial/qtubuntu, xenial/qtubuntu-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Diff missing (xenial/qtbase-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
<robru> mardy: you need to publish 1992 again, it broke the time you tried it
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/unity8)
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 QA Signoff: Approved
<alesage> robru, random question: I'm aware of the bileto API but would there be a way to get historical data?
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Pending binary packages (vivid/libertine, xenial/libertine, yakkety/libertine). Successfully built (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch, yakkety/ubuntu-app-launch)
<robru> alesage: yes? Bileto api exposes access to every ticket ever created...
<alesage> robru, aha of course ok thx
<alesage> was thinking by silo
<robru> alesage: /v1/ticket/N will work even for closed tickets
<alesage> robru, many thanks
<robru> alesage: and /#/ticket/N to browse it. You're welcome
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (vivid/unity8, xenial/unity8, yakkety/unity8). Failed to build (vivid/qmenumodel, xenial/qmenumodel, yakkety/qmenumodel). Successfully built (vivid/qtubuntu, vivid/qtubuntu-gles, xenial/qtubuntu, xenial/qtubuntu-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 Successfully built
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (vivid/unity8, xenial/unity8, yakkety/unity8). Failed to build (vivid/qmenumodel, xenial/qmenumodel, yakkety/qmenumodel). Successfully built (vivid/qtubuntu, vivid/qtubuntu-gles, xenial/qtubuntu, xenial/qtubuntu-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles)
<rvr> bzoltan: zsombi: Text clear button still doesn't work, take a look to https://trello.com/c/Wi0CYpIx/3671-2035-ubuntu-2035-ubuntu-ui-toolkit-bzoltan
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 yakkety/unity8: Failed to branch https://code.launchpad.net/~mzanetti/unity8/unified-stages
-queuebot:#ubuntu-ci-eng- pstolowski marcustomlinson, https://bileto.ubuntu.com/#/ticket/1785 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, 
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Currently building (vivid/unity8). Dependency wait (xenial/unity8, yakkety/unity8). Failed to build (vivid/qmenumodel, xenial/qmenumodel, yakkety/qmenumodel). Successfully built (vivid/qtubuntu, vivid/qtubuntu-gles, xenial/qtubuntu, xenial/qtubuntu-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles)
<bzoltan> rvr: thanks for testing it. i am checking it out
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Proposed pocket (yakkety/ubuntu-system-settings-online-accounts). Release pocket (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts, yakkety/online-accounts-api)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (xenial/unity8, yakkety/unity8). Failed to build (vivid/qmenumodel, xenial/qmenumodel, yakkety/qmenumodel). Successfully built (vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity8, xenial/qtubuntu, xenial/qtubuntu-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles)
<bzoltan> rvr:  how did you do that? I opened the UITK component gallery and I could clear the text area with the (x)
<rvr> bzoltan: I used krillin + silo
<bzoltan> rvr:  me too
<bzoltan> rvr: Are you on telegram? I have a video
<bzoltan> rvr: http://pastebin.ubuntu.com/23280916/
<bzoltan> rvr: http://pastebin.ubuntu.com/23280917/
<bzoltan> rvr:  https://youtu.be/53x7fMjzRkY
<rvr> bzoltan: private video
<bzoltan> rvr:  try now
-queuebot:#ubuntu-ci-eng- zhangew401, https://bileto.ubuntu.com/#/ticket/2014 QA Signoff: Approved
<rvr> phablet@ubuntu-phablet:~$ click list | grep gallery
<rvr> com.ubuntu.developer.bzoltan.ubuntu-ui-toolkit-gallery	1.3.2060.1
<rvr> bzoltan: http://paste.ubuntu.com/23280960/
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
<Mirv> cjwatson: hmm, okay, that would help in understanding the problem since it seems to appeared out of nowhere (since also the previous version of qtdeclarative fails its own test on arm64 now)
<bzoltan> rvr: reboot?
<bzoltan> maybe
-queuebot:#ubuntu-ci-eng- dbarth mardy, https://bileto.ubuntu.com/#/ticket/1817 Release pocket
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Failed to build (xenial/online-accounts-api). Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts). Needs rebuild due to new commits (yakkety/online-accounts-api, yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/online-accounts-api, vivid/signon-apparmor-extension, xenial/signon-app
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2052 Pending binary packages
<rvr> bzoltan: Still failing
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Failed to build (xenial/online-accounts-api). Needs rebuild due to new commits (yakkety/online-accounts-api). Successfully built (vivid/online-accounts-api)
<rvr> bzoltan: If you see, the test case requires the suggestions to be enabled
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2052 Successfully built
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2052 Publishing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2052 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Currently building (vivid/unity8). Failed to build (xenial/unity8, yakkety/unity8)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1956 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/unity8)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Publishing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Release pocket (xenial/unity-scope-click). UNAPPROVED queue (yakkety/unity-scope-click)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Proposed pocket (yakkety/unity-scope-click). Release pocket (xenial/unity-scope-click)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Pending binary packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2052 Proposed pocket
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2052 Release pocket
<bzoltan> rvr:  yes, the issue happens if the word suggestion settings is on
#ubuntu-ci-eng 2016-10-06
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2053 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Pending binary packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2053 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Currently building (yakkety/qtbase-opensource-src, yakkety/qtdeclarative-opensource-src). Diff missing (xenial/qtbase-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2046 Release pocket
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Currently building (yakkety/qtbase-opensource-src). Diff missing (xenial/qtbase-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
<bzoltan> rvr:  I have tested it on a device what has #2104 UITK, so the actual released and it is the same issue.  As long the text wasn't committed to the text input, then it's input method, otherwise it is text input. So the clear button does not see it... as the clear button clears th etext input and not the text method. It is a bug indeed, but it is not a regression.
<bzoltan> rvr: the fun is, that after a word is committed, the second suggestion is cleared if you clear the content so we only have problem with clearing the first suggestion
<bzoltan> rvr: We have a bug for it and it will be fixed in the next release - https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1630872
<ubot5> Ubuntu bug 1630872 in ubuntu-ui-toolkit (Ubuntu) "Clear text (x) does not clear the first suggested but not committed word" [Critical,Confirmed]
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2049 Diff missing (xenial/qtbase-opensource-src, yakkety/qtbase-opensource-src). Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtbase-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
<mardy> Mirv: hi! Do i need your magic powers for https://bileto.ubuntu.com/#/ticket/1992, or is it going to land by itself?
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Preparing packages
<Mirv> mardy: it won't land unless you land it. so the simple rule is: if no packaging changes, you can publish it. if packaging changes, you'll need core-dev to ack them and if there are new binary packages you'll need even archive admin to review the new packages.
<Mirv> mardy: ah, sorry, I read the status line wrong... it seems yakkety is missing!
<Mirv> mardy: I'd guess archive admins have rejected it, in that case, you may or may not have gotten e-mail about that.
<Mirv> mardy: was it earlier in unapproved queue according to the status?
<mardy> Mirv: no e-mail, and I don't think it was ever in the unapproved queue
<mardy> Mirv: I hit the publish button yesterday afternoon
<Mirv> mardy: weird
<Mirv> mardy: oh... https://bileto.ubuntu.com/log/1992/publish/1/info/ <- robru, there was an exception apparently during copying to yakkety
<Mirv> mardy: so that publish job log explains something went wrong. well, what you can do is try to hit publish again and let's see the log.
 * mardy tries
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Failed to build (vivid/online-accounts-api, xenial/online-accounts-api, yakkety/online-accounts-api). Needs rebuild due to burned version number (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts). Needs rebuild due to new commits (yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/signon-apparmor-extension, xenial/signon-app
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1992 Publishing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Failed to build
<Mirv> mardy: robru: second try worked, thanks mardy! no error in publish job and package in queue now: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=account-plugins
<mardy> Mirv: thanks :-)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1992 Release pocket (vivid/account-plugins, xenial/account-plugins). UNAPPROVED queue (yakkety/account-plugins)
<mardy> Mirv: are you aware of any problems with arm64 builders?
<mardy> Mirv: today online-accounts-api tests seem to all have started to reliably fail on arm64, with the same error: https://launchpadlibrarian.net/288504657/buildlog_ubuntu-xenial-arm64.online-accounts-api_0.1+16.04.20161006-0ubuntu1_BUILDING.txt.gz
<mardy> Mirv: but the only changes that we landed yesterday seem quite harmless: http://bazaar.launchpad.net/~online-accounts/online-accounts-api/trunk/revision/27
<Mirv> mardy: yes, see #ubuntu-devel my last messages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Publishing packages
<Mirv> mardy: they updated builders to use xenial's (4.4) kernel instead of wily's older one. QML stuff breaks.
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2048 Publishing packages
<mardy> Mirv: ouch
<Mirv> ouch indeed, no idea if the problem is in Qt, kernel, libc, compiler or where..
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2048 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Currently building (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts, yakkety/ubuntu-system-settings-online-accounts). Failed to build (vivid/online-accounts-api, xenial/online-accounts-api). Needs rebuild due to new commits (yakkety/online-accounts-api). Successfully built (vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Failed to build
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2047 Proposed pocket
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Failed to build (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts, yakkety/ubuntu-system-settings-online-accounts). Needs rebuild due to new commits (yakkety/online-accounts-api). Successfully built (vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety/signon-apparmor-exte
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Preparing packages
<mardy> Mirv: do we have a bug # for the QML issue?
<Mirv> mardy: not yet, I'm not sure what to file it against but let me start with something
<Mirv> mardy: oh, even vivid!
<Mirv> so it affects Qt 5.4 too, and likewise GCC 4.9, 5, 6 and multiple libc versions.
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Preparing packages
<Mirv> mardy: ok bug #1630906 is there now
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1992 Proposed pocket (yakkety/account-plugins). Release pocket (vivid/account-plugins, xenial/account-plugins)
<ubot5> bug 1630906 in ubuntu-push-qml (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,New] https://launchpad.net/bugs/1630906
<Mirv> 7w 23
<sil2100> mzanetti: ^
<mzanetti> ack
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
<rvr> bzoltan: Ok, I'll continue testeing
<rvr> testing
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Pending binary packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Pending binary packages (vivid/online-accounts-api, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/ubuntu-system-settings-online-accounts, yakkety/online-accounts-api, yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/signon-apparmor-extension, xenial/signon-apparmor-extension, yakkety/signon-apparmor-extension)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Needs rebuild due to new commits (yakkety/online-accounts-api). Successfully built (vivid/online-accounts-api, xenial/online-accounts-api)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Pending binary packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Needs rebuild due to new commits (yakkety/online-accounts-api). Successfully built (vivid/online-accounts-api, vivid/signon-apparmor-extension, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/signon-apparmor-extension, xenial/ubuntu-system-settings-online-accounts, yakkety/signon-apparmor-extension, yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
<bzoltan> rvr:  thank you... good catch this bug was. Kudos :)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 vivid/unity-notifications: debdiff failed: see log for details
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Failed to build (xenial/unity8, yakkety/unity8). Needs rebuild due to new commits (yakkety/ubuntu-settings-components). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Pending binary packages (yakkety/online-accounts-api, yakkety/ubuntu-system-settings-online-accounts). Successfully built (vivid/online-accounts-api, vivid/signon-apparmor-extension, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/signon-apparmor-extension, xenial/ubuntu-system-settings-online-accounts, yakkety/signon-apparmor-extension)
<cjwatson> Mirv: Do you have access to a 4.4 arm64 box where you (or somebody appropriate) could dig into this?  I see the porter is on 3.13, so not very helpful
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/telephony-service, xenial/telephony-service, yakkety/telephony-service). Failed to build (xenial/telepathy-ofono, yakkety/history-service, yakkety/telepathy-ofono). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, xenial/history-service, xenial/messaging-app, yakkety/messaging-app)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Pending binary packages (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles, yakkety
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Successfully built
<Mirv> cjwatson: not that I can think of, frieza runs 3.10
<cjwatson> Mirv: I'd suggest asking IS folks if there's anything that can be done to help you there
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
<Mirv> cjwatson: ok.
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/history-service, yakkety/telepathy-ofono). Pending binary packages (vivid/telephony-service, xenial/telephony-service). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, xenial/history-service, xenial/messaging-app, yakkety/messaging-app, yakkety/telephony-service)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/history-service, yakkety/telepathy-ofono). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service, yakkety/messaging-app, yakkety/telephony-service)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Uploading build
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2017 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 Failed to build
<rvr> bzoltan: Silo 2035 approved
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Currently building (xenial/qtbase-opensource-src). Failed to build (yakkety/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, yakkety/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 Publishing packages
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 Release pocket (vivid/telephony-service, xenial/telephony-service). Successfully built (yakkety/telephony-service)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Pending binary packages
-queuebot:#ubuntu-ci-eng- popey, https://bileto.ubuntu.com/#/ticket/2045 QA Signoff: Approved
<boiko> robru: just FYI, there is an unhandled exception here: https://bileto.ubuntu.com/log/2009/publish/latest/
<boiko> robru: should I try to publish again, or is everything OK?
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/1943 QA Signoff: Approved
<boiko> trainguards: I tried to publish silo 2009, but got an exception, should i try again or is it ok?
<Mirv> boiko: please try again, mardy had similar problem earlier
<boiko> Mirv: thanks
<pmcgowan> Mirv, who is working on that builder segfault issue?
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 Publishing packages
<Mirv> pmcgowan: I just updated the bug report on what I got with help from IS and pinged doko and cj_watson, I hope they could come up with a person to go to next, either arm64 porter like doko on that same machine that now can reproduce the problem, or some kernel team member
<pmcgowan> Mirv, ok, and you said it doesnt crash on xenial+overlay on m10, is that with doing a build there or just running
<Mirv> pmcgowan: during build, ie the same qmlplugindump command that crashes on builders. also in general there is no change on M10 anywhere, it's still using 3.10 kernel unlike builders. this specific arm64 machine that is now similar enough to the builders (kernel 4.4) can reproduce the crash. I used xenial chroot, but the builders fail on any series as long as the 4.4 kernel is in use.
<Mirv> so maybe it's arm64 specific kernel change that prevents some usage that Qt triggers, regardless of Qt version, GCC version or libc6 version (vivid, xenial, yakkety)
<pmcgowan> Mirv, ack
<pmcgowan> Mirv, I get invalid branch for the code you linked in the bug
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 Release pocket (vivid/telephony-service, xenial/telephony-service). UNAPPROVED queue (yakkety/telephony-service)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Pending binary packages
<Mirv> pmcgowan: right I noticed the same and added a new comment with url that also works in a fresh session
<pmcgowan> Mirv, did you see patch tsdgeos pointed out?
<bzoltan> rvr:  thank you!
<Mirv> tsdgeos: pmcgowan: thank you yes I did, now building for yakkety and xenial at https://bileto.ubuntu.com/#/ticket/2055 - I need to stop now but tsdgeos if you have still time please see how hard that would be to backport to our vivid qtdeclarative from overlay PPA.
<tsdgeos> well let's see if it actually fixes anything first :D
<Mirv> that's ok too :)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Failed to build (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
<oSoMoN> vigo, have you had a chance to test webbrowser-app again with your built-in webcam?
<vigo> oSoMoN, not yet but give me 5 minuts and I'll tell you :)
<oSoMoN> thanks!
<vigo> oSoMoN, it is working for me now :)
<vigo> Toshiba webcam+FHD
<oSoMoN> vigo, awesome! thanks for confirming, I wonât re-open the bug report then
<vigo> oSoMoN, it appears in white colour instead of black, is that due to it is the only camera available?
<vigo> just the string I mean, not the whole field
<oSoMoN> vigo, yes itâs expected, the widget is disabled because thereâs no other choices
<vigo> oSoMoN, perfect :)
<vigo> thank you!
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Diff missing (xenial/qtbase-opensource-src). Pending binary packages (yakkety/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, yakkety/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Publishing packages
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Publish failed: Packaging diff requires ACK
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Successfully built
<bzoltan> Mirv:  the UITK has rules changes what need ack - https://bileto.ubuntu.com/#/ticket/2035
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Diff missing (xenial/qtbase-opensource-src, yakkety/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, yakkety/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, yakkety/qtmir, yakkety/qtmir-gles
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
<boiko> trainguards: telephony-service on silo 2009 is marked as being in the UNAPPROVED queue on yakkety, can you please force merge it so that the code gets into trunk at least?
<robru> boiko: sure can't! I just rolled out choice yesterday explicitly forbidding force merge in queues, you need talk to #ubuntu-release to get it either approved or rejected
<robru> boiko: and to your previous question, it's generally harmless to just mash the buttons again if you see an unhandled exception, which is generally the result of lp failing to respond to our lplip calls
<boiko> robru: thanks for the info :)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Successfully built
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Pending binary packages
<robru> boiko: you're welcome
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1992 Release pocket
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service, yakkety/messaging-app, yakkety/telephony-service)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Bad merges (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Currently building (vivid/qtmir, vivid/unity8, xenial/qtmir, xenial/unity8, yakkety/qtmir). Failed to build (yakkety/unity8). Successfully built (vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir-
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Publishing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubunt
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Release pocket (vivid/ubuntu-ui-toolkit, vivid/ubuntu-ui-toolkit-gles, xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles). UNAPPROVED queue (yakkety/ubuntu-ui-toolkit, yakkety/ubuntu-ui-toolkit-gles)
<sil2100> robru: hey! I guess it's time to do the switch to yakkety-overlay
<robru> sil2100: ok, will do, just finishing lunch
<dobey> sil2100, robru: i thought we weren't going to do overlay for yakkety ?
<robru> dobey: why wouldn't we? Phone dev needs to continue in spite of freeze
<dobey> because we're not going to release a phone with yakkety.
<robru> dobey: the yakkety packages still need to go somewhere
<dobey> why do there need to be yakkety packages at all if they're not going to yakkety archive?
<dobey> would be nice to be able to do xenial+vivid only in bileto
<robru> dobey: they go to z once z exists. We just skip the freeze
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Proposed pocket (yakkety/ubuntu-ui-toolkit, yakkety/ubuntu-ui-toolkit-gles). Release pocket (vivid/ubuntu-ui-toolkit, vivid/ubuntu-ui-toolkit-gles, xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles)
<sil2100> robru: thanks!
<robru> sil2100: yw
<sil2100> dobey: requirement is to always support lastest upstream
<sil2100> dobey: just because we don't intend to release a product with yakkety doesn't mean we won't release one with z, or the next one
<sil2100> Trunk always needs to be up to date
<sil2100> Triple landings will go away once we kill vivid
<dobey> sil2100: i don't see how "trunk needs to be up to date" and "trunk always needs to land somewhere even if we don't support it" are the same thing though
<robru> dobey: think of the sru process. Bugs need to be fixed in devel before backporting to a release. You propose we would develop vivid ahead of yakkety, so that vivid would be ahead of yakkety.
<dobey> robru: i didn't say anything about vivid
<sil2100> Or xenial
<dobey> well xenial is an lts
<robru> dobey: you literally said you want to target only xenial+ vivid
<dobey> robru: yes, i said that should be doable in bileto.
<sil2100> Yes, but it's like robru said, we follow the standard archive procedures here
<sil2100> The current devel series always needs to be up to date
<sil2100> Since, as I said, in like 1-2 years we decide to switch off from xenial to a new series (or whatever), then we'd have a huge delta
<robru> dobey: anyway if you were to do development without yakkety, it would increase the Delta between phones and desktops, which would take us farther away from our convergence vision
<dobey> i don't think so
<sil2100> That's what happened in the ubuntu-rtm/14.09 times
<dobey> there are already plenty of cases where yakkety and vivid+overlay differ, including the need of several projects to have a stable branch for vivid while new things are developed for the snap world
<sil2100> The general idea is that everyone is required to have all the changes also present, supported and tested in yakkety
<sil2100> Just because people break the rule doesn't mean it's good and acceptable from the archive POV
<robru> dobey: in theory, people who forked for vivid are supposed to be releasing to yakkety first then backporting to vivid like an sru. forking for vivid isn't meant for vivid development to proceed ahead of where yakkety development is. any projects doing that are Very Bad And Should Feel Bad.
<sil2100> We should follow standard archive procedures, the overlay is just a faster way of deploying than waiting for every change to go through as SRU
<dobey> robru: no, my point is that there are things that can't work on vivid
<dobey> and the current practice has led us to putting things in vivid that shouldn't be there anyway
<dobey> sil2100: well no, really the overlay is just a cache so we can land stuff and then dump it over to z when z opens, because it's unlikely any of it will be pushed out as an SRU to yakkety
<sil2100> For the yakkety case, yes
<robru> sil2100: ok the change is pushed to production, over the next 20 minutes any trio tickets that were published will switch from "UNAPPROVED queue/Proposed pocket (yakkety). Release pocket (xenial, vivid)" to "Successfully built (yakkety). Release pocket (xenial, vivid)" and a simple republish will publish yakkety to overlay then automerge within 20 minutes
<robru> after that
<sil2100> robru: \o/ thanks again ;)
<robru> sil2100: you're welcome
<robru> sil2100: also I'll keep an eye on any migrating tickets, get some sleep ;-)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service, yakkety/telephony-service). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service, yakkety/messaging-app)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1868 Release pocket (vivid/apparmor-easyprof-ubuntu, xenial/apparmor-easyprof-ubuntu). Successfully built (yakkety/apparmor-easyprof-ubuntu)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Pending binary packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1868 Publish failed: robru not authorized to upload apparmor-easyprof-ubuntu
<robru> but but but but
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Preparing packages
<robru> oh it's manuals, not merges
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 DONE queue (yakkety/ubuntu-ui-toolkit, yakkety/ubuntu-ui-toolkit-gles). Release pocket (vivid/ubuntu-ui-toolkit, vivid/ubuntu-ui-toolkit-gles, xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1868 Release pocket
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 REJECTED queue (yakkety/telephony-service). Release pocket (vivid/telephony-service, xenial/telephony-service)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Successfully built
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 DONE queue (yakkety/ubuntu-ui-toolkit-gles). Release pocket (vivid/ubuntu-ui-toolkit, vivid/ubuntu-ui-toolkit-gles, xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles, yakkety/ubuntu-ui-toolkit)
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2009 Release pocket
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2035 Release pocket
-queuebot:#ubuntu-ci-eng- boiko, https://bileto.ubuntu.com/#/ticket/1897 Failed to build (xenial/history-service, xenial/telephony-service, yakkety/history-service). Needs rebuild due to new commits (yakkety/telephony-service). Ready to build (vivid/telepathy-qt, xenial/telepathy-qt, yakkety/telepathy-qt). Successfully built (vivid/history-service, vivid/telephony-service)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2051 Abandoning ticket
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service, yakkety/messaging-app, yakkety/telephony-service). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, xenial/messaging-app, xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service, yakkety/messaging-app). Pending binary packages (vivid/telephony-service, xenial/telephony-service). Successfully built (vivid/history-service, vivid/telepathy-ofono, xenial/history-service, yakkety/telephony-ser
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service, yakkety/messaging-app). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service, yakkety/telephony-service)
#ubuntu-ci-eng 2016-10-07
<Mirv> bzoltan: seems like you got it landed, great!
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1964 Publishing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1964 Publish failed: Diff missing (xenial/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/1964 Ready to build (xenial/qtbase-opensource-src-gles). UNAPPROVED queue (xenial/qtbase-opensource-src)
<bzoltan> Mirv: slangasek was the kind one who assisted :)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Pending binary packages (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Diff missing (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Generating diffs
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Diff missing (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src). Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles, xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Diff missing (yakkety/qtdeclarative-opensource-src-gles). Pending binary packages (xenial/qtdeclarative-opensource-src-gles). Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles). Successfully built (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Diff missing (xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles). Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles). Successfully built (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Generating diffs
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Diff missing (xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src-gles). Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles). Successfully built (xenial/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Ready to build (vivid/qtdeclarative-opensource-src, vivid/qtdeclarative-opensource-src-gles). Successfully built (xenial/qtdeclarative-opensource-src, xenial/qtdeclarative-opensource-src-gles, yakkety/qtdeclarative-opensource-src, yakkety/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 QA Signoff: N/A
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Bad merges (yakkety/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/q
<jgdx> trainguards: hey, can someone publish/finalize https://bileto.ubuntu.com/#/ticket/1943 ?
<Mirv> jgdx: yes, you can :)
<Mirv> there are no packaging changes
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
<jgdx> Mirv, okay, thank you!
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/1943 Publishing packages
-queuebot:#ubuntu-ci-eng- anpok, https://bileto.ubuntu.com/#/ticket/2003 Publishing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Currently building (vivid/unity8). Failed to build (xenial/unity8). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notificat
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/1943 Release pocket
-queuebot:#ubuntu-ci-eng- anpok, https://bileto.ubuntu.com/#/ticket/2003 Release pocket
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2056 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Generating diffs
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2056 Pending binary packages (xenial/repowerd). Successfully built (vivid/repowerd, yakkety/repowerd)
-queuebot:#ubuntu-ci-eng- pstolowski marcustomlinson, https://bileto.ubuntu.com/#/ticket/1785 QA Signoff: Approved
<Mirv> ubuntu-qa: how can I require QA Signoff for yakkety+xenial silos? would need for https://bileto.ubuntu.com/#/ticket/2055 and https://bileto.ubuntu.com/#/ticket/2054
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Generating diffs
<jibel> Mirv, no idea. robru ^
<rvr> Mirv: We only test in xenial (rc-proposed)
<rvr> Target Series	yakkety+xenial
<rvr> Seems correct ?
<jibel> rvr, it is not a reason. you cannot set qa signoff to required. bileto forces it to n/a
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2056 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2055 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Currently building (xenial/qtbase-opensource-src-gles). Failed to build (yakkety/qtbase-opensource-src-gles). Successfully built (xenial/qtbase-opensource-src, yakkety/qtbase-opensource-src)
<Mirv> now it seems you managed to do that, thank you
<jibel> Mirv, yes but I am not sure status will change to ready automatically
<Mirv> probably not
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubunt
-queuebot:#ubuntu-ci-eng- pstolowski marcustomlinson, https://bileto.ubuntu.com/#/ticket/1785 Publishing packages
<Mirv> ubuntu-qa: anyway, tickets 2054 and 2055 are ready from my point of view (only gles builds need a retry or two in 2054), and they affect a) yakkety iso tracker bug (2054), b) anything QML broken to build on arm64 (2055). tickets have all the necessary information regarding the options we have. I've tested yakkety desktop briefly but I have problems with my krillin so not phone / xenial+overlay. either
<Mirv> landing can also be considered separately for its merits.
-queuebot:#ubuntu-ci-eng- pstolowski marcustomlinson, https://bileto.ubuntu.com/#/ticket/1785 Release pocket
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service, yakkety/messaging-app, yakkety/telephony-service). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service)
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2056 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Currently building (yakkety/qtbase-opensource-src-gles). Failed to build (xenial/qtbase-opensource-src-gles). Successfully built (xenial/qtbase-opensource-src, yakkety/qtbase-opensource-src)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2057 Pending binary packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Failed to build (xenial/qtbase-opensource-src-gles). Successfully built (xenial/qtbase-opensource-src, yakkety/qtbase-opensource-src, yakkety/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2057 Successfully built
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Currently building (vivid/unity8). Dependency wait (xenial/unity8, yakkety/unity8). Failed to build (vivid/qmenumodel, xenial/qmenumodel, yakkety/qmenumodel). Successfully built (vivid/qtubuntu, vivid/qtubuntu-gles, xenial/qtubuntu, xenial/qtubuntu-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, 
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8, yakkety/unity8). Pending binary packages (vivid/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/messaging-app). Failed to build (xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service, yakkety/telephony-service). Successfully built (vivid/history-service, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/telephony-service). Uploading build (xenial/messaging-app, yakk
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (xenial/unity8, yakkety/unity8). Failed to build (vivid/qmenumodel, xenial/qmenumodel, yakkety/qmenumodel). Successfully built (vivid/qtubuntu, vivid/qtubuntu-gles, vivid/unity8, xenial/qtubuntu, xenial/qtubuntu-gles, yakkety/qtubuntu, yakkety/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/unity8)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, yakkety/telepathy-ofono). Needs rebuild due to new commits (yakkety/history-service, yakkety/telephony-service). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service, yakkety/messaging-app)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Currently building (vivid/unity8, xenial/unity8). Failed to build (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubunt
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2058 yakkety/ubuntu-themes: Failed to commit https://code.launchpad.net/~flexiondotorg/ubuntu-themes/lp1624571. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2058 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Currently building (vivid/unity8). Failed to build (xenial/unity8). PPA/bzr version mismatch (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, ya
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Currently building (vivid/unity8). Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2058 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2058 Publishing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2054 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2058 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubunt
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 Failed to build (vivid/address-book-app, xenial/address-book-app). Needs rebuild due to new commits (yakkety/address-book-app)
-queuebot:#ubuntu-ci-eng- zhangew401, https://bileto.ubuntu.com/#/ticket/2014 Publishing packages
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/1889 Failed to build (vivid/aethercast, yakkety/aethercast). Successfully built (xenial/aethercast)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, 
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/1889 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2058 Proposed pocket
#ubuntu-ci-eng 2016-10-08
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, yakkety/qtmir-gles, yakkety/qtubunt
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Failed to build (xenial/unity8). Needs rebuild due to new commits (yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, yakkety/qtmir, 
#ubuntu-ci-eng 2017-10-02
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2973 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2973 Release pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Failed to build (artful/unity). Successfully built (artful/gsettings-ubuntu-touch-schemas, artful/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Failed to build (artful/unity). Successfully built (artful/gsettings-ubuntu-touch-schemas, artful/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Successfully built
#ubuntu-ci-eng 2017-10-03
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Needs rebuild due to new commits (artful/unity-settings-daemon). Successfully built (artful/gsettings-ubuntu-touch-schemas, artful/unity)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Pending binary packages (artful/unity-settings-daemon). Successfully built (artful/gsettings-ubuntu-touch-schemas, artful/unity)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Needs rebuild due to new commits (artful/unity). Successfully built (artful/gsettings-ubuntu-touch-schemas, artful/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 You must add ~ci-train-bot to https://launchpad.net/~ubuntu-desktop to continue
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Successfully built
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2975 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 QA Signoff:
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 Successfully built
#ubuntu-ci-eng 2017-10-04
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Publish failed: Bad merges (artful/gsettings-ubuntu-touch-schemas). Packaging diff requires ACK (artful/unity, artful/unity-settings-daemon)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2970 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/2976 QA Signoff:
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2977 Preparing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2970 REJECTED queue
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Successfully built (artful/unity). UNAPPROVED queue (artful/gsettings-ubuntu-touch-schemas, artful/unity-settings-daemon)
#ubuntu-ci-eng 2017-10-05
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2967 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2978 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2978 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2978 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2978 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2970 Needs rebuild due to burned version number
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2947 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2978 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2978 Successfully built
#ubuntu-ci-eng 2017-10-06
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2979 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2979 Failed to build
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2980 Preparing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 Preparing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2982 Preparing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2982 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 Successfully built
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2982 Publishing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2982 UNAPPROVED queue
#ubuntu-ci-eng 2017-10-08
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2983 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2983 Successfully built
#ubuntu-ci-eng 2019-09-30
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3762 Needs rebuild due to higher version at destination (eoan/almanah, eoan/budgie-desktop, eoan/cheese, eoan/eog, eoan/evince, eoan/evolution, eoan/evolution-data-server, eoan/evolution-ews, eoan/evolution-indicator, eoan/evolution-rss, eoan/gdm3, eoan/gnome-calendar, eoan/gnome-clocks, eoan/gnome-contacts, eoan/gnome-control-center, eoan/gnome-documents, eoan/gnome-flashback, eoan/gnome-font-viewer, 
#ubuntu-ci-eng 2019-10-01
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 Publishing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3762 Needs rebuild due to higher version at destination (eoan/almanah, eoan/budgie-desktop, eoan/cheese, eoan/eog, eoan/evince, eoan/evolution, eoan/evolution-data-server, eoan/evolution-ews, eoan/evolution-indicator, eoan/evolution-rss, eoan/gdm3, eoan/gnome-calendar, eoan/gnome-clocks, eoan/gnome-contacts, eoan/gnome-control-center, eoan/gnome-desktop3, eoan/gnome-documents, eoan/gnome-flashback, eoa
#ubuntu-ci-eng 2019-10-02
-queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Uploading build
-queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Successfully built
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, /: Failed to update local lp:nux cache., disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 Ready to build (/: Failed to update local lp:compiz cache.). UNAPPROVED queue (eoan/compiz)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 Needs rebuild due to new commits (eoan/compiz). Ready to build (/:, eoan/Failed, eoan/cache., eoan/local, eoan/lp:compiz, eoan/to, eoan/update)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 Ready to build (/:, eoan/Failed, eoan/cache., eoan/local, eoan/lp:compiz, eoan/to, eoan/update). UNAPPROVED queue (eoan/compiz)
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Needs rebuild due to new commits (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Needs rebuild due to new commits (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3816 Preparing packages
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Needs rebuild due to higher version at destination
#ubuntu-ci-eng 2019-10-03
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2581 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2581 Dependency wait (zesty/ubuntu-system-settings-online-accounts). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-system-settings-online-accounts, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:ubuntu-system-settings-online-accounts, zesty/to, zesty/update). Successfully built (xenial/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3816 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 Proposed pocket (eoan/compiz). Ready to build (/:, eoan/Failed, eoan/cache., eoan/local, eoan/lp:compiz, eoan/to, eoan/update)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 Ready to build (/:, eoan/Failed, eoan/cache., eoan/local, eoan/lp:compiz, eoan/to, eoan/update). Release pocket (eoan/compiz)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3806 Merging branches
#ubuntu-ci-eng 2019-10-04
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3762 Needs rebuild due to higher version at destination (eoan/almanah, eoan/budgie-desktop, eoan/cheese, eoan/eog, eoan/evince, eoan/evolution, eoan/evolution-data-server, eoan/evolution-ews, eoan/evolution-indicator, eoan/evolution-rss, eoan/eweouz, eoan/gdm3, eoan/gnome-calendar, eoan/gnome-clocks, eoan/gnome-contacts, eoan/gnome-control-center, eoan/gnome-desktop3, eoan/gnome-documents, eoan/gnome-f
-queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Pending binary packages
-queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3807 Pending binary packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3807 Diff missing
