[00:00] <robru> veebers, https://code.launchpad.net/~robru/autopilot-qt/pitti-py3-deps/+merge/231478 here's a fixed MP, want to build that one instead?
[00:01]  * veebers looks
[00:04] <veebers> robru: yeah looks good. Thanks :-)
[00:04] <robru> veebers, no worries
[00:04] <ToyKeeper> Actually, make that 012 then 010.  015 is misbehaving.
[00:04] <veebers> I'll update the spreadsheet now
[00:05] <veebers> robru: I need to reconfig then build right?
[00:05] <robru> veebers, yep, should work if you recon first.
[00:08] <robru> ToyKeeper, is it a known bug that you can't exit a scope in image 200? I opened the reddit scope and I can't seem to get out of it by swiping...
[00:08] <robru> ToyKeeper, nm, it's weird
[00:10] <ToyKeeper> robru: Not that I'm aware of...
[00:11] <robru> ToyKeeper, yeah, had to press the back button 'just so', quite a small target apparently.
[00:12] <ToyKeeper> robru: That reminds me...  I've been meaning to file a bug about something which might cause that.  I mostly notice it when typing.  Any tap which is too close to the edge gets interpreted as the beginning of an edge swipe, and not passed to the app.
[00:13] <ToyKeeper> Makes it difficult to hit the keys on the left and right edges of the keyboard.
[00:13] <ToyKeeper> ... and apparently makes the back button even harder to press.  As if being in the least-accessible corner wasn't already enough.
[00:13] <robru> ToyKeeper, yeah that sounds like what i just saw.
[00:14] <robru> ToyKeeper, oh hey, when you said silo 15 was misbehaving, what method did you use to install it?
[00:15] <robru> ToyKeeper, are you using 'citrain device-upgrade'?
[00:15] <ToyKeeper> robru: No, but I'm doing the same thing.  Add the PPA, remove all other package sources, apt-get update, apt-get dist-upgrade, reboot.
[00:16] <ToyKeeper> The 'misbehaving' bit only happens after installing both 015 and the AP test bits.  It makes several app icons disappear.
[00:16] <robru> ToyKeeper, ah, well "remove all the other package sources" is the trick there, because 'citrain device-upgrade' doesn't do that and so it's prone to breaking things by installing non-silo stuff that's in the archive but not yet in a released image.
[00:17] <ToyKeeper> Doesn't happen with image 199 + AP, or with 199 + silo-015 but no AP.
[00:18] <robru> ToyKeeper, are you using any sort of script to help automate the "remove all other package sources" step? if so I'd like to incorporate that into the citrain script ;-)
[00:18] <ToyKeeper> robru: Yes, a thing I've had kicking around for a while called 'get-silo'.
[00:19] <robru> ToyKeeper, ooooh, please share!
[00:21] <ToyKeeper> robru: #!/bin/bash
[00:21] <ToyKeeper> # install everything from a landing silo
[00:21] <ToyKeeper> silo_number=$1
[00:21] <ToyKeeper> echo 'remounting / rw'
[00:21] <ToyKeeper> mount -o remount,rw /
[00:21] <ToyKeeper> echo 'apt-add-repo'
[00:21] <ToyKeeper> add-apt-repository ppa:ci-train-ppa-service/landing-$silo_number
[00:21] <ToyKeeper> echo 'removing deb and deb-src lines'
[00:21] <ToyKeeper> cat /etc/apt/sources.list | sed 's/^/# /' > /tmp/apt-foo
[00:21] <ToyKeeper> mv /tmp/apt-foo /etc/apt/sources.list
[00:21] <ToyKeeper> echo 'apt-get update'
[00:21] <ToyKeeper> time apt-get update
[00:21] <ToyKeeper> echo '[00:21] <ToyKeeper> wget -qO- http://ppa.launchpad.net/ci-train-ppa-service/landing-$silo_number/ubuntu/dists/utopic/main/source/Sources \
[00:21] <ToyKeeper>   | perl -ne 's/,//g; s/^Binary: // && print'
[00:21] <ToyKeeper> apt-get dist-upgrade
[00:21] <ToyKeeper> gah
[00:21] <ToyKeeper> WTF firefox, I copied the URL, not the file contents.
[00:21] <thomi> lol
[00:22] <robru> hehe
[00:22] <ToyKeeper> Weird.  It refuses to clipboard the URL.
[00:22] <ToyKeeper> Anyway, http://paste.ubuntu.com/8093412/
[00:23] <robru> ToyKeeper, thanks
[00:36] <robru> sergiusens, around?
[01:08] <sergiusens> robru: yes
[01:08] <sergiusens> missed the highlight
[01:08]  * sergiusens curses at quassel
[01:08] <robru> sergiusens, no worries. I submitted a branch for phablet-tools. fixed up citrain script reall nice-like
[01:09] <robru> sergiusens, https://code.launchpad.net/~robru/phablet-tools/isolate-upgrades
[01:09] <sergiusens> robru: reviewed it 5 minutes ago :)
[01:09] <robru> sweet
[01:09] <sergiusens> just some minor comments
[01:09] <sergiusens> you can ignore them completely or keep it in a TODO
[01:15] <robru> sergiusens, replied with reasons.
[01:16] <sergiusens> and they are fair :-)
[01:17] <robru> sergiusens, actually I'll add a warning for you ;-)
[01:17] <sergiusens> robru: jenkins is failing due to the packaging needing updating due to the removed scripts
[01:17] <robru> sergiusens, ah I can fix that
[01:17] <sergiusens> with a passing jenkins, it's all good from my pov
[01:18] <ToyKeeper> robru: Have people really been testing silos all this time with extra junk from the distro sneaking in each time?
[01:18] <robru> ToyKeeper, well, only people who use my script. I don't have a clear picture of who is using it and who isn't. but yes.
[01:22] <sergiusens> ToyKeeper: depends
[01:22] <sergiusens> i.e.; I used device-install to get the ppa and then just manually select what I wanted
[01:22] <sergiusens> so while it was broken; I got what I wanted
[01:23] <ToyKeeper> I didn't feel the need to share my little get-silo script because it seems pretty trivial.
[01:23] <sergiusens> robru: ah, the script has a potential to not work if the deps in the silo depend on a newer package than the one on the image; should be fairly non important as we build frequently enough
[01:23] <robru> ToyKeeper, it's very-nearly-trivial, but I'd rather if people were standardized on one thing rather than everybody having to implement it themselves.
[01:23] <sergiusens> ToyKeeper: I had a similar one as well :-)
[01:24] <sergiusens> dropped it, same as my phablet shell look a like I used to use
[01:24] <sergiusens> robru: feature request! phablet-shell [command] should work too :-)
[01:24] <ToyKeeper> What I'd really like to see standardized is including a test with every silo.
[01:25] <robru> sergiusens, why? the whole point of phablet-shell is to fix ncurses apps... 'adb shell [command]' doesn't have a problem with returning STDOUT, does it?
[01:26] <sergiusens> robru: depends, I get weird things when piping to  less
[01:26] <sergiusens> robru: anyways; I'm in no dire need for it
[01:26] <robru> sergiusens, I can add that pretty easily I think.
[01:27] <sergiusens> robru: just wait for ogra_ to land his rework branch first (I think he had one for phablet-shell somewhere)
[01:29] <ToyKeeper> Are we actually going to remove adb shell?
[01:29] <robru> ToyKeeper, no, just de-rooting it
[01:29] <ToyKeeper> I haven't set up (or even installed) phablet-shell yet, but I probably should.
[01:29] <robru> ToyKeeper, it's slick ;-)
[01:30] <ToyKeeper> robru: Does it go over USB or wifi?
[01:31] <robru> ToyKeeper, it sets up a port forward over USB and then ssh's through it. but first it copies your SSH key so you don't even need a password to log in.
[01:31] <robru> ToyKeeper, basically as automatic as adb shell, except it gives you a real shell rather than the hobbled one adb uses.
[01:31] <ToyKeeper> Cool.  If it were wifi, I'd have to pass...  wifi here sucks.  I can see 39 networks right now, and there are only 3 non-overlapping channels.  :(
[01:33] <ToyKeeper> I'm tempted to post a public service announcement on every neighbor's door, asking them to turn off 802.11n (uses two channels instead of one) and move their WAPs to the lowest possible point in their homes to reduce radio congestion.
[01:33] <ToyKeeper> Either that or install Faraday shielding on all my walls.
[01:33] <robru> ToyKeeper, that second option will be easier.
[01:34] <robru> sergiusens, ok, added a warning and fixed the packaging, will release it once a silo opens up
[01:38] <ToyKeeper> Mirv__: Why is the MP for 012 in the comment area instead of the MP area?  And is there any sort of test to verify the change?
[01:45] <robru> ToyKeeper, yesterday we hit a bug where rebuilds weren't getting the .1 appended to their version numbers, to I think mirv switched that one to a source silo so he could fix the packaging himself manually.
[01:49] <ToyKeeper> Ah...  okay.
[01:50] <ToyKeeper> Yesterday I was kind of sick.  Forgot I'm allergic to mowing the lawn.
[01:51] <ToyKeeper> (well, allergic to several local plants...  and didn't wear a mask when I mowed at the house I'm trying to get rid of)
[01:54] <veebers> robru: fyi the gatekeeper run with unity8 had 1 failing test that wasn't related to the changes in the silo 20 (packaging changes) (http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/214/label=gatekeeper-mako/testReport/)
[01:57] <robru> veebers, want to release then?
[01:57] <veebers> robru: yes please
[02:04] <imgbot> [02:26] <veebers> :-(
[02:26]  * veebers approves
[02:27] <veebers> done
[03:20] <tedg> So does QA need to sign off on everything now?
[03:20] <tedg> Or just larger merges?
[03:26] <ToyKeeper> raise mismatch_error
[03:26] <ToyKeeper> testtools.matchers._impl.MismatchError: 'Red' != 'Green'
[03:26] <ToyKeeper> Heh.  Next thing it'll be telling me black and white are different.
[03:26] <ToyKeeper> tedg: Everything which doesn't fix a blocker.
[03:27] <tedg> K, will mark as such.
[03:27] <ToyKeeper> tedg: Oh, and it takes twice as long as usual now, too.  Gotta test before and after on two devices instead of just one.
[03:28] <tedg> Hmm, joy. Guessing there's someone working through the silos that are blocked on QA, or do we need to ping?
[03:29] <ToyKeeper> tedg: I think at the moment it's just me.  I have one failed with the owner not around, one in progress, one more to do, and it sounds like you're adding one more.
[03:29] <robru> tedg: yeah it's just ToyKeeper
[03:29] <ToyKeeper> By the time it's tested, I suspect someone in .eu will be doing it.
[03:30] <tedg> Yup, mine is easy and involves reading a Wikipedia entry. /me is selling it.
[03:30] <tedg> :-)
[03:30] <ToyKeeper> The queue would be empty by now if we only had to verify on one device.  :(
[03:30] <ToyKeeper> Then again, I haven't even once gotten the same test result on both devices yet.
[03:30] <tedg> Cool, okay. Let me not block you, just wanted to ensure I was following process.
[03:32] <ToyKeeper> I hope we'll be done within 24 hours, because otherwise brendand gets to cover for me on Thursday and he lives about 8 hours earlier.
[03:39] <imgbot> [03:39] <imgbot> [04:01] <Mirv__> ToyKeeper: robru: no, someone else has just mentioned the MP in there in the Qt landing silo
[04:01] <robru> Mirv__: why is there an MP at all?
[04:02] <robru> if it's a source upload
[04:02] <Mirv> robru: CI has asked Qt stuff to go through MP:s so that some code coverage numbers are updated (or something)
[04:02] <Mirv> robru: so I put an auto-merger MP in always when releasing something
[04:05] <robru> sergiusens: https://launchpadlibrarian.net/182740747/phablet-tools_1.1%2B14.10.20140703-0ubuntu1_1.1%2B14.10.20140820-0ubuntu1.diff.gz uh, do you have some trunk commits you didn't release? there's stuff in this diff that's more than just my MP
[04:07] <robru> hmmm, seems like the diff is including a couple old releases for some reason.
[04:11] <Mirv> I wrote a Qt test plan to wiki instead of repeating it in comments each time
[04:15] <Mirv> ToyKeeper: so I now wrote the test plan for Qt that I've been doing, basically running all AP:s and then -app manual tests for those that have it at https://wiki.ubuntu.com/Process/Merges/TestPlan/ (searching for "-app").
[05:20] <ToyKeeper> ... it'd be really nice if I could get the same result twice in a row.
[07:46] <sil2100> Mirv: publishing silo 12 then o/
[07:47] <Mirv> sil2100: oh, I just did..
[07:47] <sil2100> Mirv: excellent ;)
[07:48] <Mirv> apparently I managed to be first
[07:48] <Mirv> thanks ToyKeeper for signoff!
[07:49] <ToyKeeper> Mirv: At least, as far as I can tell, it seems okay.  I wasn't able to directly test the specific bugfix involved, but it doesn't appear to break anything else at least.
[08:00] <Mirv> mandel's ofono landing is _critical_, otherwise I can't send cat photos out of my phone via MMS
[08:01] <Mirv> seriously speaking looks like important phone fixes
[08:01] <mandel> Mirv, haha you scared me with the cat photos, they are indeed important
[08:02] <mandel> Mirv, we probably need a qa signoff
[08:02] <sil2100> hah ;)
[08:03] <Mirv> signoff probably needed, yes
[08:03] <Mirv> mandel: also, the MP would need approving
[08:04] <mandel> Mirv, hmm was it not, I'll ping abeato about that
[08:04] <sil2100> psivaa: I noticed that we're missing parts of test results for both 200 and 201 - looks like some device went down?
[08:04] <Mirv> mandel: at least there's no green "Approved" in a comment there yet.
[08:06] <abeato> mandel, hi
[08:06] <psivaa> sil2100: no, this time it wasn't devices.. calendar_app.tests.test_new_event.NewEventTestCase.test_edit_event_with_default_values test had gone on an infinite loop of ' Pressing and Releasing: BackSpace'
[08:06] <sil2100> Oh, damn, twice
[08:06] <Mirv> calendar got updated in #200..
[08:07] <mandel> Mirv, abeato is the one that owns the branch, AFAIK it has been reviewed but we do not want to wait for awe (USA) to get the silo
[08:08] <abeato> mandel, Mirv awe already reviewed and I addressed a couple of minor issues in the changelog
[08:08] <Mirv> mandel: abeato: no problem getting the silo, just to let you know it needs formal approving
[08:08] <Mirv> there's only 1 empty silo but another one should be emptied in 1h, so I think I can assign the silo
[08:08] <abeato> Mirv, great, thanks, when awe wakes up we'll get the approval
[08:09] <psivaa> sil2100: last part of the logs in  https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/753/consoleText shows it.. the job timed out and therefore dint run clock, dropping letters, terminal and system settings
[08:09] <psivaa> sil2100: but i've aborted the calendar tests in 201.. so we should have the other results
[08:10] <sil2100> psivaa: thanks!
[08:10] <psivaa> yw :)
[08:10] <sil2100> We would need to ask Brendan to look into the calendar-app issue...
[08:11] <mandel> Mirv, great, thx1
[08:11] <mandel> Mirv, I'll make sure that awe does take a look
[08:15] <mandel> brendand, I own you an update on the sims! sorry for the delay, but I've been focused on an important feature for the phone that cound not be delayed :-/
[08:16] <brendand> mandel, that's ok
[08:20] <sil2100> brendand: hi! So, we seem to be encountering a strange infinite loop in calendar app tests since the last update of the app
[08:20] <sil2100> brendand: it happened twice already - in 200 and 201
[08:21] <sil2100> brendand: psivaa got this log: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/753/consoleText
[08:21] <brendand> sil2100, infinite loop - crazy!
[08:21] <sil2100> brendand: could you take a look?
[08:23] <pete-woods> trainguards: hi folks. I agreed with Saviq to land my silo before his, but obvs now we are in traincon-0. I'd say it's really worth getting this release of scopes into a promoted image, as it fixes a number of race conditions, fixes scope settings, and has had a lot of testing (now that it went through the rtm release)
[08:23] <brendand> sil2100, oooh - that must be autopilot related
[08:23] <pete-woods> I don't really know who "QA" means, though
[08:23] <pete-woods> i.e. who to talk to
[08:23] <brendand> pete-woods, me, davmor2
[08:24] <pete-woods> oh, cool :)
[08:24] <brendand> pete-woods, which silo?
[08:24] <Mirv> brendand: it seems landing-005
[08:24] <brendand> ok
[08:24] <pete-woods> beat me to it
[08:27] <Mirv> brendand: sil2100: I think it should be marked as requiring QA signoff, and maybe consider doing the QA validation first on that silo? it's scopes only so the validation should take relatively small time compared to some system wide changes.
[08:27] <Mirv> (marked)
[08:28] <brendand> pete-woods, are there any functional changes or is it just bug fixes?
[08:29] <pete-woods> brendand: there should be no user-visible changes. it changes our settings backend to use qt labs settings, instead of u1db, though
[08:29] <sil2100> Mirv: yes, that's a good idea
[08:29] <brendand> flashing a device now
[08:32] <sil2100> ogra_, popey: ping
[08:34] <popey> sil2100: yeah, hangouts suck
[08:34] <popey> had to reboot
[08:37] <seb128> hum, did we stop getting amd64 builds from the CI/jenkins?
[08:37] <seb128> e.g on https://code.launchpad.net/~mterry/unity8/dismiss-old-pam-prompts/+merge/231363
[08:37] <seb128> fginther`, ^
[08:41] <dbarth> morning
[08:41] <dbarth> what's the procedure to get a qa signoff on a silo?
[08:41] <dbarth> ie, who do i bribe^Huh ping?
[08:51] <popey> dbarth: davmor2 i think.
[08:53] <davmor2> dbarth: me initially
[09:01] <brendand> Mirv, 0.4.393
[09:01] <davmor2> dbarth: what do you need testing?
[09:01] <Mirv> sil2100: correction, pkcon install-local is the right away. I always have to try twice (I first try local-install) before I get it right :)
[09:02] <Mirv> brendand: http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/136/artifact/out/com.ubuntu.calendar_0.4.393_all.click
[09:02] <sil2100> ;)
[09:07] <popey> ogra_: have we disabled adb now?
[09:08] <ogra_> popey, not without a huge announcement, no :)
[09:08] <popey> hmm
[09:08] <popey> wonder why adb can't see my phone
[09:08] <bzoltan1> ogra_:  do you know if there is a way to flash my device without that intro wizard?
[09:08] <ogra_> nothing changed within the last months
[09:08] <popey> pfft, unplug/replug
[09:09] <ogra_> bzoltan1, pgablet-config has a command to disable it
[09:09] <ogra_> *phablet
[09:09] <bzoltan1> ogra_:  yes... after I flashed and used my pretty little fingers :) and I wish to spare them from that work if that is possible
[09:10] <ogra_> ubuntu-device-flash --foo --bar --baz && phablet-config welcome-wizard disable
[09:10] <ogra_> that will make phablet-config sit and wait til adb shows up
[09:10] <ogra_> and automatically disable it
[09:11] <dbarth> davmor2: it's in silo 15
[09:11] <davmor2> dbarth: yeap I will put it in my list
[09:12] <dbarth> davmor2: it's a bunch of oa fixes; mostly packaging; one with hooks and one in the UI where you should see the list be disabled once you select an account type to create
[09:12] <dbarth> davmor2: ty
[09:34] <psivaa> sil2100: the 201 with rerunning system settings and reminder, reminders showed 6 failures on the rerun too, system-settings all passed. crashes are (only 3 this time) camera app, unity8 and indicator network
[09:35] <Mirv> psivaa: FYI no good retrace from the #199 shorts_app qmlscene, although I'll let LP try it still: bug #1359126
[09:52] <psivaa> Mirv: i did not see that crash again on 200 or in 201
[09:53] <popey> sil2100: for me on nexus 4, music app passed all 17 tests ok
[10:00] <sil2100> popey: I'm installing the package now, will confirm in a minute
[10:01] <popey> thanks
[10:02] <brendand> sil2100, the infinite loop is certainly reproducible
[10:02] <brendand> sil2100, i'll try the old version of the click package now
[10:02] <sil2100> brendand: ok, thanks!
[10:14] <sil2100> popey: wait a moment still, I'm having some problems setting up the tests ;/
[10:20] <brendand> sil2100, so now it fails, but doesn't get stuck
[10:22] <popey> sil2100: no, just the usual phablet-config autopilot --dbus-probe enable ; phablet-click-test-setup --click  com.ubuntu.music ; adb reboot ; phablet-test-run -v music_app
[10:23] <sil2100> For me all the tests are failing somewhere in setUp... strange, I'll try to reconfigure those
[10:26] <popey> do you have any music on the device?
[10:31] <sil2100> No, no one told me that's a requirement - let me push some
[10:33] <brendand> sil2100, ah it seems the test that is a problem is a brand new test
[10:34] <sil2100> brendand: do you see anything obviously broken there?
[10:34] <brendand> sil2100, well now i need to step through it and see what it is doing
[10:36] <brendand> Mirv, can i get the current click package too? i need to reinstall
[10:36] <brendand> Mirv, i can probably work it out from the link actually - if i get stuck i'll ask
[10:37] <sil2100> popey: hm, still seems to fail
[10:37] <popey> have they ever passed on that device?
[10:39]  * sil2100 reboots
[10:39] <brendand> davmor2, you been checking silo005?
[10:39] <davmor2> bregma: is that the mtp silo
[10:40] <davmor2> brendand: ^ even
[10:40] <sil2100> Yes
[10:40] <sil2100> Wait
[10:40] <davmor2> bregma: sorry
[10:40] <brendand> davmor2, i was under the impression it was scopes
[10:40] <sil2100> popey: actually, now that I see, they didn't indeed
[10:40] <sil2100> I was looking at the wrong test results
[10:40] <davmor2> brendand: no then the mtp stuff must of landed already :)
[10:40] <brendand> davmor2, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-005
[10:40] <popey> ok, so can we agree that it's unfair to block this update on a device where they already fail?
[10:41] <sil2100> popey: anyway, sorry for the delay then, you can push to the store
[10:41] <popey> thanks sil2100
[10:41] <popey> Mirv: ^^ please can you push that music click to the store.
[10:41] <brendand> davmor2, looks fine to me - scopes work ok. i might run the unity8 AP tests as well
[10:41] <sil2100> It's strange though, as the failure seems to be on accessing the SQL database
[10:42] <davmor2> brendand: no then I'm doing the dogfooding at the minute.  If you are happy with it mark it as qa passed on the spreadsheet :)
[10:43] <brendand> davmor2, how does it taste?
[10:44] <davmor2> it's kinda okay so far the glass is a little crunchy though
[10:44] <sil2100> :D
[10:46] <Mirv> brendand: I assume you found it :)
[10:46] <brendand> Mirv, yeah :)
[10:46] <Mirv> popey: music click uploaded
[10:47] <popey> thanks Mirv
[11:16] <brendand> sil2100, ok so the reason is clear now, even if the fix is not
[11:23] <sil2100> brendand: what is this new test-case about? Is that for a new feature?
[11:26] <brendand> sil2100, nope, it just edits an event
[11:26] <brendand> sil2100, basically it tries to clear a text field and the autopilot function which does that has an issue
[11:26] <brendand> sil2100, it depends on the cursor ending up at the end of the text
[11:26] <brendand> sil2100, which doesn't happen
[11:27] <brendand> i filed a bug but need to do a bit more investigation: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1359167
[11:27] <brendand> sil2100, actually the feature *might* be new
[11:28] <brendand> sil2100, since when i ran with the old click it didn't get to where the failure occured
[11:28] <brendand> sil2100, hard to explain
[11:30] <nik90> brendand: do you have a link to that function?
[11:40] <sergiusens> robru: I don't do trunk releases on deb and everything I control is trunk == package (except for clicks, but I don't own those)
[11:42] <ogra_> sergiusens, hmpf, are you aware that all that citrain stuff you landed last night wont work at all if it doesnt use phablet-tools etc ?
[11:42] <sergiusens> ogra_: I didn't land it
[11:42]  * ogra_ notes even more developer mode hacks he will have to do 
[11:42] <ogra_> you approved it, didnt you ?
[11:42] <sergiusens> ogra_: yeah; but it didn't change much of what was already there
[11:42] <sergiusens> right?
[11:43] <ogra_> dunno, but it was pointless to land it
[11:43] <ogra_> and i was actually expecting all the citrain stuff to not use adb shell directly ...
[11:44] <sergiusens> ogra_: feel free to break it; but in the meantime, people were testing targets incorrectly; so for the 'today' it was rather important
[11:44] <ogra_> thanks for at least pointing it to me via the merge :)
[11:44] <sergiusens> ogra_: that was the point
[11:44] <ogra_> long planned and all, yeah :)
[11:47] <brendand> nik90, it's actually in uitk /home/phablet/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_textarea.py
[11:48] <brendand> nik90, although i don't think that's where the actual problem is
[11:48] <nik90> brendand: actually I suspected since calendar is expected to use the sdk AP helpers
[11:48] <nik90> brendand: I will see if I can figure out where it is failing in calendar
[11:53] <brendand> nik90, first thing it does is 'with self.keyboard.focused_type'
[11:53] <brendand> nik90, this focuses the cursor on the description field
[11:54] <brendand> nik90, the problem is it is in the middle of the text
[11:54] <nik90> brendand: ok, but if it is used the SDK AP helpers that shouldn't matter since the helper will autoselect the whole text and clear it.
[11:54] <brendand> nik90, http://people.canonical.com/~brendan-donegan/middle.png
[11:55] <nik90> brendand: if it doesn't do that, then it is not using the SDK helper function correctly
[11:55] <brendand> nik90, no it doesn't do that
[11:56] <nik90> brendand: I use the helpers for the clock app tests, where I use it to clear the timer names and start fresh
[11:56] <brendand> nik90, next it is calling '/home/phablet/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_textarea.py(23)clear()'
[11:56] <brendand> nik90, right maybe there is a different helper that does that
[11:57] <brendand> nik90, have you done that on device or on desktop?
[11:57] <nik90> brendand: both
[11:57] <brendand> nik90, run the clock app tests that is
[11:57] <brendand> nik90, okay because the behaviour is stated as being different between the two
[11:57] <brendand> nik90, on desktop it does do select_all
[11:57] <brendand> nik90, but anywhere else it uses the 'End' key
[11:58] <brendand> nik90, and it looks like the End key does not work properly
[11:58] <nik90> brendand: ah
[11:58] <brendand> nik90, it's not going all the way to the end of the text
[11:59] <brendand> nik90, http://people.canonical.com/~brendan-donegan/after_end.png
[12:00] <nik90> brendand: I think it could be because every other field uses TextField{} while the description is a TextArea{}
[12:00] <nik90> brendand: so different helpers indeed
[12:01] <sil2100> davmor2: how's the dogfooding?
[12:02] <cjwatson> is this dogfooding for a potential promotion candidate?
[12:02] <cjwatson> I thought there were still blockers
[12:03] <davmor2> sil2100: it's looking pretty good, it's not finished but so far not too bad.
[12:03] <davmor2> cjwatson: no just to make sure nothing else is horrifically broken
[12:03] <sil2100> cjwatson: since we still have blockers, we're using the time for davmor2 to make sure there are no new ones that sneaked in before TRAINCON-0
[12:03] <sil2100> davmor2: how about krillin? Did you test only mako for now?
[12:04] <cjwatson> mkay.  was trying to work out if I could somehow manage to land perl 5.20 before feature freeze
[12:04] <davmor2> sil2100: I'm testing both that's why it's not complete yet :) I'll finish off after lunch
[12:04] <sil2100> davmor2: thanks ;)
[12:09] <om26er> sil2100, which silo would you need me to test first ?
[12:13] <sil2100> om26er: hey! Let me see
[12:15] <sil2100> om26er: so, I think brendand is testing silo 5 already, so maybe start off with silo 009
[12:16] <om26er> sil2100, ok
[12:56] <om26er> sil2100, any other silo that no one else is testing ?
[13:00] <brendand> sil2100, same here
[13:06] <Mirv> om26er: brendand: I remember dbarth asking davmor2 about silo 015, not sure if it's underway. I haven't seen anyone announcing looking at 010
[13:07] <brendand> Mirv, well i'll look at 10 then :)
[13:07] <davmor2> Mirv: I was going to look after but now om26er is here and brendand  has finished either of them can have a look
[13:08] <Mirv> om26er: so 015 would be free to take ^ :)
[13:08] <om26er> Mirv, ok, thanks
[13:09] <tedg> Cool, signed off. sil2100, can you publish silo 9 please?
[13:09] <fginther`> seb128, https://code.launchpad.net/~mterry/unity8/dismiss-old-pam-prompts/+merge/231363 does have an amd64 build
[13:09] <fginther`> seb128, http://jenkins.qa.ubuntu.com/job/unity8-utopic-amd64-ci/1118
[13:09] <seb128> fginther`, no "deb" with the result though?
[13:10] <sergiusens> seb128: output.zip was generated for armhf only historically
[13:10] <Mirv> tedg: I was just looking at that. done.
[13:10] <tedg> Ah, cool, thanks Mirv!
[13:10] <seb128> sergiusens, oh, I though we had it for amd64 as well, for some reason
[13:11] <sergiusens> seb128: since it was at a time when we had really bad build times there and people had only access to emulated armhf builders
[13:11] <fginther`> seb128, ah, no that's not being collected. It would have been collected incidentally as part of the otto testing, but we had to stop that a few months ago due to problems getting the testing working reliably
[13:11] <seb128> fginther`, sergiusens, k, weird, ubuntu-system-settings include amd64 debs
[13:11] <seb128> I though that was standard
[13:11] <seb128> seems not
[13:12] <sergiusens> seb128: well I guess if you ask for it they will do it
[13:12] <Mirv> seb128: are you up to reviewing packaging changes? removing external dependencies and adding symbols: https://ci-train.ubuntu.com/job/ubuntu-landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-shell_0.5.4+14.10.20140819-0ubuntu1.diff + https://ci-train.ubuntu.com/job/ubuntu-landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-api_0.6.3+14.10.20140819-0ubuntu1.diff
[13:12] <sergiusens> nothing prevents it except thinking about jenkins storage requirements
[13:14] <fginther`> seb128, yeah it's been added to a few projects due to specific requests, generally saving these for all could potential blow up our storage
[13:14] <seb128> Mirv, whoever decided to reorder .symbols in their file, that's not a good idea
[13:14] <fginther`> seb128, if you're asking for unity8, I can turn it on
[13:14] <seb128> fginther`, k, thanks for the reply, I was mostly curious (I also don't want to build that one myself, but I can wait for it to be in a silo)
[13:14] <seb128> fginther`, don't bother
[13:14] <fginther`> seb128, ok
[13:15] <seb128> thanks
[13:15] <seb128> Mirv, "0.6.2+rtm+rtm+rtm+14.09.20140818", wth with that version?
[13:16] <cjwatson> I could understand that in ubuntu-rtm, but what's that doing in ubuntu?
[13:16] <Mirv> pete-woods|away: why did you reorder the .symbols? ^
[13:17] <Mirv> seb128: +rtm+rtm etc was a bug in CI Train. they're including the changelog entry since they're syncing their earlier rtm landing.
[13:17] <seb128> Mirv, also -1 from me, some function changes signature in the .symbols, which is an ABI change
[13:17] <seb128> that should be a soname change
[13:17] <ogra_> seb128, you just have to count rtm's now ... one per upload gets added :)
[13:17] <cjwatson> Mirv: syncing an earlier rtm landing is pointless
[13:18] <cjwatson> Mirv: ubuntu-rtm is going to be reset to match ubuntu as of the next promoted landing
[13:18] <cjwatson> Mirv: so please tell them not to do that since they have to fix up for seb128's comments anyway
[13:18] <sil2100> davmor2: any final dogfooding results?
[13:18] <Mirv> seb128: ok then. pete-woods|away: ^ -1 on the packaging changes / symbols
[13:19] <davmor2> sil2100:  just got back from lunch,  It looks like there is an issue on mako with the welcome wizard, just trying to track down if it got disabled or not
[13:19] <cjwatson> pete-woods|away: ^- my comments too
[13:19] <Mirv> cjwatson: so doesn't it make sense to get the changes that went only to -rtm to the ubuntu then? or do you just mean preserving the old changelog entry is needless?
[13:19] <cjwatson> Mirv: it doesn't make sense, because those changes will be flushed
[13:20] <Mirv> cjwatson: right, I just checked I understood correctly. thanks.
[13:20] <cjwatson> Mirv: I mean, if there were changes that went only to -rtm without being in ubuntu first, then that was violating landing policy anyway - the substantive changes should be merged, but not the changelog
[13:20] <cjwatson> or not the version
[13:20] <cjwatson> if that makes sense
[13:20] <cjwatson> but AFAIK the only things that were landed on ubuntu-rtm were copies of things already in ubuntu
[13:23] <Mirv> they landed to rtm directly on line 1189 of the archive tab
[13:24] <dbarth> Mirv: you can free silo 19 if you're running low on them
[13:24] <dbarth> or anyone interested in getting back some free silos
[13:24] <Mirv> dbarth: ah, thanks, it's needed indeed! just ask it back later.
[13:25] <dbarth> nw
[13:25] <dbarth> btw, i also have silo 6 which passed tests; can i get a ack on that one to publish?
[13:27] <Mirv> dbarth: I was looking at that already. it seemed a very isolated MP worth publishing so I did that.
[13:28] <cjwatson> sil2100,robru: Can you clarify what happened with archived landing line 1189 (unity-scopes-shell, unity-scopes-api on ubuntu-rtm)?  It does not appear to have landed on ubuntu first; I thought we were all agreed that any landing on RTM must first have been separately landed for Ubuntu
[13:30] <cjwatson> sil2100,robru: The branches in question have been merged onto trunk because the branches targeted trunk, so it's all very confused now
[13:31] <sil2100> cjwatson: not sure what happened with this one, it might have been one of the first landings done after the RTM switch
[13:31] <sil2100> I mean, CI Train RTM switch
[13:31] <sil2100> Maybe robru will remember more
[13:53] <dbarth> Mirv: thank you
[13:53] <Mirv> mandel: would you be able to land the telephony-service .pot changes really quickly today?
[13:53] <mandel> Mirv, I'm not a lander, but if I get a silo I can make sure that they are tested asap and be ready to land
[13:54] <mandel> Mirv, is a matter of doing the test plan, but they are just .pot changes so is not a big deal
[13:54] <Mirv> mandel: the spreadsheet says you're lander :) ok, since that seems an easy landing. I fixed the MP URL:s for you.
[13:54] <cjwatson> BTW build queues are very long right now due to large batches of GCC, KDE, and Perl 5.20 builds, but let me know if there's anything urgent from CI Train that needs to be scored up
[13:54] <mandel> Mirv, yes, sorry I confused lander with publisher
[13:55] <pete-woods> Mirv: I didn't want to re-order the symbols. unfortunately we made a previous release with the symbols in a non-sorted order. this just brings it into line
[13:55] <Mirv> bfiller: are you ok recompiling telephony-service in landing-004 after mandel's .pot file changes?
[13:56] <pete-woods> this is also fun because we went through the same complaints when releasing to RTM :)
[13:56] <Mirv> pete-woods: if it was the +rtm+rtm+rtm release, the ordering can be probably reverted since the rtm will be overwritten
[13:56] <pete-woods> Mirv: that release was basically the same as the one we're doing now (just one extra bugfix)
[13:57] <om26er> Mirv, regarding the Online Accounts silo, I am trying to figure out what does the silo fix
[13:57] <pete-woods> I know its difficult to read the symbols diff, but we have extensive checking to ensure we don't break the ABI
[13:57] <cjwatson> there's certainly no reason to take the test RTM landing into consideration for basically anything
[13:57] <Mirv> om26er: ask dbarth (landing-015)
[13:57] <om26er> dbarth, Hi! what does silo 15 actually fix ? :)
[13:59] <bfiller> Mirv: yes
[14:00] <davmor2> sil2100: so everything that should work seems too, everything that is expected to be broken is
[14:00] <sil2100> davmor2: excellent news
[14:00] <davmor2> sil2100: I missed the -- on channel which is why I got R11 on my mako d'oh
[14:01] <dbarth> om26er: hi; fixes packaging, also a click hook issue and most of all, it ensures only 1 account type gets selected when creating a new account from system-settings
[14:01] <om26er> dbarth, are there bug reports ?
[14:02] <dbarth> om26er: ie, go uss > oa > add new account > verify that once 1 is selected until the trusted prompt appears
[14:02] <dbarth> om26er: nope, no one but i had noticed the issue yet ;)
[14:03] <om26er> dbarth, ok, thanks, Basically I just need to test the above thing, other than the test plan.
[14:04] <dbarth> om26er: right, i did the nomal regresionn testing, but you can emove / create an account just to get reassurance
[14:04] <dbarth> remove
[14:06] <Mirv> mandel: ok, you have landing-009 and it's already building https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/4/console
[14:07] <sil2100> davmor2: did you see kgunn's e-mail on the phone list? How serious is this bug? (since it sounds pretty serious)
[14:07] <mandel> Mirv, sweet, thx
[14:09] <ogra_> sil2100, the second one you mean ?
[14:09] <greyback> trainguards: hey (not TRAINCON0 related, so not urgent) I need a hand with silo16 - rebuilding qtmir-gles seems to not actually tell the PPA to rebuild - somehow the armhf package built but i386 & amd64 failed, and now the train considers it failed?
[14:09] <ogra_> sil2100, you cant stop the alarm at all ... it rings forever until you hard reboot the phone
[14:09] <sil2100> ogra_: yeah, the PIN-locked unresponsiveness... is that highly reproducible and bad?
[14:10] <sil2100> ogra_: that happens every time?
[14:10] <ogra_> (since the only UI element you had to stop it vanished with the first alarm)
[14:10] <ogra_> sil2100, well, every time you have two meetings at the same time or two alarms at the same time
[14:11] <ogra_> sil2100, not sure how often people have alarms or notifications scheduled for the exact same time though ... i had it once since the bug exists
[14:11] <ogra_> others with more filled calendars might have it more often
[14:12] <sil2100> hmm, complicated, I actually wonder what caused this to be broken
[14:12] <sil2100> kgunn: do we know what landing actually caused it?
[14:12] <Mirv> greyback: qtmir-gles does not have armhf package. it complained about lttng-ust, and you need to bump the qtmir-gles version to .1 manually in the MP since manual is the way the -gles packages get bumped and versioned.
[14:13] <pete-woods> Mirv: so what do you want me to change about the release? it is just the symbols file sorting, or is there more?
[14:13] <cjwatson> greyback: you should never use the Build button in CI Train to ask Launchpad to retry a failed build.  The Build button is mislabelled - it should be Upload
[14:13] <cjwatson> (IMO)
[14:14] <Mirv> pete-woods: anything seb128 and cjwatson mentioned, so ABI breakage / soname bump was suggested, and cleaning up debian/changelog
[14:14] <greyback> Mirv: cjwatson: ok I see my problem. Thanks for the help
[14:14] <pete-woods> Mirv: there is no ABI break. and when you say clean up. you mean pretend that the rtm release never happened, right?
[14:14] <cjwatson> pete-woods: The RTM release never happened :)
[14:14] <cjwatson> (Soon it will look like that statement is in fact true)
[14:14] <greyback> cjwatson: yeah I read Build as Build :)
[14:15] <seb128> pete-woods, why are some functions changing their number of arguments in the .symbols?
[14:15] <ogra_> sil2100, i doubt there was any specific landing and i bet it was always like that
[14:15] <sil2100> ogra_: you think so?
[14:15] <ogra_> sil2100, it is just that we now have locking ... it doesnt happen on a swipe device
[14:15] <seb128> pete-woods, e.g
[14:15] <seb128> - (c++)"unity::scopes::internal::ScopeObject::ScopeObject(unity::scopes::internal::RuntimeImpl*, unity::scopes::ScopeBase*)@Base" 0.4.0+14.04.20140312.1
[14:15] <seb128> + (c++)"unity::scopes::internal::ScopeObject::ScopeObject(unity::scopes::internal::RuntimeImpl*, unity::scopes::ScopeBase*, bool)@Base" 0.6.2+rtm+rtm+rtm+14.09.20140818
[14:15] <pete-woods> seb128: those are internal functions. I don't really like that we export out internal symbols, but we do.
[14:15] <sergiusens> trainguards can you recnfigure silo 8?
[14:15] <pete-woods> *our
[14:16] <sil2100> sergiusens: sure
[14:16] <seb128> pete-woods, well, you change exported objects, so you change abi
[14:16] <sergiusens> thanks
[14:16] <sil2100> Mirv: doing ^
[14:16] <seb128> pete-woods, no?
[14:16] <pete-woods> seb128: nope. this is purely internal, and happens like every release
[14:16] <sergiusens> also, can someone explain why people are already targetting the rtm archive? is it just for testing?
[14:16] <Mirv> sil2100: yeah, I try to drift off, although it's starting to get really busy all-around around this time :)
[14:16] <seb128> pete-woods, why is it showing in the exported symbols if it's not exported?
[14:17] <sil2100> Mirv: yeah, time for you to EOD! ;)
[14:17] <pete-woods> seb128: they are exported in the .so sense, but they are thoroughly checked to not be exposed in our headers
[14:17] <sergiusens> trainguards can we get a wiki with a workflow on when to target the rtm archive directly and when to target ubuntu and sync and other possibilities?
[14:17] <seb128> pete-woods, so in the .so sense you have an abi change?
[14:17] <seb128> pete-woods, if you expect no client to use that abi
[14:17] <sil2100> sergiusens: there will be an annoucement with the procedure once we're done with the official branching
[14:17] <sil2100> sergiusens: i.e. once we get a promotable image
[14:18] <sergiusens> sil2100: so what people are doing now is just testing, right?
[14:18] <pete-woods> seb128: yes, if someone copied one of our internal headers from our source tree (that don't get installed) and used the resulting symbol, they'd be stuffed
[14:18] <kgunn> sil2100: we don't know, investigation not far enough along
[14:18] <sil2100> sergiusens: yes, although there aren't too many ubuntu-rtm landings happening
[14:18] <seb128> pete-woods, k, seems like you could benefit from making those symbols private
[14:18] <pete-woods> seb128: I agree, but it's been like this since the start. and isn't my call to change
[14:18] <sergiusens> sil2100: well I don't know why people except for desktop shared components would target rtm specifically
[14:18] <seb128> pete-woods, sil2100: but ok then if you are sure there are no way a rdepends is using those functions
[14:19] <seb128> pete-woods, the fact that it's like that since the start doesn't make it right ;-)
[14:20] <pete-woods> seb128: apparently it makes debugging a great deal easier for us
[14:20] <seb128> k
[14:21] <pete-woods> seb128: I really don't like it either. especially because I have to have this conversation repeatedly :)
[14:21] <pete-woods> but I am not the tech lead of scopes. so feel free to engage in lengthy debate with michi
[14:24] <cjwatson> sergiusens: we were trying to get a variety of teams to do test landings
[14:27] <thostr_> seb128: we also need the internal symbols exported for our tests
[14:27] <thostr_> seb128: as this allows us to mock certain functionality
[14:28] <thostr_> seb128: this might not be optimal but it was the best we could do back then
[14:34] <seb128> thostr_, k, it makes it less trivial to review abi changes from outside, but of well, it's a price to pay I guess
[14:38] <cjwatson> If you were feeling kind you could figure out some way to annotate that - I think dpkg-gensymbols will ignore symbol tags it doesn't recognise, so (internal) or (x-internal) or something
[14:39] <cjwatson> Then at least people could guess that they don't need to worry about changes in those symbols
[14:39] <cjwatson> thostr_,pete-woods: ^-
[14:40] <thostr_> cjwatson: good to know
[14:41] <mvo_> hey trainguards - I would love to get a silo for 39, but I guess this will need qa signoff if we are in traincon-0 as it adds the click signature stuff which has the potential to break installing clicks. is there a chance for me to get it still into a silo so that I can do the final testing on the real device and all that?
[14:41] <pete-woods> cjwatson: yes, if that's possible it would definitely make my life less painful
[14:41] <cjwatson> check it, but the above is my reading of the man page
[14:42] <pete-woods> sure, will definitely check
[14:48] <sil2100> Mirv: hey! We're currently a bit low on silos right now, let me check if we can do anything
[14:48] <sil2100> I mean, mvo_
[14:48] <sil2100> ^
[14:48] <sil2100> ;)
[14:48]  * sil2100 curses the tab button
[14:49] <mvo_> sil2100: thank you!
[14:57] <om26er> dbarth, Hi! can you please provide me the it.mardy.account-tester_0.1_all.click ? I am not sure how to build it
[14:57] <om26er> its needed to run the automated tests
[15:01] <davmor2> sil2100: so personally I would land the fix that is mp'd and then maybe discuss the other the meeting.  I think it should be fixed but if it isn't going to get fix in the next 24 we really need to start the ball moving rtm wise
[15:03] <sil2100> davmor2: right, although the blocker that will be left seems like a serious issue in overall, would really feel bad with that if there is no workaround for it at least
[15:03] <davmor2> sil2100: the workaround is reboot the phone
[15:03] <sil2100> kgunn: do you know if maybe the PIN-locked bug has some at least nasty hacky workaround possible to do in a short timeframe?
[15:04] <sil2100> davmor2: excellent workaround ;p Sounds like old Windows all over
[15:04] <davmor2> sil2100: you mean turn it off and turn it back on isn't the magic cure all for everything
[15:05] <ogra_> davmor2, except that you cant reboot it anymore
[15:05] <ogra_> at least not without hassle
[15:07] <kgunn> sil2100: not really, b/c its super nasty....i don't support it....it would be to "ignore" one of the notifications
[15:08] <sil2100> Indeed ;/
[15:08] <sil2100> hmmm
[15:08] <kgunn> sil2100: so we're still focused on why the heck there's no surface drawn but input is already targeted...
[15:08] <kgunn> anyway...we're on it
[15:08] <camako> kgunn, you joining standup?
[15:08] <sil2100> kgunn: thanks for the update ;)
[15:08] <kgunn> arggg camako
[15:08] <kgunn> lost for time
[15:15] <brendand> tedg, i am trying to test silo010. it doesn't install
[15:15] <tedg> charles, ^
[15:15] <brendand> tedg, http://paste.ubuntu.com/8098699/
[15:15] <tedg> brendand, What error are you getting?
[15:15] <brendand> charles, ^
[15:16] <tedg> That might be an rsalveti question ^
[15:17] <rsalveti> brendand: check the comment in the spreadsheet
[15:48] <dbarth> om26er: ok
[15:48] <dbarth> om26er: in you inbox
[15:49] <om26er> dbarth, thanks
[15:53] <mvo_> sil2100: hm, still no silo for me? I guess I get some dinner then
[15:53] <sil2100> mvo_: still trying to get one free for you ;/
[16:00] <sil2100> mvo_: you'll have one pretty soon!
[16:02] <sil2100> ogra_: meeting!
[16:03] <ogra_> on my way, sorry
[16:04] <sil2100> pete-woods: hey, regarding silo 5 - did the recent rebuilds were only packaging-changes or something else as well?
[16:04] <pete-woods> sil2100: literally just debian/changelog
[16:05] <pete-woods> sil2100: and I span it up on the phone anyway, just to be paranoid
[16:06] <robru> cjwatson: sil2100: yes that scopes landing was the Very First RTM landing, and the upstreams weren't aware of the utopic->rtm requirement. I informed them that their trunks were messed up and they needed to re-do that release in utopic, not sure why they haven't fixed it yet.
[16:10] <brendand> charles, so alarms work while the phone is off with silo010, but there is no way to stop the alarm. do we want to land it like that?
[16:11] <pete-woods> robru: well we tried to fix it. but because of the normal waiting times for silos, going through the same debates re internal symbols, then being told to pretend the RTM release never happened, we have gone round the roundabout a few times :p
[16:11] <charles> brendand, no way to stop the alarm?
[16:12] <brendand> charles, well apart from holding down the power button for a really long time
[16:12] <charles> brendand, when the phone is suspended and the alarm goes off, the screen should come on + haptic feedback + the snap decision for dismiss
[16:12] <cjwatson> pete-woods: I'm sorry that the RTM bit wasn't clear to you, but I did explain things in https://lists.launchpad.net/ubuntu-phone/msg09377.html ...
[16:12] <brendand> charles, nope - not here
[16:13] <charles> brendand, could you go into more detail what you're seeing?
[16:13] <pete-woods> cjwatson: sure. it was definitely our misunderstanding regarding the attempt at landing to rtm
[16:13] <brendand> charles, hearing: an alarm. seeing: nothing
[16:14] <charles> brendand, urgh :-)
[16:14] <charles> brendand, what are you seeing this on?
[16:14] <brendand> charles, pm'ed you
[16:14] <charles> ack
[16:22] <Wellark> "Silo ready to build packages"
[16:22] <Wellark> does that mean I have to manually hit "Build" to get the first set of packages cooking?
[16:24] <rsalveti> charles: when I tested the silo alarm also worked fine for me, so it could be a different bug (not necessarily related to the silo)
[16:27] <charles> rsalveti, wfm, but my testing was on an n4
[16:28] <cjwatson> Wellark: yes
[16:28] <rsalveti> charles: mine was on n7
[16:33] <charles> rsalveti, dyk if there's a way to force a phone into suspend mode, rather than just waiting for it to happen on its own?
[16:33] <rsalveti> charles: hitting the power off button should do that
[16:33] <charles> rsalveti, that actually puts the phone into suspend mode, rather than just turning off the display?
[16:33] <charles> ok, TIL
[16:36] <charles> brendand, though, if you're getting sound but no display, this sounds like it might be a separate issue:
[16:37] <charles> if the phone was suspended, you wouldn't get either since the indicator-datetime-service process would be suspended either
[16:37] <brendand> charles, somehow i got it so that i got sound but no visuals. i thought i had powered off the phone, but that might not have been the case
[16:37] <charles> so (1) when the alarm goes off and you get sound but no display, what happens if you press the power button to get the display -- is there a snap decision? i.e., is the only failure that the display isn't comingon?
[16:38] <brendand> charles, i have it suspended now and waiting for an alarm
[16:38] <rsalveti> charles: yup, the phone will always try to suspend when there's no suspend blocker
[16:38] <brendand> charles, no - i had to hold down the power button to turn it off
[16:38] <rsalveti> charles: by default when the screen is on, the system-compositor should be holding a suspend blocker
[16:38] <charles> also (2) if you get sound-but-no-video again, what happens if you phablet-shell into it and run "powerd-cli display on"
[16:38] <brendand> rsalveti, how can i check if it is suspended?
[16:39] <rsalveti> brendand: no easy way really, you can get the info from powerd if to know if it's trying to suspend (powerd-cli list shouldn't show any suspend blockers)
[16:39] <rsalveti> but then to know if the device is in deep suspend or not is not necessarily trivial
[16:40] <rsalveti> you can check dmesg after running adb
[16:40] <rsalveti> maybe cking might have a way to know that, but you can only know after if it's suspend or not
[16:40] <rsalveti> because well, while suspend you can't access anything :-)
[16:40] <rsalveti> that's why I usually test this on flo
[16:40] <rsalveti> because there's no radio/modem (that usually keeps the device awake)
[16:48] <bzoltan1> robru:  may i get a silo for an hour or max two? line 40
[16:51] <brendand> sil2100, do we have any idea what the 'correct' number of tests run for mako is?
[16:51] <brendand> sil2100, it seems lower now than it should be
[16:51] <brendand> sil2100, the fact that calendar didn't run doesn't explain it all
[16:51] <sil2100> brendand: not sure exactly... we don't have all calendar app didn't run, and we don't have notes-app tests anymore
[16:59] <robru> ogra_: oh, why did you call my phablet-tools landing pointless? I changed it to use 'sudo' in anticipation of a rootless adb shell ;-)
[17:04] <davmor2> sil2100: why do we still have notes in the image I thought that was being dropped completely already ;)
[17:04] <sil2100> davmor2: we do?! :O
[17:05] <brendand> charles, rsalveti - so if the phone is in deep suspend i won't be able to phablet-shell to it?
[17:07] <mvo_> hm, still no slot for click ?
[17:08] <robru> mvo_: i just hit publish on one, should be free soon
[17:08] <mvo_> \o/
[17:08] <davmor2> sil2100: also just confirming popey 's finding that the only things that bugger up the lock are 2 notifications from the same system at the same time that have button interactions in them
[17:10] <sil2100> mvo_: you have a silo now, since we'll have that one silo free for blocker fixes soon
[17:10] <ogra_> robru, what would sudo achieve ?
[17:11] <ogra_> robru, that would only work if you had a sudoers file in place that sets your commands NOPASSWD
[17:11] <ogra_> or if you somehow hack a way together to echo the password into sudo
[17:12] <ogra_> robru, though i might be wrong, did you test them with the new adbd and a password set ?
[17:13] <ogra_> if it works that way it will work in the future too indeed :)
[17:15] <robru> ogra_: heh, ok. still, it fixed a long standing bug. i'll fix the rootless issue later
[17:15] <ogra_> robru, then they will stop working by end of the week
[17:16] <ogra_> (which is why i called it pointless to land the changes now)
[17:17] <charles> brendand, I think keeping the phone plugged in via usb inhibits suspend. tvoss and rsalveti would probably be able to answer this more authoritatively
[17:17] <mvo_> sil2100: \o/ thanks a lot
[17:26] <sil2100> nik90: hey, you around? :)
[17:27] <nik90> sil2100: yes
[17:27] <sil2100> nik90: so, I wanted to poke you about the calendar-app broken autopilot test that causes an infinite loop on real devices
[17:27] <robru> sil2100: ok, I added the stuff you wanted to the dashboard. global status is in the titlebar and silo tested image numbers are in the spreadsheet description per silo
[17:27] <nik90> sil2100: ooh I am not a calendar app dev, so not too familiar with it. But shoot let me see if I can help
[17:28] <sil2100> Oh, I think I heard someone mentioning that you were looking at that, but maybe it was balloons..?
[17:28] <sil2100> brendand: could you give me the bug number of the calendar issue?
[17:28] <nik90> sil2100: I was trying to help brendand since I coudn't find any calendar app dev
[17:28] <sil2100> Ah, ok ;)
[17:29] <sil2100> nik90: since if there's no calendar-app dev right now, I would even recommend an (ugly!) test-skip for now
[17:29] <sil2100> nik90: since currently this test breaks all smoketesting, as it hoggs devices until they time-out
[17:29] <nik90> sil2100: oh :/
[17:29] <sil2100> So before we kick a new image, we need to have this either fixed or skipped :<
[17:30] <nik90> balloons: you were trying to help mihir with the calendar ap tests yesterday. Do you know about the infinite looping issue ^^
[17:31] <balloons> nik90, I do ;-)
[17:31] <sil2100> plars: did you re-run the tests that didn't run yet for krillin?
[17:31] <nik90> sil2100: balloons is your man ;)
[17:32] <balloons> haha nik90 , well played
[17:32] <nik90> hehe
[17:32] <Wellark> now we are talking
[17:32] <sil2100> balloons: hi! ;)
[17:33] <sil2100> balloons: so, as mentioned above... do you know if this infinite-loop issue in calendar can be quickly fixed today? If not, I would have to ask for a skip of the test in the meantime and release to the store
[17:34] <sil2100> kgunn: about that 'nasty' workaround... how ugly would it look in code to do that actually? Is that a one-liner, or something more?
[17:34] <sil2100> kgunn: you know, the one with badly 'dropping'/'ignoring' the other notification
[17:34] <balloons> sil2100, I can prep something
[17:35] <rsalveti> charles: yes, you need to unplug the usb cable
[17:35] <rsalveti> brendand: phablet-shell will work because it requires a usb connection, and that keeps the device awake
[17:35] <rsalveti> brendand: ssh itself shouldn't though
[17:35] <rsalveti> over wlan
[17:36] <ogra_> why wouldnt ssh ?
[17:36] <ogra_> it would keep the device awake too, no ?
[17:36] <ogra_> (as long as there is data transfered)
[17:39] <plars> sil2100: yes, they are going, one sec
[17:40] <robru> brb, breakfast
[17:41] <plars> sil2100: seems to be stuck in an endless autopilot loop again :(
[17:42] <sil2100> plars: did you run the calendar-app tests as well?
[17:42] <sil2100> plars: those need to be skipped sadly...
[17:42] <plars> sil2100: I set it up to run all of them in the session that had problems
[17:42] <plars> sil2100: I'll be more selective and restart it
[17:44] <brendand> rsalveti, charles - mind if i give this silo some extra time for testing? i can't seem to reproduce the issue i found easily
[17:45] <charles> brendand, take the time you need
[17:45] <charles> brendand, if you do see the same sound-but-no-video issue, remember to try 'powerd-cli display on' when it happens
[17:46] <brendand> charles, yep
[17:50] <rsalveti> ogra_: if fully suspended ssh should in theory fail
[17:51] <rsalveti> but it seems it might work, looking at the latest email sent by cking
[17:51] <rsalveti> it seems the device wakes up to handle the package
[17:52] <tvoss> charles, rsalveti iirc adbd holds a wake-lock
[17:52] <rsalveti> yup
[18:04] <sil2100> plars: thanks :)
[18:07] <kgunn> sil2100: actually, i'm trying to test another workaround we discovered
[18:07] <sil2100> kgunn: oooh!
[18:07] <sil2100> !
[18:07] <kgunn> won't miss any notifications
[18:08] <sil2100> kgunn: any details? :) Or too busy working on it?
[18:09] <sil2100> balloons: any ETA on the calendar-app fix/workaround?
[18:09] <kgunn> sil2100: i really want to replicate per the original bug...not just the script in the mp....so, if you can find someone that'd be great
[18:09] <kgunn> https://code.launchpad.net/~macslow/unity8/disable-opacity-animation-1354406-workaround/+merge/231588
[18:09] <elopio> ping plars: I need help understanding a segfault that happens on Jenkins but not on my machine.
[18:09] <elopio> https://code.launchpad.net/~canonical-platform-qa/dialer-app/qmltests1/+merge/230412
[18:09] <elopio> do you know who can help me with that?
[18:10] <plars> elopio: is it in smoke testing that you get the segfault?
[18:10] <sil2100> popey, davmor2, om26er: can anyone of you guys help out with verifying if this branch works-around the PIN-locked issue? https://code.launchpad.net/~macslow/unity8/disable-opacity-animation-1354406-workaround/+merge/231588
[18:10] <plars> elopio: oh, I guess not
[18:10] <elopio> plars: no. I'm adding a QML test, that's run during build.
[18:13] <sil2100> popey, davmor2, om26er: please contact kgunn if you are able to help ;)
[18:14] <popey> i can't right now, am away from home for the next 3 hours at least
[18:14] <kgunn> lemme get a silo sil2100, it'll make all this easier
[18:15] <sil2100> kgunn: ah! Since we're talking about silos... is there a landing for the other blocker already?
[18:17] <kgunn> sil2100: i put them both in there
[18:17] <plars> elopio: any chance you've tried running it locally under pbuilder the way it's run there?
[18:18] <plars> elopio: if I'm looking at this right, it looks like it fails every time, on multiple systems
[18:18] <elopio> plars: I've run it with pbuilder. I'm not sure how to reproduce the exact same environment as jenkins.
[18:19] <plars> elopio: some insight from fginther:
 plars, right these builds run in a pbuilder chroot. These will inherit the environment from the parent, so if elopio is running this inside a chroot on his desktop, he may be inheriting X11 and dbus environment variables.
[18:19] <plars> elopio: ^
[18:20] <fginther`> elopio, I usually recommend to retry the build after starting an ssh session (which has a much smaller env)
[18:22] <balloons> fginther`, so I wanted to ask you about how far you got on running AP tests against a device as part of the click-building / publishing to store for the community core apps
[18:22] <fginther`> balloons, I'll have to get back to you a later, in a meeting
[18:23] <kgunn> sil2100: line 42, and yeah, i know if conflicts with 2 others...i'm just isolating the blockers
[18:24] <kgunn> robru: ^ in case sil went m.i.a.
[18:25] <davmor2> sil2100: yeap I can look at that
[18:25] <sil2100> robru: can you assign a silo? Do we have something free? ;) If not, deploy preprod to cupstream2distro trunk and assign it ;p
[18:26] <sil2100> davmor2: thanks! It should be in a silo soon
[18:28] <davmor2> sil2100: Meh I thought it already was.  ToyKeeper, om26er guys I knock off at 20:00 today and it is 19.27 could one of you guys test this silo once the package builds please if I miss it.  Basically set the lock and then se t 2 alarms for the same time and wait for the to go off.
[18:28] <davmor2> try and unlock the phone
[18:29] <om26er> davmor2, ok
[18:29] <ToyKeeper> davmor2: That's silo 10?
[18:29] <ToyKeeper> Surprised it didn't land while I was asleep.
[18:29] <davmor2> ToyKeeper: it's not in a silo yet
[18:29] <ToyKeeper> Oh.
[18:30] <davmor2> ToyKeeper: that's why I'm assuming I might not be here by the time it builds in the silo :)
[18:30] <robru> kgunn: sil2100 there are in fact 0 silos available
[18:30] <robru> however silo 5 should finish landing shortly
[18:31] <sil2100> Ok, hmmm
[18:31] <ToyKeeper> I'm surprised I'm even awake...  up late, half a night of fitful sleep, woken early for errands, and now starting a long long shift while still feeling kind of sick.  It's going to be a long day.
[18:31] <robru> ToyKeeper: up... late? this is the earliest I've ever seen you online...
[18:31] <kgunn> dude...the calendar is super wonky
[18:32]  * kgunn feels slightly mistreated on a blocker when the damn thing doesn't sync proper
[18:33] <robru> kgunn: argh, sorry you're not getting a silo, not sure if any are bumpable (there probably are, i just don't know which)
[18:34] <robru> sil2100: what's up with silos 9 and 14? they don't need QA?
[18:34] <sil2100> robru: I guess they might, I didn't see those
[18:34] <sil2100> robru: they weren't ready yet before so I didn't set the tags for those
[18:34] <robru> sil2100: oh, i'm publishing pitti's langpacks, since those are trivial and apparently qa already acked anyway
[18:35] <sil2100> Wait!
[18:35] <sil2100> NO!
[18:35] <robru> sil2100: maybe we should change the "QA required?" to a global check rather than a per-silo check?
[18:35] <sil2100> Dooooon't!
[18:35] <robru> sil2100: what? too late. crap
[18:35] <sil2100> CRAP
[18:35] <robru> sil2100: oh no
[18:35] <robru> sil2100: it errored
[18:35] <robru> sil2100: it's ok
[18:35] <sil2100> Phew
[18:35] <robru> sil2100: saved by an unapproved MP
[18:35] <robru> sil2100: what's the problem?
[18:36] <sil2100> robru: ok, don't publish that for now, I mean it won't be a tragedy! But we agreed with pitty that we'll publish that after promotion ;)
[18:36] <sil2100> It's nothing really bad but yeah, it would mean we would get rid of most translations for all those apps
[18:36] <robru> sil2100: oh but it's just sitting there taking up a silo for a trivial diff... bah
[18:37] <sil2100> Yeah, but I would prefer us to have translations in our promoted image ;)
[18:37] <sil2100> Not a critical thing if they're gone, but still!
[18:38] <robru> sil2100: landings 1 and 11 are the stalest, do you know of any reason we can't free those?
[18:38] <balloons> sil2100, https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/skip-edit-test/+merge/231606. But it would be best to find a workaround if possible
[18:41] <sil2100> balloons: ok, what I would propose is getting this merged anyway right now and just continue working on a workaround
[18:41] <sil2100> balloons: since as I said, currently our smoketesting is basically broken because of this
[18:41] <sil2100> So we cannot even build a new image, since smoketesting would hang
[18:42] <sil2100> elopio: could you take a look at this? https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/skip-edit-test/+merge/231606
[18:42] <sil2100> robru: could you track calendar-app and if this gets merged, make sure it gets to the store?
[18:43] <sil2100> robru: once it's in the store it would be nice to have an image
[18:43] <sil2100> (or just wait for cron if it's too late)
[18:43] <robru> sil2100: is that in a silo?
[18:43] <elopio> sil2100: I thought somebody was working on the right fix. Would you give me some time to properly fix it, or is it urgent now?
[18:43] <sil2100> elopio: yes, it's very urgent, as it breaks smoketesting
[18:44] <robru> bfiller: are you actively testing silo 11? it seems quite stale and we're out of silos. mind if I free that one?
[18:44] <sil2100> elopio: that's why I would prefer it to be at least worked-around for now, jsut in case the real fix would take longer than the next image builds
[18:44] <bfiller> robru: that's fine
[18:44] <sil2100> robru: it's a click package, so balloons would have to do all the build magic for that
[18:44] <elopio> sil2100: ok then. I'll approve this one, report a bug and link it to the removed tests blueprint.
[18:44] <balloons> I just proposed the skip as a backup under the assumption we can't produce a workaround
[18:44] <balloons> I need to reproduce it still
[18:45] <sil2100> balloons: brendand mentioned it's reproducible everytime on devices
[18:45] <sil2100> Ok, need to EOD now ;)
[18:45] <sil2100> robru: I leave things in your hands! I expect a PERFECT image when I wake up in the morning - no blockers, no autopilot issues!
[18:46] <robru> sil2100: oh yeah totally
[18:46] <sil2100> ;)
[18:46] <robru> sil2100: i mean I coulda done that all along, but I didn't.
[18:47] <sil2100> hah
[18:48] <sil2100> o/
[18:59] <robru> ok, well I gotta run to the doctor for a bit, hopefully QA will have signed off on some stuff to publish when i get back...
[19:15] <rsalveti> davmor2: if you get time still, mind validating silo 02? you kind of tested it already
[19:15] <rsalveti> otherwise I guess I could ask ToyKeeper
[19:16] <davmor2> is that the mic gain silo,  if so then myself and brendand tested that, or did you add more code?
[19:16] <brendand> davmor2, yeap
[19:17] <brendand> davmor2, rsalveti - i'd really like to get that landed, it blocks our operator testing
[19:17] <davmor2> rsalveti: did you add code to it from yesterday if not then I'm happy it didn't break anything
[19:18] <davmor2> cyphermox: the mtp silo can that be landed or are you doing more work to it?
[19:18] <cyphermox> davmor2: just about ready, I had minimal review changes to make from mandel
[19:19] <davmor2> cyphermox: nice :)
[19:19] <cyphermox> we out of traincon-0 yet? :)
[19:19] <davmor2> cyphermox: no
[19:20] <brendand> plars, ubuntu_terminal_app didn't get run today
[19:21] <plars> brendand: looking
[19:21] <brendand> plars, oh wait yeah it did
[19:25] <davmor2> brendand: give me a number quick
[19:26] <robru> rsalveti: is silo 2 almost ready to land? Would love to free a silo! ;-)
[19:27] <davmor2> robru just double checking it now
[19:28] <robru> davmor2: sweet!
[19:39] <davmor2> rsalveti, robru: just granted silo2 sounds good to brendand and me
[19:40] <robru> davmor2: thanks!
[19:40] <davmor2> robru: now just bug rsalveti to do whatever with it so it lands already.
[19:40] <davmor2> I'm calling it a night 04:30 start tomorrow :)
[19:41] <robru> davmor2: oh i'm doing that
[19:41] <robru> kgunn_: still around? i have a silo freeing up
[19:41] <kgunn_> robru: ta
[19:46] <mvo_> silly(?) questin, but how do I find out if I need qa-sign off?
[19:47] <mvo_> (for line  #39, slio 006)
[19:47] <robru> mvo_: we're in traincon, so anything that isn't an isolated bugfix requires QA signoff. all new features and new "upstream releases" require QA
[19:49] <mvo_> robru: all right, so I just need to wait? or is there anything I can further help with?
[19:49] <mvo_> (for this to land I mean)
[19:52] <robru> mvo_: poke ToyKeeper to do the QA review I guess. or brendand
[19:53] <mvo_> robru: thanks! I will wait with the poking until tomorrow I think, its getting late here :)
[19:53] <robru> mvo_: ok cool. does this landing fix any blocker bugs? or just new features/
[19:54] <mvo_> robru: the new signature feature and a feature to make retracing easier, so no critical fixes.  the signature feature is required for rtm  though
[19:55] <mvo_> robru: signed click packages I should say
[19:55] <robru> mvo_: ok, no worries. we can land it but it just won't be a priority over the critical things I'm trying to shepherd in
[19:57] <robru> kgunn_: ok you got silo 5! sorry for the delay!
[19:57] <mvo_> robru: thanks, yeah, definitely not a priority plus it has breakage potential (but my tests are good so it shouldn't realize this potential, fingerscrossed and all that :)
[19:57]  * mvo_ really calls it a day now
[20:00] <kgunn_> robru: ta
[20:01] <robru> kgunn_: you're welcome!
[20:14] <rsalveti> robru: davmor2: yeah, it was ready to be landed
[20:14] <rsalveti> guess that already happened :-)
[20:14] <rsalveti> robru: thanks for triggering build with watch-only
[20:14] <rsalveti> forgot about that
[20:15] <robru> rsalveti: no worries, just about had a pregnant when i tried to publish and it failed. Would have hated to tell you to retest everything ;-)
[20:38] <balloons> robru, can you approve? https://myapps.developer.ubuntu.com/dev/click-apps/156/changerequest/
[21:01] <robru> balloons: sorry I'm afk, can do it in an hour or so... Can you find somebody else?
[21:02] <robru> balloons: actually sorry i don't even know what that url is, i guess you need popey ?
[21:03] <balloons> robru, ohh you have no powers eh? then yep, popey it is
[21:03] <balloons> I thought perhaps cyphermox can do it too?
[21:03] <balloons> https://myapps.developer.ubuntu.com/dev/click-apps/156/
[21:03] <cyphermox> I can check it out
[21:04] <robru> balloons: all my powers are in launchpad, got nothing in the click store... I can't remember who the other click store guy is, maybe dpm?
[21:04] <balloons> robru, indeed I was right, it's cyphermox :-)
[21:05] <cyphermox> well, I know nothing of the click store really
[21:05] <cyphermox> but I can try to help out
[21:05] <robru> cyphermox: nah we need somebody with magic perms
[21:09] <cyphermox> pmcgowan might know who should do this
[21:12] <pmcgowan> balloons, is that to approve an app submission?
[21:13] <balloons> pmcgowan, indeed.. popey can do it, and I thought cyphermox could also.. who's the us approver then if not you cyphermox ?
[21:14] <pmcgowan> I am surprised balloons cant
[21:15] <balloons> it's a 2 step thing and we split the roles
[21:15] <balloons> I can upload, but not approve..
[21:16] <pmcgowan> balloons beuno approved it
[21:17] <balloons> :-) he's another one
[21:17] <cyphermox> should I really be able to approve these things? I don't mind, but I know I don't have access to it and probably missing some training
[21:24] <kgunn_> ToyKeeper: sorry about your rough night last night...do you have it in you to test for silo5....its a silo that fixes the 3 blockers
[21:29] <ToyKeeper> kgunn_: Woot!
[21:30] <ToyKeeper> kgunn_: I'll get right on it.  :)
[21:30] <kgunn_> thanks (fingers crossed)
[21:32] <veebers> robru: hey, do I need to do anything extra for line 22? (it's actually a desktop only release too)
[21:39] <popey> evening all
[22:19] <robru> veebers: sorry I'm afk. Are you talking about silo 1? Surely ap affects the phone as well? ;-) i can publish when i get home as long as you're confident in the quality.
[22:27] <veebers> robru: no worries, no I'm talking about the autopilot-legacy line that doesn't currently have a silo allocated
[22:28] <robru> veebers: oh OK, well i could assign it but there's nothing free at the moment.
[22:28] <veebers> robru: ack, fair enough. I hope to put silo1 into 'tested' very soon
[22:29] <robru> veebers: great to hear it!
[22:31] <ToyKeeper> kgunn_: So, still finishing tests but it looks good so far.  Only saw one weird quirk and it wasn't reproducible.
[22:31] <kgunn_> ToyKeeper: yep, its all looking good to me, just running through AP tests
[22:31] <ToyKeeper> kgunn_: The weird quirk was that on one device, only one time, I couldn't change the time zone after installing the silo.
[22:32] <kgunn_> huh...
[22:32] <ToyKeeper> Like, tapping the zone appeared to register a tap but not an untap, so it never completed the action.
[22:32] <kgunn_> ToyKeeper: i've been futzing with settings, calendar abunch today as you can imagine...and i kinda suspect there's a deeper core issue going on
[22:32] <ToyKeeper> After a reboot though, I couldn't get it to happen again.
[22:32] <kgunn_> before i tested the silo, i noticed lots of oddities around calendar
[22:33] <ToyKeeper> I doubt it's related.  I've seen similar issues before and again could never do it on purpose.
[22:33] <kgunn_> ToyKeeper: speaking of, do you know how to run calaendar AP test ??
[22:33] <kgunn_> i don't see it in the wiki i use
[22:33] <ToyKeeper> kgunn_: The intarwebs suggest this: phablet-click-test-setup --click com.ubuntu.calendar;         phablet-test-run -p address-book-service-dummy calendar_app
[22:33] <ToyKeeper> https://wiki.ubuntu.com/Touch/Testing
[22:33] <kgunn_> thanks
[22:34] <ToyKeeper> I haven't tried it yet though.
[22:34] <kgunn_> ever ?
[22:34] <ToyKeeper> Well, not recently...  which, at the speed things are moving, may as well be ever.
[22:34] <kgunn_> :)
[22:39] <robru> rsalveti: looks like pulse is stuck in proposed due to regressing kde. Can you investigate? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-kde-runtime/lastBuild/ARCH=amd64,label=adt/ something about unsatisfiable depends, not sure why.
[22:39] <rsalveti> regressing kde?
[22:39] <rsalveti> wtf
[22:39] <rsalveti> 18741 qemu: terminating on signal 15 from pid 79104
[22:39] <robru> rsalveti: yep, the autopkgtest said so. Might be transient, dunno.
[22:40] <rsalveti> robru: it seems the test run failed because of that ^
[22:40] <robru> rsalveti: but just before that it says unsatisfiable dependents
[22:40] <rsalveti> oh right
[22:40] <rsalveti> hm
[22:40] <rsalveti> that doesn't help me
[22:41] <robru> rsalveti: i find pitti is the most helpful person for autopkgtests ;-)
[22:41] <rsalveti> robru: I don't even know what to look for
[22:42] <robru> rsalveti: me either... Do you have a vm to test in? I might be able to poke at it when i get home, just at the dr right now.
[22:42] <rsalveti> wonder if a side effect of the latest autopackage test upload done by pitti
[22:43] <rsalveti> or maybe just a side effect of the current archive state
[22:44] <rsalveti> robru: I need to leave in a few, so would be nice if you could give it a try later
[22:44] <rsalveti> I should be back in ~2 hours
[22:44] <robru> rsalveti: yeah i should be home in an hour.
[22:44] <rsalveti> robru: can someone at least retry the job?
[22:45] <rsalveti> just to make sure it's not a temporary thing
[22:45] <robru> rsalveti: yeah not sure who. I guess we need a core Dev for that
[22:45] <rsalveti> it seems it's broken for a few already
[22:45] <rsalveti> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-kde-runtime/
[22:45] <rsalveti> well, I'm a core dev, let me see
[22:45] <robru> infinity: are you around to retry an autopkgtest in proposed? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-kde-runtime/lastBuild/ARCH=amd64,label=adt/
[22:46] <rsalveti> it is broken for quite a few hours
[22:46] <rsalveti> robru: yeah, broken for a few hours already and with the same message
[22:47] <rsalveti> since ~7 hours ago
[22:47] <robru> Oh good. Glad that's blocking us then
[22:48] <rsalveti> too bad the log doesn't even say the broken dependencies
[22:49] <rsalveti> robru: jenkins is not connected with sso, so I don't think I even have an account in there
[22:51] <rsalveti> http://paste.ubuntu.com/8101703/
[22:51] <rsalveti> what changed from the working version to the first broken one
[22:51] <rsalveti> new util-linux and dbus
[22:52] <rsalveti> minor things :P
[22:53] <rsalveti> bbl
[23:13] <Ursinha> I wonder why that error message doesn't contain the full command line that caused the failure, or at least the dependencies in that context
[23:19] <ToyKeeper> kgunn_: The spreadsheet has no status for "testing pass?" on silo 005.  Are you still testing?
[23:20] <kgunn_> ToyKeeper: was just about to flip the switch i ran a ton of the AP tests....last one just finishing
[23:20] <kgunn_> but all is good
[23:20] <ToyKeeper> kgunn_: As far as I can tell, even if it's not a real fix, it still seems to be made of win as far as the current blockers are concerned, and I think we should land it ASAP.
[23:20] <kgunn_> yep...will flip it now
[23:21] <kgunn_> done!
[23:22] <ToyKeeper> ... and if someone kicks off a build soon (or cron, whatever), I can most likely go ahead and approve the image for promotion...  assuming nothing else explodes.
[23:24] <ToyKeeper> Until then, I think this might be a good time for lunch.
[23:24] <robru> cyphermox: you around? Can you publish silo 5? I'm away from my laptop right now.
[23:24] <cyphermox> sure
[23:24] <cyphermox> I'll look at it, did you do any review yet?
[23:26] <rsalveti> I'd block cron until this issue is sorted out (that is blocking pulse migration)
[23:26] <rsalveti> brb, dinner :-)
[23:29] <cyphermox> robru: that was a fix for traincon0?
[23:31] <robru> cyphermox: yeah, like all of the blockers ;-) thanks!
[23:31] <cyphermox> k
[23:40] <robru> rsalveti: what's the worst possible outcome of an image build that has your silo but is missing pulse? Will audio be totally broken, our just alarms, or what?