[00:27] <fginther> thomi, pong?
[00:30] <fginther> thomi, I'll should be back in 60-90 minutes
[01:26] <fginther> thomi, are you there?
[01:28] <thomi> fginther: am now - you?
[01:32] <fginther> thomi, yo
[01:33] <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.
[01:34] <fginther> thomi, I know that the retry code I used is not the way to go.
[01:34] <thomi> fginther: hey
[01:34] <fginther> thomi, good evening
[01:34] <thomi> fginther: I looked at your branch, but it wasn't clear to me exactly what the problem was you were trying to solve
[01:34] <thomi> fginther: so maybe we ought to have a hangout about this tomorrow first thing?
[01:35] <fginther> thomi, sorry about that, was a little rushed trying to send you something before I had to leave the house
[01:35] <fginther> thomi, hangout tomorrow would be good
[01:36] <thomi> fginther: yeah no worries
[01:36] <thomi> fginther: it'll have to be first thing tomorrow though, since I have an appt in town afterwards
[01:36] <thomi> fginther: I'll create a calendar event, so we both know when we're free
[01:36] <fginther> thomi, that works for me, please schedule what works for you
[01:37] <thomi> fginther: scheduled.
[01:37] <thomi> fginther: our clocks have changed, which means NZ + US now have more overlap
[01:37] <fginther> thomi, \o/
[01:38] <thomi> presumably the US clocks will change soon as well, which should make it even easier :)
[01:39] <fginther> thanks for offering to help, hopefully I'll understand the problem a little better tomorrow as well
[01:39] <fginther> have a good night
[01:39] <thomi> no worries
[06:48] <lool> heya
[06:50] <lool> didrocks: hangout?
[06:50] <didrocks> lool: still answering emails, ok in ~20 minutes?
[06:52] <lool> sure
[07:06] <lool> didrocks: I'm on
[07:07] <didrocks> lool: coffee and I'll be there
[07:24] <lool> https://code.launchpad.net/~bfiller/mediaplayer-app/remove-no-display/+merge/188092
[07:52] <lool> didrocks: LP #1232588
[08:33] <didrocks> vila: https://plus.google.com/hangouts/_/b31c28f31fcf9e093dc094c78119b1080db93ff7
[08:35] <vila> didrocks: sry, can't right now,
[08:35] <didrocks> no worry ;)
[08:36] <vila> didrocks, lool: some notes about the issue you mentioned during the week end: http://paste.ubuntu.com/6174698/
[08:36] <vila> didrocks, lool: i.e. I looked, it could be fixed, do we want to or is it overkill ?
[08:37] <vila> didrocks: no news about dns migration, will check later
[08:41] <ogra_> damn, my daily DLS reconnect seems to now fall exactly into the meeting :(
[08:41] <ogra_> *DSL
[08:58] <lool> vila-afk-biab: There was some news about DNS migation somewhere
[08:58] <lool> I heard we were switching DNS/DHCP in some lab since last friday, but can't remember where
[08:58] <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
[08:59] <lool> vila-afk-biab: There are certainly more urgent things to do though  ;-)
[08:59] <lool> ogra_: lol
[08:59] <lool> ogra_: perhaps you can reboot it in the morning?
[08:59] <ogra_> well, or late at night
[08:59] <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
[09:00] <ogra_> yeah, my reconnect used to be around 4 or 5am ... not sure why it moved
[09:00] <lool> it's tired of waking up so early, like me?
[09:00] <ogra_> i guess i'll set up a cronjob
[09:00] <ogra_> heh, likely
[09:02] <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
[09:02] <didrocks> lool: yeah, I wondered if it's the same
[09:02] <didrocks> lool: please feel free to remove my duplicate if it's the same ;)
[09:03] <lool> didrocks: I think yours covers slightly more, so will keep both
[09:03] <didrocks> ok
[09:07] <didrocks> sil2100: while I'm busy doing other things, do you mind landing friends?
[09:07] <didrocks> sil2100: no need for testing, it's just a Standards-Version bump
[09:08] <didrocks> (juts to clean the page)
[09:08] <sil2100> didrocks: any testing needed? ACK
[09:09] <sil2100> didrocks: done!
[09:09] <sil2100> AFK for a quick momen
[09:09] <sil2100> t
[09:10] <didrocks> Mirv: I added request #58, can you look and test that with psivaa?
[09:10] <didrocks> Mirv: divide the work as you wish, I think someone should take desktop, the other phone
[09:10] <didrocks> (the changelog sounds good)
[09:13] <Mirv> didrocks: ok!
[09:14] <psivaa> didrocks: Mirv: let me know either way
[09:14] <Mirv> didrocks: there's a blocker bug though since libusermetrics doesn't build, I filed a bug today
[09:15] <didrocks> Mirv: ok, please ping upstream as well so that they know of it
[09:15] <Mirv> but if excluding libusermetrics, then ok
[09:15] <didrocks> Mirv: and we can publish without that one
[09:15] <didrocks> yep ;)
[09:15] <Mirv> didrocks: I'm planning to, ted is not line yet
[09:16] <didrocks> ok ;)
[09:18] <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...
[09:18] <Mirv> my sentences suck today
[09:19] <psivaa> Mirv: ack will test the phone :)
[09:19] <Mirv> psivaa: thanks!
[09:19] <psivaa> yw :)
[09:37] <didrocks> sil2100: Mirv: lool: ok, found out why the customization project wasn't listed. (configuration branch was not refreshed). Should be fine now
[09:37] <didrocks> sil2100: please work on landing the customization one as well as discussed
[09:37] <didrocks> Mirv: ok, so I just branch qtsystems and review?
[09:40] <didrocks> Mirv: ah, we'll need a DEP5 format (so that we know if it's reported upstream) please
[09:40] <didrocks> ping me once done
[10:06] <lool> didrocks: why don't we just bzr pull the config regularly from jk?
[10:07] <didrocks> lool: jibel convinced me to not do it, but TBH, I don't see anything block it (on that side at least)
[10:08] <didrocks> lool: the whitelist still need to be manual (on snakefruit), but on magners, I think we could
[10:10] <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)
[10:11] <jibel> you're
[10:11] <didrocks> jibel: this is just about bzr pull on magners I guess
[10:11] <didrocks> not deploying the config I guess
[10:11] <jibel> if it is just a pull that's fine
[10:11] <didrocks> let's cronify that then
[10:11] <jibel> but at some point we talked about reconfiguring automatically
[10:12] <didrocks> (done)
[10:12] <didrocks> yeah
[10:13] <didrocks> for that we need to pull out of jenkins a bunch of stuff
[10:13] <didrocks> but I think this plan is now dead…
[10:15] <didrocks> sil2100: back?
[10:15] <lool> why don't we do that as part of starting the tasks or something?
[10:15] <lool> or just change the jobs to read from the config
[10:16] <lool> e.g. instead of a "complex" job definition, you just make a thin wrapper around config/$job-name
[10:16] <didrocks> lool: at first, we didn't want to rely on the config files, but yeah, it happens it's what needed now
[10:16] <didrocks> lool: but TBH, this is not something we can tackle on anymore before V1, we are pulled in a lot of other directions ;)
[10:21] <vila> didrocks: what's V1 here ?
[10:21] <vila> cu2d V1 ?
[10:21] <didrocks> vila: phone version 1?
[10:21] <vila> oh, bah, silly me
[10:21] <didrocks> :)
[10:24] <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 ;)
[10:30] <didrocks> sil2100: how was friends published? Did you check? I see everything in red on that stack
[10:30] <Mirv> didrocks: DEP5 added to qtsystems.
[10:30]  * vila catches up backlog
[10:31]  * cjwatson adds landing ask 123 for click 0.4.9
[10:31] <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
[10:34] <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)
[10:34] <didrocks> Mirv: sponsored, thanks!
[10:34] <Mirv> thanks!
[10:34] <cjwatson> didrocks: Should be entirely backward-compatible, though I'm reflashing now to run tests
[10:35] <didrocks> cjwatson: ok, feel free to upload once the tests are done (filing landing ID 60)
[10:35] <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)
[10:36] <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
[10:36] <didrocks> Mirv: yw ;)
[10:37] <cjwatson> didrocks: Oh, it won't affect that at all, but I'll run what tests I can find
[10:38] <didrocks> thanks ;)
[10:38] <didrocks> sil2100: also, have you disabled autopilot the other day for real? I see still some builds in the ppa
[10:39] <didrocks> seb128: mind merging back your changes to indicator-keyboard trunk please? ;)
[10:43] <seb128> didrocks, waiting for somebody to approve https://code.launchpad.net/~seb128/indicator-keyboard/saucy-manual-upload/+merge/188065 since friday...
[10:44] <seb128> didrocks, not sure why the CI didn't kick in again after I pushed the new revision though
[10:44] <didrocks> seb128: ah, you proposed that back, thanks! seems upstream isn't responsive then.
[10:44] <seb128> didrocks, well, I think they were waiting for CI
[10:44] <didrocks> seb128: what about kick in? it doesn't find the latest revision in the archive
[10:44] <didrocks> ah
[10:44] <didrocks> upstream merger
[10:44] <seb128> right
[10:44] <seb128> let's just approve it
[10:44] <didrocks> yeah
[10:44] <seb128> can you do that?
[10:44] <seb128> thanks ;-)
[10:45] <didrocks> done ;)
[10:45] <didrocks> thanks to you!
[11:01] <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)
[11:01] <didrocks> sil2100: also, it will be nice if you can evaluate the settings stack at the same time
[11:26] <sil2100> ACK
[11:27] <sil2100> didrocks: I published the friends stack, as when I was publishing the stack it was still waitonstacks
[11:28] <didrocks> sil2100: maybe try rerunning it?
[11:28] <didrocks> or restoring the .bak
[11:28] <sil2100> hmmm
[11:29] <sil2100> I wonder what happened
[11:30] <sil2100> cp: cannot stat `/var/lib/jenkins/cu2d/work/saucy/friends/*_friends-app.xml': No such file or directory
[11:31] <didrocks> sil2100: interesting, maybe you just got unlucky and published just after the stack was unlock?
[11:31] <didrocks> unlocked*
[11:34] <sil2100> didrocks: should I re-run the whole stack normally or just do a force publish again?
[11:34] <didrocks> sil2100: I think restore the previous .bak
[11:34] <didrocks> and then try publishing
[11:39] <didrocks> sil2100: better?
[11:40] <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
[11:40] <sil2100> didrocks: is it ok without those?
[11:40] <didrocks> sil2100: should be
[11:40] <didrocks> as long as you have the .project
[11:44] <sil2100> hmmm
[11:45] <sil2100> http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Friends/job/cu2d-friends-saucy-3.0publish/42/console
[11:45] <sil2100> I wonder whatsapp
[11:45] <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'
[11:45] <sil2100> Permissions look ok,
[11:47] <didrocks> sil2100: are you connected to mangers? I can't apparently
[11:47] <sil2100> didrocks: it takes around 1 minute to connect ;/
[11:47] <sil2100> So you need patience
[11:47] <sil2100> drwxrwxr-x+ 2 desktop-team jenkins 4096 Sep 29 21:23 lock
[11:48] <didrocks> oh
[11:48] <didrocks> you did cp
[11:48] <didrocks> why not mv?
[11:48] <didrocks> (or even cp -p :p)
[11:48] <sil2100> I did a mv of the old one, and then cp -a ;)
[11:48] <sil2100> Ok, so I'll do a mv then!
[11:49] <didrocks> weird, if you cp -a, desktop-team shouldn't be the owner
[11:49] <didrocks> so yeah, rm -r friends
[11:49] <didrocks> mv friends.bak friends
[11:49] <sil2100> cp -a friends.bak/ friends
[11:49] <sil2100> k ;)
[11:58] <didrocks> sil2100: so, we're good now?
[12:01] <sil2100> didrocks: with friends, yes! Waiting for misc to finish
[12:01] <didrocks> sil2100: ok, did you read about AP which seems to still be in the ppa and building?
[12:01] <didrocks> sil2100: did you forgot to deploy the backout on Friday?
[12:01] <didrocks> (I think we should remove it again and remove it)
[12:02] <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?)
[12:04] <sil2100> Aye aye! I was almost sure I was deploying *something*, but I guess I didn't!
[12:04] <sil2100> heh
[12:04] <sil2100> Maybe I redeployed the wrong branch
[12:07] <didrocks> maybe…
[12:10] <didrocks> Mirv: psivaa: how are the indicators tests looking?
[12:10] <Mirv> didrocks: argh! I just figured out you said 'changelog' looked fine, not the 'changes' (packaging changes) regarding indicators!
[12:11] <Mirv> didrocks: so published, a moment ago, but..
[12:11] <didrocks> oh?
[12:11] <didrocks> ok, let me look at the FS
[12:11] <Mirv> didrocks: so this's because the cu2d was read, and it didn't show the packaging changes under the publish stack
[12:11] <Mirv> s/read/red/
[12:11] <didrocks> Mirv: yeah, there is a trick for that
[12:11] <didrocks> (foo + AUTO_PUBLICATION)
[12:11] <didrocks> Mirv: it was red because of the tests?
[12:11] <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
[12:12] <didrocks> ok, let me look :)
[12:12] <Mirv> didrocks: red because of libusermetrics build failure. I did autopilot locally and so did psivaa
[12:12] <didrocks> ah ok ;)
[12:13] <didrocks> Mirv: ok, it seems to be the same thing everytime, so yeah, looking good
[12:15] <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.
[12:17] <lool> ralsina: around?
[12:17] <didrocks> Mirv: yeah, this one is really tricky ;)
[12:17] <Mirv> didrocks: "do no use manually" says the hint for that :)
[12:17] <didrocks> Mirv: when you run it, ensure that the stack is not running at all
[12:17] <didrocks> there is no safety net
[12:17] <didrocks> hence this "do not use manually" :p
[12:18] <ralsina> lool: here, good morning!
[12:18] <lool> ralsina: good morning!
[12:18] <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
[12:18] <Mirv> right. I tend to not to ever do anything if stack is running anyhow (or stop it before).
[12:19] <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?
[12:19] <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"
[12:19] <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
[12:20] <ralsina> lool: well, to test for updates, we are installing some old clicks via pkcon then checking
[12:20] <lool> can I download old clicks from somewhere?
[12:20] <ralsina> lool: we have a few, let me get you the URLs
[12:21] <lool> thanks
[12:21] <lool> one is enough I guess
[12:21] <lool> small  :-)
[12:21] <ralsina> lool: there is a copy of old hello world somewhere, gatox is loking for it
[12:22] <gatox> lool, hi, ralsina asked me to give you this old clicks: http://ubuntuone.com/0mHE7D9wQLkd2DXBJROxTi - http://ubuntuone.com/3KnGeEQjvt9nXul0JLLDew
[12:23] <lool> gatox: ty
[12:24] <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?)
[12:25] <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
[12:28] <sil2100> didrocks: eh, it seems cordova-doc build is hanged ;/
[12:28] <sil2100> didrocks: "Started 6 hours ago"
[12:28] <sil2100> didrocks: and it doesn't move at all
[12:28] <sil2100> I'll abort it maybe?
[12:28] <sil2100> Ok, no, wait, it moves
[12:29] <sil2100> But why 6 hours?
[12:31] <Laney> Can someone make the CI re-run on https://code.launchpad.net/~laney/ubuntu-system-settings/measure-size-critical-fix/+merge/188020 ?
[12:32] <lool> mandel: looking
[12:32] <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
[12:33] <lool> Laney: done
[12:33] <Laney> merci
[12:34] <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)
[12:36] <cjwatson> sil2100: (if this didn't get resolved while my connection was bouncing)  Have you checked that the logtail isn't progressing?
[12:37] <lool> mandel: hmm looking at the diff, I'm not too convinced with the file handling stuff
[12:37] <cjwatson> sil2100: In fact, it looks like the logtail *is* progressing, so it's not huge, just slow due to png compression
[12:37] <cjwatson> *not hung
[12:37] <mandel> lool, what worries you?
[12:37] <lool> mandel: that the download service itself is running unconfined and writing to computed pathnames
[12:38] <lool> like appending an id at the end of a filename to create a new one
[12:38] <sil2100> cjwatson: as I mentioned: "Ok, no, wait, it moves", but I wonder why it takes 6 hours already
[12:38] <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
[12:38] <sil2100> cjwatson: since damn, it's i386, 6 hours for one package is a LOT
[12:39] <cjwatson> sil2100: png compression can be enormously slow on systems with lots of pngs
[12:39] <cjwatson> unfortunately
[12:39] <cjwatson> s/systems/packages/
[12:39] <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)
[12:39] <sil2100> cjwatson: thanks
[12:40] <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
[12:40] <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?
[12:40] <cjwatson> e.g. override_dh_builddeb:\n\tNO_PNG_PKG_MANGLE=1 dh_builddeb
[12:42] <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
[12:42] <lool> we need to ask security team about apparmor profiles anyway
[12:43] <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
[12:43] <mandel> lool, what is wrong with that?
[12:43] <mandel> lool, then, I think we should land that branch
[12:50] <lool> mandel: the symlink part was that it would write the download to ~/.upstart/my-job.conf for an unconfined app
[12:50] <mandel> lool, we can always return an error if the file is present
[12:51] <mandel> lool, and let app developers deal with it
[12:51] <lool> mandel: right; you need to do the write in a secure way, race free
[12:51] <mandel> lool, can you add a comment and I'll update the branch so that if present, we raise an exception
[12:51] <lool> mandel: typically if(!exists(file)) {write(file)} is racy
[12:52] <mandel> lool, I fear that the click scope is not cleaning the files and that will break it :-/
[12:52] <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
[12:52] <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
[12:52] <fginther> morning
[12:52] <lool> will log a bug
[12:52] <mandel> lool, thx
[12:52] <lool> mandel: let's land your fix though
[12:53] <mandel> lool, ok, I'll pay attention to that, we need to ask security, I'd like their input for this
[12:54] <lool> mandel: it's non-trivial to get it right, e.g. that applies when creating the download directory too
[12:54] <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
[12:55] <mandel> cjwatson, yeah, that is an issue, both in the downloader and the scope, that branch fixes it just changing the downloader side
[12:55] <lool> mandel: https://bugs.launchpad.net/ubuntu-download-manager/+bug/1233149
[12:55] <mandel> lool, thx
[12:55]  * mandel goes to have some food
[12:58] <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  ;-)
[12:58] <lool> my only problem is that I'm falling asleep
[13:07] <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!  :-)
[13:07] <ralsina> lool: approved, mandel forgot to do it after it was agreed to land it
[13:09] <cwayne> asac: ping
[13:09] <cjwatson> cwayne: He's on holiday
[13:10] <cwayne> cjwatson: ah, thanks.. a  /nick asac-holiday could've been helpful :)
[13:10] <cwayne> didrocks: ping
[13:13] <sil2100> ogra_: hi! Do you have a moment ;)?
[13:14] <ogra_> sil2100, shoot
[13:14] <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
[13:16] <cjwatson> sil2100: ack on the first, nack on the second
[13:16] <cjwatson> sil2100: Shouldn't be "Section: debug"
[13:16] <cjwatson> Hah, other packages are like that, but it's still wrong :)
[13:16] <ogra_> thanks for checking cjwatson ... i seem to not be able to reach that machine
[13:17] <sil2100> cjwatson: will you give a conditional ACK if I promise to prepare a merge for changing that? ;)
[13:18] <cjwatson> sil2100: I'd suggest just deleting the Section: line
[13:18] <cjwatson> sil2100: I'm just checking some context for the rest of it
[13:19] <cjwatson> sil2100: Surely you need to handle dh_python2/dh_python3 integration too?
[13:19] <cjwatson> sil2100: It's not generally OK to just dump files into /usr/lib/python*/dist-packages/ without the use of any Python helper
[13:21] <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
[13:21] <sil2100> cjwatson: ;)
[13:21] <cjwatson> I'm afraid that doesn't convince me to ack it
[13:22] <sil2100> cjwatson: I'm not the one doing the packaging here
[13:22] <cjwatson> sil2100: I think you basically need (a) Build-Depends: python (>= 2.7); (b) dh $@ --with=python2; (c) add ${python:Depends} to Depends
[13:22] <cjwatson> That still doesn't convince me to ack it :)
[13:22] <cjwatson> You aren't going to convine me to ack something incorrect
[13:22] <cjwatson> *convince
[13:22] <sil2100> cjwatson: ok then, I'll wait for didrocks to decide on what to do with this release
[13:22] <sil2100> cjwatson: then why didn't the release team reject all the other packages if they are incorrect?
[13:22] <cjwatson> The above sequence should be basically all you need, simple enough
[13:22] <cjwatson> sil2100: I didn't see them :-P
[13:22] <sil2100> cjwatson: right
[13:23] <ogra_> the wonderful world of auto-approval
[13:23] <sil2100> didrocks: ping, the settings stack is blocked for now, see ^ for context
[13:24] <cjwatson> Might also need "X-Python-Version: 2.7" since autopilot.pro hardcodes 2.7
[13:24] <cjwatson> In which case Build-Depends: python (>= 2.6.6-3~) is actually more correct
[13:25] <cjwatson> Given that this is a five-minute build, this should take about ten minutes to fix
[13:26] <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
[13:26] <cjwatson> (As in, the packages will probably vanish from the primary archive)
[13:28] <cjwatson> Oh good grief, all *-dbg are in debug.  I wonder if I misunderstood that section ...
[13:28] <cjwatson> Looks like I did.  Hmm.
[13:30] <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
[13:35] <didrocks> lool: ack
[13:35] <didrocks> sil2100: cordova-doc: please abort I guess
[13:36] <didrocks> sil2100: oh, no, it doesn't. Hum, the build seems very long
[13:36] <didrocks> sil2100: so, let's try to release it so that we don't have it again
[13:37] <sil2100> didrocks: so we should wait for it to finish? (7 hours running already)
[13:38] <didrocks> sil2100: yeah, and then, we ensure it's in
[13:38] <sil2100> ACK
[13:40] <didrocks> sil2100: keeping a look on that?
[13:41] <sil2100> didrocks: I'll keep a tab opened, hope it will finish building till the end of the day!
[13:43] <didrocks> sil2100: cjwatson: we have examples in other packages how we handle building with python
[13:43] <didrocks> sil2100: look at unity8 (debian/rules)
[13:43] <didrocks> sil2100: so I doubt 90% of the packages are doing that, for those I looked at least…
[13:44] <cjwatson> I'm preparing a patch for friends-app now by way of example
[13:44] <sil2100> didrocks: well, notes-app, gallery-app, friends-app
[13:44] <sil2100> didrocks: messaging-app as well
[13:44] <cjwatson> And yeah, unity8 is better
[13:44] <sil2100> didrocks: I would say that all *-app packages that we daily release have that
[13:44] <cjwatson> So let's fix them and not get it wrong in new code
[13:45] <sil2100> didrocks: so it's no wonder someone added the autopilot packaging in the same way
[13:45] <cjwatson> Like I say, it's really not hard, I'm preparing a patch that people can crib from
[13:45] <didrocks> sil2100: yeah, same issues than autotools…
[13:46] <didrocks> cjwatson: +1
[13:48] <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
[13:49] <didrocks> sil2100: for unity8, I've implemented a setup.py upstream for this
[13:49] <cjwatson> Not using setup.py is also weird, but it wasn't what I commented on.
[13:51] <cjwatson> sil2100: https://code.launchpad.net/~cjwatson/friends-app/dh-python2/+merge/188338 - shouldn't be harder than that for the others
[13:51] <cjwatson> (Of course some other core dev should probably eyeball that)
[13:53] <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)
[13:55] <seb128> sil2100, https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.0.2+dfsg1-7ubuntu5 is what you remember
[13:56] <sil2100> seb128: thanks! heh, something similar was echoing in my ears and I couldn't differentiate it from the noise
[14:01] <Laney> Is there a hidden point to the libfriends upload that just bumps standards-version?
[14:04] <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?
[14:04] <cjwatson> sil2100: Yes, it is valid.  Some details of it were only fixed up in the last few months
[14:05] <sil2100> cjwatson: I get a lintian error on your branch - is that normal?
[14:05] <sil2100> cjwatson: E: friends-app source: missing-build-dependency-for-dh-addon python2 => python | python-all | python-dev | python-all-dev
[14:05] <retoaded> fginther, let me poke but it may be related to me changing the DHS/DHCP services for those networks.
[14:05] <cjwatson> Er, by which I mean "two weeks ago"
[14:05] <cjwatson> sil2100: Yes, that's Lintian being out of date and can be ignored
[14:07] <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
[14:07] <cjwatson> sil2100: But python is Multi-Arch: allowed, and is indeed the canonical example of this kind of dependency
[14:07] <cjwatson> We have quite a few of these in the archive now
[14:15] <sil2100> ACK, awesome
[14:22] <sil2100> cjwatson: https://code.launchpad.net/~sil2100/ubuntu-system-settings-online-accounts/dh_python2/+merge/188340 <- is the same change ok here?
[14:24] <cjwatson> sil2100: Yep, looks fine
[14:24] <cjwatson> sil2100: That has my ack with that merge
[14:24] <sil2100> cjwatson: thanks
[14:25] <cwayne> mfisch: next day or two according to pete-woods
[14:28]  * cjwatson sees that security has taken over the build farm for a while
[14:28] <lool> == Building click-package stack ==
[14:28] <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 :)
[14:28] <cjwatson> Uploaded click 0.4.9
[14:28] <lool> to pick up the ubuntu-download-manager rev that got merged a couple of minutes after the tick
[14:28] <didrocks> great ;)
[14:28] <ralsina> mandel: I top-approved it anyway
[14:29] <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
[14:30] <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)
[14:33] <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
[14:35] <didrocks> sil2100: apart from that, testing the settings went ok? so you can publish them both once rebuilt?
[14:35] <didrocks> sil2100: also, I feel cordova-docs is *almost* merged ;)
[14:35] <didrocks> built*
[14:36] <didrocks> sil2100: also, the customization hooks have progressed?
[14:36] <didrocks> (not sure if you followed, but I got why it didn't show up this morning)
[14:37] <sil2100> didrocks: testing went fine, ran the AP tests on the device as well, but some of the tests are actually desktop-only
[14:37] <sil2100> didrocks: did some dogfooding, all green
[14:37] <cjwatson> Yeah, cordova-docs is built now
[14:38] <didrocks> sil2100: please publish whatever you can, will be helpful before the meeting to know what's still needed for image 71
[14:38] <cjwatson> I think I'll rebalance the i386/amd64 builders back to 4/4, since there's a bit of a queue
[14:39] <cwayne> didrocks: the customization hooks were updated last week but haven't landed yet
[14:39] <cjwatson> 10 pending amd64 builds
[14:39] <didrocks> cwayne: yeah, we are working on publishing it
[14:39] <cwayne> didrocks: cool, thanks. just saw customization-hooks and figured i'd give some context :)
[14:40] <sil2100> didrocks: will rebuild settings once my merge gets in
[14:40] <didrocks> cwayne: yeah, no worry, thanks for following! :)
[14:41] <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)
[14:41] <sil2100> didrocks: I can tackle ubuntu-touch-customization-hooks now, any additional tests that need to be ran for that?
[14:42] <bfiller> fginther: we are quite blocked by otto autopilot failures on multiple MR's
[14:42] <didrocks> sil2100: I don't think there is any TBH
[14:42] <didrocks> sil2100: did you fix AP trunk btw?
[14:42] <didrocks> sil2100: I mean, removed from the ppa and deployed the removal?
[14:43] <bfiller> fginther: sounds like you and omer are discussing a plan but we need this fixed asap. have a ton of stuff to land
[14:43] <sil2100> didrocks: by fix you mean, removed? Yes
[14:43] <sil2100> didrocks: it's removed from the PPA and disabled in the stack
[14:43] <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
[14:43] <didrocks> sil2100: thanks a lot man :)
[14:43] <bfiller> fginther: sounds good, can we do that now?
[14:43] <didrocks> fginther: what's the issue?
[14:43] <sil2100> didrocks: I'll publish misc - checking what components are in ;)
[14:44] <didrocks> great!
[14:44] <fginther> bfiller, yes, trying to, unfortunately there is a network issue blocking everything else at the moment
[14:44] <fginther> bfiller, but will update the jobs as soon as possible
[14:44] <fginther> didrocks, it looks like tab switching is unreliable - https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1232857
[14:45] <sil2100> didrocks: juust... cordova-docs is still pending publication ;/
[14:45] <bfiller> fginther: thanks
[14:45] <didrocks> sil2100: yeah, do the customization stuff and you can switch on that one just after I guess
[14:45] <didrocks> then 2 down!
[14:46] <didrocks> fginther: which autopilot version are you using?
[14:47] <fginther> didrocks, 1.3.1+13.10.20130930-0ubuntu1
[14:49] <didrocks> fginther: where are you taking it?
[14:49] <didrocks> fginther: it's been multiple days we have issues with AP in daily-build ppa FYI
[14:49] <didrocks> so it's now removed
[14:49] <didrocks> please retry before disabling (now that this version is removed)
[14:49] <fginther> didrocks, yes, that's from the ppa
[14:49] <fginther> didrocks, will give it a fresh try
[14:50] <didrocks> fginther: please keep me posted
[14:50] <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
[14:50] <didrocks> bfiller: "fix for flaky autopilot tests", really really really? \o/
[14:51] <didrocks> lool: ok, you did run the mediaplayer-app AP tests?
[14:51] <didrocks> lool: not sure if it's using unity8 to test scope activation
[14:52] <sil2100> didrocks: is cordova-docs preNEWed?
[14:52] <didrocks> sil2100: I think I did, let me look again at it
[14:52] <didrocks> (looking at the last commits)
[14:52] <sil2100> didrocks: if yes, then I'll publish it along with ubuntu-touch-customization-hooks now ;)
[14:53] <didrocks> sil2100: my requested change is in, so +1
[14:53] <didrocks> sil2100: refreshed the whitelist as well
[14:59] <bfiller> didrocks: indeed!
[14:59] <didrocks> bfiller: you will get in front of the queue for image 72 I guess :p
[14:59] <didrocks> bfiller: will release the ubuntu-keyboard back (we just fixed trunk with mismatch in the archive)
[15:00] <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
[15:00] <lool> bfiller: (did you see my bug about mediaplayer AP tests?  ;-)
[15:00] <bfiller> didrocks: thanks
[15:00] <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
[15:01] <bfiller> lool: we supposedly skipped the tests for scenne selector, let me check with renato
[15:01] <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
[15:02] <didrocks> lool: ok, ack then
[15:02] <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
[15:03] <bfiller> lool: what environment did the tests fail on?
[15:03] <lool> bfiller: upstream merger
[15:04] <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
[15:04] <lool> bfiller: I don't know, I think there's a link in the bug
[15:04] <didrocks> bfiller: TBH, I think you are getting AP issues, not VM issues (but let's see if Francis confirms)
[15:05] <lool> right, there's a link thre
[15:05] <lool> so I wanted to play with click stack, but download-manager didn't build on amd64 yet
[15:06] <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
[15:06] <cjwatson> 15:39 <cjwatson> 10 pending amd64 builds
[15:06] <cjwatson> lool: ^-
[15:06] <bfiller> loo, didrocks : I think this is the same problem that is preventing many of our MR's from landing on different apps
[15:06] <bfiller> lool: ^^
[15:06] <bfiller> lool: can you run the test on a device? I bet it will work fine
[15:07] <lool> cjwatson: thanks
[15:08] <lool> bfiller: not right now
[15:08] <lool> bfiller: will try later, if you beat me just say so in the bug report and close it
[15:08] <lool> bfiller: and poke fginther about it I guess :-)
[15:10] <lool> bfiller: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4470/mediaplayer-app-autopilot/ seems to back your analysis though
[15:10]  * didrocks will bet on AP trunk
[15:11] <sil2100> didrocks: *sigh* my settings merge got rejected by jenkins
[15:11] <sil2100> A unit test failure ;/
[15:11] <lool> didrocks: so I just set FORCE_PUBLICATION, nothing else, and rebuild with renamed .project files?
[15:12] <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
[15:12] <fginther> lool, bfiller, those failed tests were on the hardware env
[15:12] <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_/
[15:12] <didrocks> lool: FORCE_PUBLICATION, then once in, rename the .project file, and rebuild with "foo" to recreate the state
[15:12] <didrocks> sil2100: argh, can you get some help upstream?
[15:13] <lool> didrocks: Gah, getting this http://10.97.0.1:8080/job/autopilot-saucy-daily_release/2236/
[15:13] <lool> didrocks: seems like the same issue as upstream merger
[15:13] <lool> bfiller: ^
[15:14] <lool> so real failures
[15:14] <didrocks> cjwatson: lool: AP is the one in the archive, so different
[15:15] <lool> MismatchError: After 10.0 seconds test on SceneSelector.opacity failed: 1 != dbus.Double(0.0, variant_level=1)
[15:15] <lool> this is definitely one of the bogus tests I intend to ignore
[15:15] <lool> ok, forcing this one through
[15:16] <didrocks> (I mean, it's not AP trunk's fault like what we saw somewhere else)
[15:17] <lool> pushed mediaplayer-app, rebuilding media stack with "foo"
[15:18] <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
[15:20] <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.
[15:21] <fginther> retoaded, do we need to reboot ps-android-sandybridge also?
[15:22] <rfowler> fginther: i just rebooted it 1/2 hour ago
[15:23] <didrocks> bfiller: do you mind expanding the "use qml bindings for infographics"?
[15:24] <didrocks> bfiller: like, is there any bug report?
[15:24] <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.
[15:24] <bfiller> didrocks: done
[15:24] <fginther> retoaded, ack
[15:24] <bfiller> no bug report, just apps are supposed to use new api
[15:24] <bfiller> which is qml
[15:24] <didrocks> bfiller: ok, sounds good, thanks ;)
[15:25] <bfiller> np
[15:25] <doanac> asac: is there anything i can do to help get autopilot unblocked from the landing-pipeline?
[15:26] <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.
[15:26] <didrocks> doanac: asac is on vacations
[15:26] <retoaded> It will be time consuming but will get done.
[15:26] <didrocks> doanac: right now, from our tests, AP trunk regressed all apps + unity8 tests
[15:27] <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
[15:27] <didrocks> (and then fixing ;))
[15:27] <doanac> didrocks: interesting. i'm not sure AP had any functional code changes.
[15:27] <ogra_> sergiusens, ^^^
[15:28] <didrocks> doanac: it seems that it regressed one way or another (multiple confirmation by sil2100 and Saviq)
[15:28] <didrocks> doanac: we don't really know more though, had to go back on prod side :/
[15:30] <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
[15:30] <sergiusens> didrocks, ^^
[15:30] <doanac> sergiusens: there are more changes that have queued up now
[15:30] <sergiusens> doanac, that sucks, can we daily release with only our change?
[15:31] <didrocks> sergiusens: doanac: quite a lot: https://code.launchpad.net/~autopilot/autopilot/1.3
[15:33] <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 ?
[15:34] <didrocks> sergiusens: hum, this is getting complicated, can't we work with thomi to get the issues fixed?
[15:34] <didrocks> sergiusens: because ensuring AP doesn't regress is taking 2 hours, I will rather fix the real version
[15:34] <didrocks> sergiusens: when/why do you need that right now?
[15:34] <didrocks> (just trying to assess)
[15:35] <sergiusens> didrocks, it's blocking click package testing for two weeks now
[15:35] <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
[15:38] <sergiusens> doanac, we can always side fix this and put the hook in phablet-config and make the hooks rerun with a tmpdir
[15:39] <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
[15:41] <sergiusens> doanac, great, I'll look into it
[15:48] <Laney> can someone please retry https://code.launchpad.net/~mterry/unity8/statsWelcomeScreen/+merge/184153 too? The failures all look transient to me
[15:50] <Laney> Alternatively tell me if me clicking on the rebuild link actually works
[15:50] <Laney> :-)
[15:53] <sergiusens> Laney, rebuild works if logged in to jenkins behind the firewalls
[15:53] <Laney> oh, probably not then
[15:53] <Laney> I have no account there afaik
[15:54] <sergiusens> Laney, look at what's on the MR (latest comment)
[15:54] <Laney> sergiusens: how timely
[15:54] <sergiusens> yeah
[15:54] <Laney> the CI was still busted :P
[15:55] <sergiusens> doanac, saw your email, will look at it after a quick bite
[16:00]  * lool waits for click 0.4.9 to be on ports
[16:02] <didrocks> robru: around?
[16:02] <didrocks> https://plus.google.com/hangouts/_/76bca9c02d41106488aa07d8aae1b40d8b6d09a4
[16:02] <robru> didrocks, yep, just up
[16:04] <fginther> Laney, looking
[16:05] <Laney> fginther: mterry pushed another commit, probably will kick itself off now
[16:05] <fginther> Laney, ack
[16:09] <ogra_> rsalveti, will we get the last bits of the media stack over night ?
[16:10] <rsalveti> ogra_: we hope so, in a few hours actually
[16:10] <ogra_> ok
[16:10] <rsalveti> we can dream, right?
[16:10] <ogra_> haha
[16:10] <ogra_> yeah
[16:10] <ogra_> didrocks, ^^^
[16:15] <didrocks> \o/
[16:24] <fginther> sil2100, https://code.launchpad.net/~fginther/cupstream2distro-config/add-thumbnailer/+merge/188383
[16:24] <fginther> sil2100, adds the thumbnailer which was just discussed
[16:28] <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?
[16:28] <lool> robru: we're going to spin 71 and 72 immediately thereafter, then you can land stuff if you like
[16:28] <lool> but need some testing before we can spin 71
[16:28] <lool> and my phone is just screwed, gah, will take some time to fix
[16:28] <robru> lool, hmm, didrocks has assigned me to land a few things for 72 ;-)
[16:29] <didrocks> robru: yeah, try to land as much as you can for 72 (there are quite small things)
[16:29] <lool> didrocks: for 73 I guess
[16:29] <didrocks> robru: we can retarget for 73 if you don't finish them for 72
[16:29] <lool> didrocks: where should we state the system-image .debs to test?
[16:29] <robru> didrocks, ok, no worries then. I will begin landing now and if they land for 72 or not is fine
[16:29] <lool> didrocks: I was thinking a block hint on it, + upload to -proposed would be in order, what do you think?
[16:30] <lool> or we can do PPA
[16:30] <didrocks> robru: looks good, maybe some stacks will need for rebuilding (like the apps one I guess)
[16:30] <didrocks> lool: PPA maybe? It's not that long to build
[16:31] <robru> didrocks, ugggggh, 79 test failures in app stack... fun
[16:31] <lool> didrocks: with a ~ppa?
[16:31] <lool> didrocks: slangasek can't participate in much system-image testing right now due to a power outage taking his wireless down
[16:32] <didrocks> robru: yeah, please relaunch, the autopilot in the ppa was busted
[16:32] <didrocks> lool: yeah, ~ppa
[16:32] <didrocks> lool: argh, of course
[16:33] <lool> ogra_, didrocks: Sorry will take me a while to test because I have to reflash; should be 10-15mn from now
[16:34] <ogra_> lool, no hurry
[16:34] <didrocks> lool: this gives time for robru ;)
[16:41] <robru> didrocks, ok, i believe everything that has been asked of me is building... now we wait ;-) (err, read emails while waiting... :-)
[16:41] <didrocks> robru: heh, thanks!
[16:50] <didrocks> robru: do I miss anything? (I answered you by email)
[16:51] <robru> didrocks, no, just miscommunication. it's fine i guess
[16:51] <didrocks> robru: ah nice ;)
[16:53] <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)
[16:54] <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
[16:54] <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?
[16:54] <lool> cjwatson: I mean, there is no /opt/click.u.c/.click in the image
[16:55] <didrocks> robru: I guess indicator juts has nothing to build :)
[16:55] <didrocks> and then publish
[16:55] <didrocks> hum, no
[16:55] <robru> didrocks, hummm, the latest commit from lp:indicator-keyboard did not show up in daily release ppa
[16:55] <didrocks> there is this libubermetric
[16:56] <cjwatson> lool: Huh, no, shouldn't be
[16:56] <didrocks> robru: I think that Mirv messed with the file system maybe there is something wrong
[16:56] <didrocks> let me look
[16:56] <cjwatson> lool: Different traceback, I assume?
[16:56] <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)?
[16:57] <lool> cjwatson: yes, permission denied
[16:57] <didrocks> robru: in fact the stack is running
[16:57] <lool> cjwatson: can't remove it even after installing other clicks
[16:57] <cjwatson> lool: Oh, sorry, that's a new bug
[16:58] <didrocks> robru: however, 64 is a typo of mine
[16:58] <robru> didrocks, yes, i just re-ran it now myself
[16:58] <didrocks> robru: it's not indicator-keyboard, but ubuntu-keyboard
[16:58] <didrocks> (fixed the spreadsheet)
[16:58] <robru> didrocks, oh
[16:58] <didrocks> sorry about that
[16:58] <didrocks> just autotyping ;)
[16:59] <didrocks> robru: it seems you are already rerunning the services stack
[16:59] <robru> didrocks, i just did now that you told me to :-P
[16:59] <didrocks> robru: ahah, you're fast :p
[16:59] <cjwatson> lool: bah, right, <- idiot
[16:59] <cjwatson> lool: can I upload a new click version that fixes just this?
[16:59] <lool> cjwatson: yes please  :-)
[17:00] <didrocks> ogra_: you will need to track that one before image 71 ^
[17:00] <lool> didrocks ogra_: ^ I think this regresses removals, so waiting on this one for the image
[17:00] <didrocks> lool: no worry!
[17:00] <lool> ogra_, didrocks: Going for dinner
[17:00] <didrocks> lool: enjoy
[17:00] <cjwatson> lool: it'll be http://paste.ubuntu.com/6176317/
[17:00] <cjwatson> after testing
[17:00] <lool> cjwatson: ok
[17:00] <cjwatson> (that's hard to read but it's mostly indentation changes - http://paste.ubuntu.com/6176321/ with diff -b)
[17:01] <lool> it looked like it was either something like that, or another syscall ld_preload thing for removals, glad it's the former  :-)
[17:01]  * ogra_ is happy to wait ... not on a race :)
[17:02] <lool> wow getting an update in update manager
[17:02] <cjwatson> Yep, that works
[17:02] <cjwatson> lool: It's not a regression, I might note - I just didn't fix bug 1232066 hard enough in the last upload
[17:02] <cjwatson> lool: Oh, actually, you're right, it is a regression
[17:03] <cjwatson> Maybe
[17:03] <cjwatson> lool: Do you get the same traceback after installing other click packages?
[17:04] <lool> cjwatson: can't easily tell
[17:04] <lool> getting a pkcon error
[17:04] <cjwatson> lool: You have a traceback in the bug though
[17:04] <cjwatson> So try   pkcon remove 'com.ubuntu.sudoku;0.4.3;all;local:click'
[17:05] <cjwatson> And then paste the traceback from that
[17:10] <cjwatson> lool: ... any luck?  I have a fix, just would like to make sure I fully understand what's going wrong for you
[17:11] <cjwatson> Oh, he said he was going for dinner.  I'll just upload then since it WFM
[17:13] <cjwatson> lool: click 0.4.10 uploaded
[17:13] <lool> cjwatson: just back from dinner
[17:14] <cjwatson> You eat quickly
[17:14] <lool> just a plate of spaghettis with bolognaisa
[17:14] <lool> sorry, bolognase I guess
[17:14] <lool> cjwatson: pkcon remove 'com.ubuntu.sudoku;0.4.3;all;local:click' worked
[17:16] <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
[17:17] <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#
[17:18] <bfiller> fginther|lunch: please give me an update when these can be unblocked.
[17:18] <lool> cjwatson: is it enough to rm -rf /opt/click.ubuntu.com/{*,.*} to get to the same state as a fresh image?
[17:18] <lool> ogra_: will promote click-package stack
[17:19] <lool> ogra_: Actually we can probably do better than what I had proposed for system-image
[17:19] <cjwatson> lool: Might leave cruft around from hooks
[17:19] <cjwatson> lool: Assuming correctly-written hooks, it should be OK if you reboot after doing that
[17:19] <lool> ogra_: a) build now, b) upload system-image, c) build, d) build
[17:19] <lool> test from c) to d)
[17:19] <cjwatson> (Which has the effect of rerunning hooks)
[17:19] <lool> ok
[17:19] <cjwatson> lool: But
[17:19] <lool> there is always a butt
[17:19] <cjwatson> lool: Don't run the command you quoted!
[17:19] <cjwatson> lool: .* expands to include ..
[17:20] <lool> erf, ok, it was just for IRC
[17:20] <cjwatson> rm -rf /opt/click.ubuntu.com/{*,.click}
[17:21] <lool> interesting, zsh is being slightly more helpful than bash here in expanding .* to things starting with .
[17:22] <lool> cjwatson: bah, unapproved
[17:23] <lool> desktop seed
[17:23] <lool> via pk plugin I guess
[17:35] <lool> (click 0.4.10 approved by Stéphane)
[17:44] <robru> lool, do we care about libusermetrics for today's images? i can't get it to build, don't understand the failure.
[17:45] <ogra_> robru, make the committer fix it
[17:45] <ogra_> and set it back to TODO
[17:45] <robru> ogra_, yeah, there's already a bug
[17:45] <ogra_> if it is broken it is broken ...
[17:51] <lool> robru: isn't that already in the image?
[17:51] <lool> robru: what's the issue?
[17:51] <robru> lool, https://bugs.launchpad.net/libusermetrics/+bug/1233003
[17:51] <robru> lool, there is an old one in the image. i'm  just asking if it's important to get it in
[17:52] <lool> The following tests FAILED: 4 - usermetricsoutput-unit-tests (Failed)
[17:52] <lool> robru: it's not particularly important
[17:52] <robru> lool, ok, then i'll focus on other things ;-)
[17:53] <lool> robru: it looks like the issue are that some tests trigger valgrind errors
[17:53] <robru> lool, i don't know the first thing about valgrind. maybe you can work with pete-woods on resolving that? ;-)
[17:53] <lool> robru: just point him at the failure log on i386
[17:54] <robru> lool, well, he marked the bug as fixed even though it's not fixed, so...
[17:54] <lool> cjwatson: new click is all fine, thanks
[17:57] <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
[17:58] <ogra_> phablet-flash ubuntu-system --channel saucy --no-backup
[17:58] <robru> ogra_, thanks
[17:58] <ogra_> (--no-backup is the "wipe" command)
[17:58] <robru> ogra_, ah, it didn't show up in 'phablet-flash -h'
[17:59] <ogra_> yeah, would be in phablet-flash ubuntu-system -h
[17:59] <lool> you need the actual command to see all the --help options
[17:59] <robru> ahhhh
[18:06] <sil2100> fginther: ping!
[18:07] <fginther> sil2100, hello
[18:07] <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? :)
[18:07] <sil2100> fginther: thanks!
[18:12] <fginther> sil2100, approved
[18:12] <sil2100> fginther: awesome! *hugs*
[18:13] <sil2100> See you tomorrow guys
[18:13] <fginther> sil2100, later
[18:20] <lool> ogra_: Ok, gtg; could you check for click 0.4.10 to be in saucy in rmadison then build an image ?
[18:20] <ogra_> indeed
[18:20] <lool> ogra_: ty!
[18:32] <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
[18:39] <robru> similar situation with mediaplayer_app AP tests holding back camera-app release.
[18:41] <ogra_> build 71 running
[18:44] <ogra_> robru, sorry, i have not much clue about the CI infrastructure, cant give you a hint here
[18:45] <robru> ogra_, ok, well then I have no choice but to not release this then. bug has been filed, will ping appropriate upstreams shortly.
[18:46] <ogra_> probably lool can help later
[18:46] <ogra_> he said he'd be back
[18:47] <robru> ogra_, let me know when image 72 is done, i'll help test the image upgrades too
[18:47] <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.
[18:47] <fginther> bfiller, will retrigger recent failing jobs
[18:48] <ogra_> robru, yeah, thats still hours away
[18:48] <robru> ogra_, ok, great. I EOD in 6 hours ;-)
[18:51] <robru> fginther, do you think that'll help with mediaplayer-app, as well? https://bugs.launchpad.net/mediaplayer-app/+bug/1231418
[18:56] <fginther> robru, nope, that test was already executed with the autopilot 1.3.1+13.10.20130918-0ubuntu1
[18:56] <robru> buh. ok thx
[19:23] <bfiller> fginther: please retrigger all the MR's found in that sheet
[19:23] <fginther> bfiller, ack
[19:46] <cjwatson> lool: new click> great
[19:51] <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!!!
[19:51] <kgunn> its been damn smooth ever since
[19:51] <fginther> kgunn, you're welcome. I was I could have similar results for eveything else
[19:52] <kgunn> ;)
[19:53] <cjwatson> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-saucy-amd64/70/console is transient.  Can somebody please retry?
[19:53] <cjwatson> (from https://code.launchpad.net/~cjwatson/friends-app/dh-python2/+merge/188338)
[19:57] <fginther> cjwatson, on it
[19:58] <cjwatson> thanks
[20:00] <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
[20:01] <cjwatson> robru: that happens occasionally even on the primary archive build daemons due to bad timing
[20:01] <cjwatson> it's a "try again" thing
[20:01] <robru> cjwatson, ok, will do
[20:01] <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
[20:01] <robru> heh, fginther beat me to it
[20:02] <fginther> cjwatson, curious, would it be safe if the job itself immediately did a retry of the apt-get operation?
[20:02] <cjwatson> and even worse for PPAs
[20:02] <robru> cjwatson, what do you mean by 'cycle'? are you just referring to the churn of updated packages?
[20:02] <cjwatson> fginther: probably, yes, but you would want to do that only on certain types of failures and have a limit to avoid infloop
[20:02] <cjwatson> robru: I mean each publisher run
[20:02] <fginther> cjwatson, I would likely cap it at 3-5 retries
[20:02] <robru> ah
[20:03] <cjwatson> the indexes for a given archive are unfortunately spread over multiple files so it's possible to get an inconsistent view
[20:03] <cjwatson> we've talked about fixing it, but time ...
[20:04] <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...
[20:04] <cjwatson> fginther: the PPA publisher runs every 10 minutes or so in practice if there are changes
[20:05] <cjwatson> so the odds of hitting it are probably non-negligible, indeed
[21:01] <bfiller> robru: ping
[21:15] <bfiller> fginther: is jenkins down?
[21:15] <fginther> bfiller, not the one I'm looking at
[21:16] <renato> fginther, could you take a look on this MR: https://code.launchpad.net/~renatofilho/mediaplayer-app/fix-1231418/+merge/188433
[21:16] <fginther> bfiller, upstream merger and public jenkins are responding for me
[21:17] <bfiller> fginther: waiting on this MR too: https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-1213046/+merge/186223
[21:18] <fginther> renato, your MP is at the front of the build queue
[21:19] <renato> fginther, thanks
[21:19] <bfiller> fginther: many of the MR's in the sheet are still not working
[21:19] <bfiller> fginther: in fact don't see any that passed yet
[21:21] <bfiller> fginther: this one approved but never merged: https://code.launchpad.net/~ted/gallery-app/single-instance/+merge/186611
[21:21] <bfiller> all the browser ones still failing tests
[21:21] <lool> heya
[21:21] <fginther> bfiller, one moment
[21:22] <robru> bfiller, pong.
[21:22] <bfiller> robru: please see my email re: ubuntu-keyboard
[21:23] <bfiller> robru: it needs a new release as the one you guys did today has issues
[21:23] <robru> bfiller, ah, ok. sure thing.
[21:24] <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 ;-)
[21:25] <bfiller> robru: I know, not sure why exactly. I never requested one. I think it's because he reverted one last week
[21:26] <robru> bfiller, yeah. the asks page just says that he's reverting the revert.
[21:27] <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
[21:27] <robru> bfiller, ok, no worries. as soon as jenkins lands it in trunk, I will kick off a new release build.
[21:27] <bfiller> robru: thank you
[21:28] <robru> bfiller, you're welcome. I just subscribed to the MP so I should get notified as soon as it's ready
[21:28] <fginther> bfiller, do you have time for a hangout?
[21:28] <bfiller> fginther: yes
[21:31] <plars> camera, address-book, and clock seem to be crashing: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4494/
[21:31] <plars> on mako, just camera crashed
[21:31] <plars> ah, it's url-dispatcher and camera actually
[21:36] <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)
[21:38] <lool> plars: can you reproduce the camera crash?
[21:38] <lool> plars: I'd try downgrading qtvideo-node
[21:38] <plars> lool: likely yes - it happened on both mako and maguro, along with lots of failures
[21:40] <lool> address-book is url-dispatcher
[21:41]  * lool upgrades to 71
[21:41] <plars> lool: qtvideo-node didn't seem to upgrade in 71 either
[21:41] <lool> plars: that was 70 though
[21:41] <bfiller> plars: no idea, we haven't changed anything that would cause that
[21:41] <bfiller> could be qtvideo-node
[21:42] <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
[21:51] <mfisch> infographics broke in 71 for sure
[21:53] <lool> plars: so the error is:
[21:53] <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
[21:53] <lool> from the url-dispatcher crash in addressbok
[21:54] <lool> plars: this looks fishy; either dbus is going away because everything is going away (session), or there is some bad upstart deps somewhere
[21:55] <lool> url-dispatcher starts on started dbus
[21:55] <lool> so I'd rather vote on the former
[21:56] <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*/
[21:56] <plars> lool: I'll see if I can reproduce it locally while I'm watching
[22:09] <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
[22:09] <lool> I mean, it basically causes an abort to get a backtrace
[22:10]  * lool => bed
[22:17] <plars> the camera one is easily reproducible for me, the url-dispatcher one is harder to hit it seems
[23:01] <rsalveti> lool: ogra_: will update the seeds and spin a new image
[23:04] <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