[02:04] <imgbot> [02:44] <AlbertA2> cihelp: were are hitting an issue with the mir autolander
[02:44] <AlbertA2> cihelp: /runscript: line 10: mk-build-deps: command not found
[02:45] <AlbertA2> cihelp: https://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/1717/console
[02:45] <fginther> AlbertA2, looking
[02:45] <AlbertA2> fginther: ack
[02:49] <fginther> AlbertA2, I've made a change to fix this and am retesting. I enabled some new build slaves today and it appears they aren't properly setup for these jobs yet. I've reconfigured them to run only on the old hardware until I can fix the missing dependencies
[02:50] <fginther> AlbertA2, This applies to the mir-android-utopic-i386-build job as well
[02:50] <AlbertA2> fginther: ok thanks!
[02:50] <fginther> AlbertA2, sorry for the inconvenience, I'll add these jobs to my test set for the next round of slave updates
[02:51] <AlbertA2> fginther: np
[03:04] <imgbot> [03:45] <Mirv> mornings
[03:49] <imgbot> [03:49] <imgbot> [03:50] <bzoltan> ToyKeeper: I git might nightly tests with the RTM image -> http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/ Check the ap-2014_09_10-19_29_44.MAIN-LOGS.tests for the summary. I think it has the same failures as th stock image without the release candidat UITK.
[03:51] <bzoltan> ToyKeeper:  it was on RTM image #32
[04:07] <bzoltan> Mirv:  I have two RTM silos waiting for QA signature... the first one I tested on #22 and the second on #32
[04:10] <Mirv> bzoltan: ok. it'd be useful to get the utopic release published first.
[04:11] <bzoltan> Mirv:  that one is a clear case after I have now top approved the MRs
[04:11] <Mirv> bzoltan: ok, thanks. I'll try publishing it then.
[04:12] <Mirv> not that QA would look at the second rtm landing anyhow before the first one is done, of course..
[04:12] <bzoltan> Mirv:  thank you. I will bug the QA folks to take the RTM UITK in queue.
[04:13] <bzoltan> Mirv:  I do not see any point of releasing the first one to be honest. Or of course it is OK to releas it and in 5 seconds later release the second one. The first one can even cause killer regression because the second will fix it :D One think would be total waste of that ... re-validatinng both
[04:14] <bzoltan> Mirv:  I think the UITK is the only project what does this level of pre-release testing -> http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/
[04:35] <Mirv> bzoltan: that's indeed probable..
[04:52] <Mirv> cyphermox_: just so you know, your upstart publishing did not publish anything, another "new normal" for CI Train. you need to watch that there's that rsync generated, otherwise you'll need to go to build watch_only and possibly reconfigure dance.
[04:53] <Mirv> robru: ^ so that's another example of how rtm landings don't land.
[04:54] <Mirv> I know to watch for it, but not necessarily all people doing publishing
[05:24] <ToyKeeper> bzoltan: Do you have the camera app tests enabled?  Everything looked good except for a new failure on the camera app.
[05:28] <bzoltan> ToyKeeper:  the camera app tests have not even started
[05:30] <ToyKeeper> bzoltan: Okay, just wondering because it looked like it didn't run.
[05:30] <bzoltan> ToyKeeper: I hav attempted to run the camera app tests 50+ times this week. It hangs or does not even start. So I removed it from the test lists. It should not block the UITK
[05:31] <Mirv> looks like ToyKeeper has conquered the mountain of validating UITK release
[05:31] <bzoltan> ToyKeeper: http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/ap-2014_09_10-19_29_44-camera_app-1.tests as you see
[05:31] <ToyKeeper> bzoltan: I haven't had issues getting the camera tests to run, but it was 1/12 failed pre-silo and 2/12 post-silo.
[05:32] <Mirv> and mtp too, and I get to do the so-called "train dance" again it seems
[05:32] <bzoltan> ToyKeeper: Mirv: But I am still on the opinion that the QA validation should not repeat what I do .
[05:32] <ToyKeeper> I then tested that part of the camera's functions manually and it seems fine so I passed it anyway.
[05:32] <Mirv> it's a secretive ritual where packages get published with a ceremony of jobs
[05:32] <Mirv> which vary from case to case
[05:33] <ToyKeeper> bzoltan: The reason UITK was delayed was because the test results didn't match, so I investigated why.  I found out that what you were running was very different than the test plan given to QA, which makes it an automatic fail.  But instead of failing it, I tried to resolve the issue.  Still working on that, actually.
[05:34] <bzoltan> ToyKeeper:  keep in mind that I am testing 20+ apps ... 800+ test cases. Flakiness and instability of apps causes surprises all the time. If any random app's random test would bock the UITK then we stil would be on the 0.000011 version :)
[05:35] <bzoltan> ToyKeeper:  No, I have run exactly the test plan.
[05:35] <ToyKeeper> I found some pretty significant differences, big enough to invalidate the results.  Like installing bits from the wrong package feed.
[05:36] <bzoltan> ToyKeeper:  the test plan was to run the AP tests for a list of apps ... the test plan does not define for any test plan how the tests are run
[05:36] <bzoltan> ToyKeeper: what bits and what package feed?
[05:37] <Mirv> please ignore the train comments. mtp was ~easy, the uitk needs bigger weapons
[05:37] <ToyKeeper> The click setup was pulling files from the non-rtm feed, then testing them on a rtm image, producing meaningless results.
[05:37] <bzoltan> Mirv: :) OK
[05:38] <bzoltan> ToyKeeper: that is a phablet-click-test-setup bug ...
[05:38] <bzoltan> ToyKeeper:  this is not the first time that a phable tool bites the SDK
[05:39] <bzoltan> ToyKeeper:  I wish to have a test plan and QA validation for the phablet tools ... I cook from what is given to me.
[05:40] <ToyKeeper> bzoltan: You might want to talk with jfunk or perhaps asac about the intended role for QA in the landing process.  The idea isn't for developers to test some parts and QA to test the other parts.
[05:40] <bzoltan> ToyKeeper: But I got your point. The 05.09 landing I have validated with the right click setup.
[05:41] <ToyKeeper> The reason for traincon 0 (and the similar rtm landing process) was because people weren't even running the tests, or didn't understand what needed to happen, so QA got involved to fix the process issues and help get everyone on the same page.
[05:41] <bzoltan> ToyKeeper: You do awesome job to secure the quality.
[05:41] <bzoltan> ToyKeeper:  fixing the problems I would start releasing proper tools what the devs should use to validate their MRs
[05:42] <ToyKeeper> bzoltan: I hear there is an effort in progress to run the CI tools against every MP so it'll have those results before landing.
[05:42] <ToyKeeper> Not quite the "make CI work for individual use on local devices" I had in mind, but still good.
[05:42] <bzoltan> ToyKeeper:  I am running the tests 24/7. In the last 24 hours I have 5 tims the ful UITK test plan. But unreliable test tools and flaky AP tests can indeed show strange results.
[05:43] <bzoltan> ToyKeeper:  But devs are expected to run tests locally
[05:45] <ToyKeeper> I'm hoping the tools will also be made robust for personal use.
[05:47] <bzoltan> ToyKeeper: We had talked about it with the QA team on the last sprint. I have proposed to require the same quality standards from the phablet tools as we require from the apps and other  components.
[05:47] <ToyKeeper> QA has had a lot less time for tooling lately though, due to the need to check each silo.  :(
[05:48] <bzoltan> ToyKeeper:  for example I did not know that phablet-click-test-setup does not work on the RTM image with the default parameters as it works on the ubuntu image.
[05:49] <ToyKeeper> A lot of rtm infrastructure was put together in a hurry, I'm not surprised the auto-detection didn't get implemented.
[06:19] <robru> Mirv: can you elaborate on this "new normal"? I thought the issue was that it reports successful migration immediately, and then you unsuspectingly free the silo before it is really copied. I'm not aware of any issues where it fails to publish even if you just give it time before freeing.
[06:19] <robru> Aren't we expecting sil back today? Shouldn't he be on by now?
[06:27] <robru> Mirv: Ooooooooooh, just saw your email, thanks for that
[06:29] <Mirv> robru: you're welcome :)
[06:29] <Mirv> those are the usual cases
[06:30] <Mirv> sil2100 should be around today, but he usually is around in about 30min - 1h from now
[06:46] <robru> Ah OK
[06:49] <sil2100> o/
[06:51] <robru> sil2100: Heyo
[06:52] <robru> sil2100: welcome back, i hope you had a restful week ;-)
[07:13] <Mirv> sil2100: welcome back!
[07:14] <Mirv> dbarth: shall we get the testing done for rtm silo 017 today? since it's blocking that already (upstream) tested unity8 landing from going to QA signoff phase
[07:33] <dbarth> Mirv: hi
[07:34] <dbarth> Mirv: i need to ask someone else with an rtm installed; hold on
[07:34] <sil2100> robru: hey! You feeling better now?
[07:36] <robru> sil2100: yeah but just barely, thanks
[07:39] <robru> sil2100: I didn't get as much done with the train as I'd wanted, but I fixed some stuff and I got some tests in. Please skim over my recent commits when you get a break from the landing craziness
[07:39] <sil2100> robru: thanks, will do! Did you manage to do the big args-to-env change?
[07:40] <robru> sil2100: that was the first thing I accomplished ;-) so happy to see that code gone!
[07:40] <Mirv> dbarth: thanks
[07:42] <ogra_> hmm
[07:42] <ogra_> something got seriously out of sync ...
[07:42] <ogra_> rtm images failed
[07:42] <robru> sil2100: you won't recognize the deploy script ;-) just wish I had been healthy enough to make those kinds of changes everywhere
[07:44] <ogra_> seems ubuntu-touch is uninstallable in rtm
[07:44] <robru> sil2100: OK, bedtime for me, good luck today!
[07:44] <sil2100> robru: no worries, let me take a look - we'll have time to do that next week still
[07:44] <sil2100> robru: goodnight! :)
[07:45] <sil2100> ogra_: oh, does it say why?
[07:45] <ogra_> well, apt is as informative as ever  :P
[07:45] <ogra_> http://paste.ubuntu.com/8316717/
[07:46] <brendand> bzoltan, i see you have another silo ready - i would *really* appreciate those logs for the tests you ran - please
[07:46] <bzoltan> brendand:  as we agreed yesterday: http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/
[07:46] <Spads> 5.8G    ./var/lib/jenkins/silos/ubuntu-rtm/landing-017
[07:46] <Spads> That's a lot for this system
[07:47] <brendand> bzoltan, great! keep doing that :)
[07:48] <brendand> bzoltan, as a reward i will test your silo :)
[07:49] <bzoltan> brendand:  I will do that from now. Thanks for testing the silo. if you need any help please shoot.
[07:50] <ToyKeeper> bzoltan: Quick question...  silo rtm/landing-009 says it was tested on rtm image 32, but image 30 is still building.  How did that happen?
[07:50] <brendand> ToyKeeper, mako probably
[07:50] <brendand> bzoltan, we really do prefer you test on krillin if possible, but if not mako is acceptable
[07:51] <bzoltan> brendand:  I would happily test on krilling if I would have one. It is coming as I have heard.
[07:51] <Mirv> Spads: it's Oxide in there at the moment..
[07:51] <brendand> bzoltan, you could add a reference to that location on the test plan
[07:51] <Spads> Mirv: is it going to go out any time soon?
[07:51] <brendand> bzoltan, fair enough then - no problem
[07:52] <Spads> and yeah: 3.6G    ./var/lib/jenkins/silos/ubuntu-rtm/landing-017/build/oxide-qt
[07:52] <Mirv> Spads: as soon as possible we hope, but upstream tests it today and then QA needs to test and sign it off
[07:52] <Spads> I only ask because it makes the backups unusually large as well, and that builds up over a week
[07:52] <Spads> but if this is the normal operating size of things for ci-train, maybe the backup policy needs to be revisited
[07:53] <ToyKeeper> brendand: If you prefer, I could start the UITK tests running before I go to bed.  I still have everything open and set up from last time.
[07:53] <ToyKeeper> brendand: If not, you might want to look at this for some possibly-helpful changes: lp:~toykeeper/ubuntu-ui-toolkit/test-plan-qa-changes
[07:53] <brendand> ToyKeeper, if you're confident there won't be any hiccups, sure
[07:54] <ToyKeeper> brendand: No, not really confident.  There are a *lot* of test failures each time, and many of them change with each test run.  It's difficult to get silo-vs-baseimage results which can be compared.
[07:55] <brendand> ToyKeeper, i may as well do it then
[07:55] <brendand> ToyKeeper, should that script just run unattended?
[07:55] <Mirv> ogra_: it looks like rsyslog from last night's landing is stuck in rtm proposed
[07:55] <ogra_> Mirv, gah
[07:56] <ogra_> thanks for spotting that
[07:56] <brendand> ToyKeeper, where does it install the silo?
[07:56] <ogra_> did we have a new UITK ?
[07:56] <ToyKeeper> brendand: Bottom section of this: https://wiki.ubuntu.com/Process/Merges/TestPlan/ui-toolkit
[07:56] <ogra_> seems that dropped 200 tests
[07:57] <Mirv> ogra_: in rtm, only after the image build
[07:57] <ogra_> Mirv, right, i'm looking at 235
[07:57] <ogra_> which had it before
[07:58] <ogra_> bzoltan, http://ci.ubuntu.com/smokeng/utopic/touch/mako/235:20140910:20140903.1/10335/ubuntuuitoolkit/
[07:58] <ogra_> Total tests:	27
[07:58] <ogra_> i assume that should be one or the other test more
[07:58] <ToyKeeper> brendand: The provisioning for UITK tests is a little more complicated than other projects, and some things need to happen in a different order.
[07:59] <bzoltan> ogra_:  yeah, a few more ... like 270+ more
[07:59] <ogra_> heh, thought so
[07:59] <bzoltan> ToyKeeper: brendand: for the UITK testing I would recommend the script in the UITK project.
[08:00] <ToyKeeper> bzoltan: Indeed.  Just not necessarily the provisioning / commissioning parts.
[08:00] <bzoltan> ToyKeeper:  I would say that especially that one
[08:01] <bzoltan> ToyKeeper:  the most important is to remove the UITK tests from the ~phablet/autopilot/
[08:02] <bzoltan> ToyKeeper:  so that you actually test with the release candidate and not with the archive AP tests
[08:02] <bzoltan> ToyKeeper:  also, the gallery-app bug can still cause surprises .. so removing the cache could save a day
[08:04] <brendand> ToyKeeper, see ogra_ 's comment - did you notice that?
[08:04] <bzoltan> brendand: ToyKeeper: but the killer of all automatic provisioning is this one -> https://bugs.launchpad.net/ubuntu-rtm/+source/base-files/+bug/1361213
[08:04] <ubot5`> Ubuntu bug 1361213 in software-properties (Ubuntu RTM) "add-apt-repository doesn't work" [High,New]
[08:04] <brendand> bzoltan, you don't need to tell me - look at the reporter :/
[08:04] <bzoltan> brendand:  I know :)
[08:04] <ToyKeeper> bzoltan: That add-repo bug is trivial to work around.
[08:05] <bzoltan> ToyKeeper:  Good to know :)
[08:05] <brendand> ToyKeeper, yeah it's not difficult but still annoying
[08:05] <bzoltan> ToyKeeper:  would you please share :)
[08:05] <ToyKeeper> echo URL > /etc/apt/sources.list.d/foo.list ; apt-get update
[08:05] <sil2100> ogra_: no UITK release in #235, I wonder why we only got 27 tests there
[08:06] <ogra_> Mirv, so i wonder if we could just sync dbconfig-common from utopic, that should release rsyslog
[08:07] <bzoltan> ToyKeeper:  ehh.. I though there is a real one :) That one I know
[08:07] <ToyKeeper> echo "deb http://ppa.launchpad.net/ci-train-ppa-service/landing-$silo_number/ubuntu-rtm 14.09 main" > /etc/apt/sources.list.d/rtm-"$silo_number".list
[08:11] <ogra_> brendand, davmor2, seen bug 1367916 ?
[08:11] <ubot5`> bug 1367916 in messaging-app "Phone freezes when trying to active the dialer app from the messaging menu" [Undecided,New] https://launchpad.net/bugs/1367916
[08:12] <psivaa> ogra_: brendand : Mirv: sorry dint read all the backlogs, but do you see  issues seen in flashing devices with utopic-proposed both krillin and mako (rtm -29 and utopic-236?
[08:13] <ogra_> psivaa, i did an OTA ... whats your issue ?
[08:13] <brendand> ogra_, can't say i have, but i'll check
[08:13] <brendand> ogra_, what i did see though is that something broke trust-store location prompts
[08:13] <ogra_> again ?!?
[08:13] <ogra_> geez
[08:13] <ToyKeeper> Okay, updated the wiki page for UITK test plan, fixed two things I missed while writing it.
[08:13] <brendand> ogra_, this time on krillin
[08:13] <brendand> ogra_, before it was only mako
[08:14] <ogra_> oh, i thought it was there on krillin too
[08:14] <ogra_> at least during the tests
[08:14] <brendand> ogra_, depends on the issue we're talking about
[08:14] <psivaa> ogra_: this was fresh flashing with --wipe, we have 6 devices out during flashing
[08:14] <psivaa> ogra_: 3 krillins and 3 makos
[08:15] <brendand> ogra_, i'm talking about the one we found when we promoted the last mako image
[08:15] <ogra_> psivaa, damn
[08:15] <psivaa> ogra_: yea, curious if someone try locally and send out an email if it's confirmed?
[08:15] <vila> psivaa: only 6 ? nagios seems to report far more than 6 no ? Including flo
[08:16] <brendand> psivaa, flashing utopic?
[08:16] <ogra_> brendand, yeah
[08:16] <sil2100> Are there problems with flashing utopic?
[08:16] <psivaa> vila: i haven't crawled my way upto flo yet
[08:16] <brendand> haven't tried that recently
[08:16] <psivaa> brendand: yes
[08:17] <brendand> psivaa, mako too?
[08:17] <psivaa> brendand: yes
[08:17] <psivaa> brendand: both krillin (with image-29) and mako (with image 236)
[08:18] <sil2100> psivaa: flo and manta are ok?
[08:18] <psivaa> sil2100: i haven't yet checked them, but vila reports they are down too
[08:18] <psivaa> sil2100: and welcome back
[08:19] <sil2100> psivaa: thanks :)
[08:19] <sil2100> The UITK run for #235 looks strange
[08:22] <brendand> sil2100, there was a landing
[08:22] <brendand> ToyKeeper, still here?
[08:22] <ToyKeeper> brendand: Yes, briefly.
[08:22] <sil2100> brendand: I checked the changelog and commitlog for #235 and there was nothing
[08:22] <sil2100> brendand: at least not directly touching UITK
[08:24] <brendand> sil2100, oh so it didn't land there?
[08:24] <brendand> ToyKeeper, when did you pass uitk?
[08:24] <sil2100> brendand: we're talking about utopic here
[08:24] <sil2100> Not RTM
[08:25] <ToyKeeper> brendand: After the image started building.  But I didn't see that there was another UITK silo until afterward.
[08:25] <ogra_> psivaa, bah, doesnt boot
[08:25] <brendand> sil2100, oh i see
[08:26] <ogra_> psivaa, sitting at the google logo
[08:26] <brendand> sil2100, well i wipe my hands of your utopic :)
[08:26] <psivaa> ogra_: right, i think that's the issue that we are seeing. 14 devices with upstream merger jobs too
[08:26] <ogra_> damn
[08:26] <Mirv> ogra_: dbconfig-common? utopic has a version of it from 2011
[08:26] <davmor2> ogra_: yes I can reproduce that bug, The number is being added to the emergency dialer which is why it looks like it is frozen, if you exit the emergency dialer and log in the number is in the dialer in the real session and works as expected
[08:27] <ogra_> Mirv, well, rmadison doesnt think it is in rtm ... and rsyslog-mysql|-psql depends on it
[08:27] <Mirv> ogra_: right, it doesn't exist _at all_ in rtm
[08:27] <ogra_> davmor2, sound like i heard that before, is that an old bug ?
[08:27] <Mirv> so hmm I guess that'd be it
[08:28] <ogra_> right
[08:28] <ogra_> just pull it in and we should be good
[08:28] <davmor2> ogra_: not that I'm aware of
[08:28] <ogra_> k
[08:29]  * ToyKeeper -> sleep
[08:30] <ogra_> psivaa, it booted now ... butu it took very very long
[08:32] <ogra_> psivaa, hmpf, i fear thats my fault ... the emulator fix seems to turn off adb on boot
[08:33] <psivaa> ogra_: ack, that means we have a fix on the way :)
[08:34] <bzoltan> ogra_:  how to turn the developer mode on with the #236?
[08:34] <ogra_> bzoltan, see above ... there is a bug
[08:35] <ogra_> bzoltan, test with 235
[08:35] <brendand> Mirv is the first outsider to comment on our trello board!
[08:36] <brendand> davmor2, we need to give him a prize
[08:37] <Mirv> a prize \o/
[08:38] <ev> sil2100: do you see any problems in excluding the silos/ directory from backups of the train? We can easily re-create their contents, correct?
[08:38] <ev> trying to get out of this disk space hole
[08:38] <davmor2> brendand: he gets to keep his cat we stop sil2100 steeling it
[08:38] <bzoltan> ogra_: I just flashed 236 :(
[08:42] <bzoltan> ogra_:  is there a way to enable adbd in the treminal app?
[08:42] <ogra_> brendand, sure
[08:42] <Mirv> davmor2: thanks for the protection :)
[08:42] <ogra_> andr<doubletap> enable adb
[08:42] <ogra_> ;)
[08:43] <bzoltan> anything simpler? :)
[08:44] <ogra_> you could try a hammer ... but i wont promise success :)
[08:46] <bzoltan> ogra_:  ohhh... I just tried. It broke my device. :D
[08:48] <asac> ubuntu-device-flash doesnt work for us anymore :)
[08:48] <asac> ubuntu-device-flash --channel=devel-proposed with a mako connected
[08:49] <asac> but guess tvoss asked elsewhere already
[08:49] <asac> so /me will wait for his answer
[08:49] <brendand> ogra_, i can't repro that bug in RTM
[08:49] <brendand> asac, yes it's broken
[08:49] <ogra_> brendand, which bug ?
[08:50] <asac> brendand: broken?
[08:50] <asac> how come?
[08:50] <brendand> ogra_, the messaging app one
[08:50] <asac> who broke?
[08:50] <ogra_> brendand, ah
[08:50] <brendand> asac, i'll let them confess :)
[08:50] <asac> hehe
[08:50] <asac> well. how ?
[08:50] <asac> upload of ubuntu-device-flash?
[08:50] <asac> or server busted?
[08:50] <brendand> asac, adb not being started
[08:50] <brendand> adbd
[08:50] <asac> dev mode?
[08:50] <ogra_> asac, looks like a system-image server issue if you ask me
[08:50] <ogra_> brendand, unrelated
[08:50] <brendand> ogra_, really?
[08:50] <ogra_> yes
[08:51] <ogra_> oh, wait, probably not
[08:51] <asac> are you on it?
[08:51] <brendand> ogra_, i didn't see all the details of asacs issue
[08:51] <ogra_> brendand, i got tvoss' details
[08:51] <asac> sudo ubuntu-device-flash --channel=ubuntu-touch/devel-proposed
[08:51] <asac> 2014/09/11 10:47:11 Expecting the device to expose an adb interface...
[08:51] <asac> 2014/09/11 10:47:11 Device is |/bin/bash: /root/.bash_profile: Permission denied
[08:51] <asac> mako|
[08:51] <asac> 2014/09/11 10:47:11 Device /bin/bash: /root/.bash_profile: Permission denied
[08:51] <asac> mako not found on server https://system-image.ubuntu.com channel ubuntu-touch/devel-proposed
[08:51] <asac> thast what i see
[08:52] <bzoltan> I see the same
[08:52] <ogra_> right, the last message confused me
[08:52] <asac> surely a follow up from the stuff before
[08:52] <asac> or at least very likely
[08:52] <ogra_> then its the last lxc-android-config landing
[08:52] <ogra_> i see whats wrong and have a fix,
[08:52] <asac> thx
[08:52] <asac> does this affect ability to upgrade?
[08:52] <asac> for thos taht have something installed?
[08:52] <ogra_> not OTA, no
[08:53] <asac> ok
[08:53] <asac> so just newcomers cannot flash
[08:53] <asac> and infrastructure
[08:53] <ogra_> and u-d-f will work from reciovery
[08:53] <ogra_> asac, right, i'm aware since 30min
[08:54] <vila> ogra_: so this explains all (almost, 14 at least and counting ;) the devices in the infra being busted ?
[08:55] <vila> ogra_: with image #236 that is
[08:55] <ogra_> vila, yes, see the backlog and my conversation with psivaa
[08:57] <bzoltan> ogra_: I could boot to recovery and now i am fahsing 235 with bootstrap
[08:57] <ogra_> bzoltan, yeah, that will work fine
[08:57] <ogra_> (as well as just enabling adb with the above command in the terminal)
[08:58] <bzoltan> ogra_:  ... and the hummer
[08:58] <ogra_> lol
[08:58] <bzoltan> that works always ... I was told today by my 5yo
[09:02] <Mirv> tvoss: non-approved https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-int64-signature/+merge/232511
[09:03] <tvoss> Mirv, done, and sorry
[09:04] <Mirv> thostr_: note line 32 is not marked as Ready?, should it be? (rtm fix apparmor settings)
[09:05] <Mirv> tvoss: why does libmedia-hub-common2.symbols only have one symbol while the common1 had many? https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/12/artifact/packaging_changes_media-hub_2.0.0+14.10.20140910.2-0ubuntu1.diff
[09:06] <tvoss> Mirv, I added a symbols.map to prevent weak stl symbols bleeding into the exposed set of symbols
[09:06] <tvoss> Mirv, we are doing that for almost all projects now, media-hub is one of the remaining ones
[09:07] <Mirv> tvoss: oh, stopping bleeding is good indeed
[09:07] <Mirv> sil2100: there's a need for MOTU here https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/
[09:07] <Mirv> my motu meeting is in 1.5 weeks ;)
[09:08] <sil2100> Mirv: looking :)
[09:09] <sil2100> Mirv: well, there's no way you won't become a MOTU ;) So it's just a matter of time
[09:09] <brendand> sil2100, can you help me out with a couple of silos?
[09:11] <Mirv> sil2100: hehe
[09:11] <sil2100> Mirv: looks good, although it's really fishy that the symbols-count for the -common library fell down so much ;) But I guess since it builds, then it has to mean everything is OK
[09:11] <sil2100> Mirv: so a +1
[09:11] <sil2100> brendand: what's up?
[09:12] <brendand> sil2100, i tested silo 14 earlier this week and found an issue
[09:12] <brendand> sil2100, the lander prepared a fix which they already landed in utopic
[09:13] <brendand> sil2100, that fix is in silo 15 now
[09:13] <brendand> sil2100, but it fixes a bug that only exists in silo 14
[09:13] <brendand> sil2100, is that ok, or is it going to cause issues?
[09:15] <brendand> maybe i need to test and land them together?
[09:16] <thostr_> Mirv: line 32 is ready... seems I overlooked it
[09:17] <sil2100> cjwatson: hey! If I would like a new package in ubuntu-rtm which is available in ubuntu, can I simply publish it to ubuntu-rtm?
[09:17] <sil2100> cjwatson: or do we need something else to make sure ubuntu-rtm recognizes it?
[09:18] <sil2100> brendand: let me read up, one moment :)
[09:19] <sil2100> brendand: so, in other words... there are two rtm silos with the same component, right? 14 and 15?
[09:21] <Mirv> sil2100: thanks! yes I checked the symbols with thomas
[09:22] <Mirv> thostr_: ok, thanks!
[09:24] <sil2100> brendand: since because you say that the packages that are in silo 15 are already in utopic, what we can do is simply rebuild unity-scope-mediascanner in silo 14
[09:25] <sil2100> brendand: then silo 14 will have everything that you need
[09:25] <sil2100> brendand: since it will have the 2 other packages for itself + the latest of the latest from silo 15
[09:26] <brendand> sil2100, yeah i would rather have everything in one place
[09:26] <brendand> pete-woods, ^
[09:27] <sil2100> brendand: oh, I see it's no longer a sync silo
[09:27] <sil2100> brendand: ok, let me get everything you need into one silo anyway :)
[09:28] <pete-woods> brendand: okay, so what do you need me to do?
[09:28] <pete-woods> am I rebuilding the mediascanner silo?
[09:28] <brendand> pete-woods, i don't *think* you need to do anything
[09:29] <brendand> pete-woods, just waiting for those test results
[09:30] <sil2100> pete-woods: no worries, I'm handling everything :)
[09:30] <sil2100> pete-woods: I'm making sure that everything is in silo 14 that's needed
[09:30] <dbarth> Mirv: for silo 17 testing, either i need to wait for alex-abreu later today, or maybe i can stand by during the qa signoff to speed that up?
[09:32] <sil2100> ev: hmm, from first thought it might be ok, but let me double check something in a moment
[09:33] <pete-woods> :)
[09:34] <ev> okay
[09:35] <popey> Mirv: could you please upload http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/lastSuccessfulBuild/artifact/com.ubuntu.sudoku_1.1.282_all.click to the store?
[09:36] <sil2100> cjwatson: for now I'll try using a silo to sync it up
[09:36] <popey> Mirv: http://s-jenkins.ubuntu-ci:8080/job/weather-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.weather_1.1.365_all.click also please
[09:38] <Mirv> dbarth: what do you mean by stand by? maybe you could negotiate whether QA would be ready to start testing the silo without your approval, or that you would mark it as "tested" (the utopic equivlent was) to get it progressing?
[09:41] <Mirv> popey: noted. my click-toolbelt just decided python doesn't have datetime module, so might need some time
[09:41] <popey> oof
[09:44] <dbarth> Mirv: have QA start testing to confim the silo; quicker easier, it's a set of bug fixes
[09:45] <Mirv> dbarth: right. please talk to brendand davmor2 about that (this is about silo 017)
[09:45] <dbarth> let me know who gets started on that and i can just help drive the test in a hangout
[09:45] <Mirv> dbarth: they have currently it and silo 010 on hold until 017 would be marked as ready for signoff testing
[09:45] <dbarth> ok clear
[09:49] <seb128> dbarth, could you look at https://bugs.launchpad.net/ubuntu-facebook-app/+bug/1367704 to check if it's assigned to the right component (it's a bug from jane)
[09:49] <ubot5`> Ubuntu bug 1367704 in Ubuntu Facebook App "Facebook account not recognised by Facebook webapp" [Undecided,New]
[09:51] <dbarth> seb128: it's not; but ok, taking care of it
[09:51] <seb128> dbarth, thanks
[09:57] <cjwatson> sil2100: you can just copy it, sure
[09:58] <cjwatson> sil2100: context?
[09:58] <cjwatson> sil2100: is this rsyslog?
[10:02] <ogra_> cjwatson, yeah
[10:02] <ogra_> it broke image builds today
[10:04] <davmor2> dbarth: we can't touch silos till they are listed for QA sign off
[10:04] <cjwatson> sil2100: using a silo for this is pointless - we should either force it, or else just do a direct binary copy into 14.09-proposed
[10:04]  * ogra_ would do the latter 
[10:04] <brendand> pete-woods, i think silo 14 should be retested
[10:05] <cjwatson> sil2100: why did you rebuild this package?
[10:05] <cjwatson> sil2100: seriously, let's stop doing pointless source-only copies when we just want to get the dependencies satisfied
[10:06] <dbarth> davmor2: i marked it test pass but left the #, does that help?
[10:06] <dbarth> apparently the queuebot noticed ;)
[10:07] <davmor2> dbarth: we'll find out in a second thanks
[10:08] <dbarth> ok, let me know if you want to open a hg; it's a quick test (apart from your own test round)
[10:08] <brendand> 17 is ready now
[10:11] <jamesh> davmor2, brendand: I posted an update on https://bugs.launchpad.net/unity8/+bug/1367400 about the bug in launching music-app for music on the SD card: in short, the fix to switch to music:/// has not made it to ubuntu-rtm yet
[10:11] <ubot5`> Ubuntu bug 1340952 in url-dispatcher (Ubuntu) "duplicate for #1367400 Video and Music scopes should provide non-file:/// based URIs" [High,In progress]
[10:11] <brendand> jamesh, is it in silo 14?
[10:12] <sil2100> cjwatson: can you just do a direct binary copy then?
[10:12] <jamesh> brendand: doesn't look like it.
[10:12] <brendand> jamesh, oh ok
[10:13] <sil2100> cjwatson: it's a package from main so I have no power over it besides through a silo
[10:13] <jamesh> brendand: was blocked waiting for QA approval for a landing to utopic, which looks like it has completed now
[10:13] <brendand> pete-woods, jamesh - so can we agree that you'll rerun the localmediascopes test plan for silo 14 and record the results somewhere?
[10:13] <sil2100> cjwatson: I can do a binary copy to the silo and then release, but yeah...
[10:13] <cjwatson> sil2100: done
[10:13] <cjwatson> $ copy-package --from=ubuntu --from-suite=utopic --to=ubuntu-rtm --to-suite=14.09-proposed -b dbconfig-common
[10:13] <sil2100> cjwatson: thanks!
[10:14] <sil2100> cjwatson: well, in theory I can't do that for a main package, right?
[10:14] <cjwatson> indeed
[10:14] <sil2100> cjwatson: or can I?
[10:14] <cjwatson> I don't believe you'll be able to
[10:14] <cjwatson> bug: sil2100 is not core-dev :)
[10:14] <sil2100> ;p
[10:15] <cjwatson> even if you need to use a silo, though, please just binary-copy from ubuntu for this kind of thing
[10:16] <cjwatson> the reversioning and rebuilding gains us nothing, and potentially even introduces issues (e.g. if somebody has a >= dependency on the latest version of the thing we're copying)
[10:16] <cjwatson> the source of this issue was a bug in the original ubuntu-rtm copying script
[10:17] <cjwatson> I followed through dependencies on everything we actually needed, of course; but I didn't follow dependencies of other binaries built by the same source as binaries we actually needed
[10:18] <sil2100> ACK o/
[10:18] <cjwatson> I think at this point it is probably too hard to safely fix in bulk for 14.09, and we should just deal with it as it comes up
[10:18] <sil2100> Right
[10:18] <sil2100> Yeah, I'll do binary-copies in such cases, I'll also inform other people from the landing team to do the same thing in cases of missing deps
[10:18] <cjwatson> bad morning for me to be late in, I guess :-/
[10:19] <cjwatson> I've previously forced proposed-migration to ignore a few things like this
[10:19] <cjwatson> but it's probably better to chase the copies, now that I've thought about it a bit
[10:20] <brendand> pete-woods, i've set 'Testing pass' back to No. please do retest silo 14 and provide the results, then set it back to Yes
[10:21] <cjwatson> well, except that chasing the copies for ubuntu-desktop-next/ubuntu-sdk would take ages; for that one it's probably still better to force, as a matter of pragmatism
[10:21] <pete-woods> brendand: okay, will have james re-run the tests..
[10:24] <Mirv> popey: ok... sudoku and weather uploaded. yesterday's python2.7 update broke it, I had to downgrade.
[10:24] <popey> Mirv: thank you!
[10:29] <popey> Mirv: sorry, one more http://s-jenkins.ubuntu-ci:8080/job/reminders-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.reminders_0.5.248_armhf.click please
[10:30] <jamesh> brendand: from above, RTM silo 14 does contain the required fixes.  I was looking at the wrong page of the dashboard
[10:35] <sil2100> cjwatson: btw. do we have a madison.cgi for ubuntu-rtm?
[10:36] <brendand> jamesh, the required fix for the RTM blocker right? i.e. 'Play in music app' is broken for songs on the SD card
[10:36] <jamesh> brendand: correct.
[10:36] <brendand> jamesh, ok, i wasn't expecting it would
[10:36] <brendand> jamesh, if a test in the test plan fails because of it, just note the bug as the reason why
[10:36] <cjwatson> sil2100: just the normal one - use rmadison
[10:36] <brendand> jamesh, and one should :)
[10:37] <cjwatson> sil2100: (I fixed that last Thursday)
[10:37] <brendand> jamesh, so if not then maybe you need another test :)
[10:37] <ev> sil2100: thoughts on those backups?
[10:37] <sil2100> cjwatson: ah! Indeed, I see ubuntu-rtm :D
[10:37] <sil2100> ev: taking a look at that now
[10:38] <jamesh> brendand: I guess so.  At the moment, I wrote most of the test plan but none of my devices have an SD card
[10:38] <brendand> jamesh, oh i see
[10:38] <ev> sil2100: thanks
[10:39] <brendand> jamesh, every team should really have someone with a krillin to test landings. that doesn't seem to be the case at the moment
[10:39] <jamesh> brendand: once we've got mediaplayer-app updated to accept video: URIs and the videos scope updated to match, the special cases for the file:///home/*/Music in the URL dispatcher can be removed
[10:40] <brendand> jamesh, might be worth it to add the test anyway with a note like 'mark this test as skipped if you do not have a device with an SD card'
[10:40] <asac> screen not going off automatically is a known regression/blocker?
[10:40] <jamesh> brendand: at that point, there should be no difference between music in the home directory and on the SD card: they'll either both work or both fail
[10:40]  * asac had that on utopic yesterday and today on rtm
[10:41] <cjwatson> sil2100: I think dbconfig-common is probably actually published, but the archive-reports business that (as a side-effect) updates rmadison's view of the world is being slow - it'll catch up by itself before I can do anything about it, but I'm going to look into some of the current perf problems there
[10:41] <cjwatson> sil2100: yep, it shows as published now, so I expect you can kick an image build
[10:42] <sil2100> ogra_: can you kick a new RTM build then?
[10:42] <sil2100> cjwatson: thanks :)
[10:42] <cjwatson> can't you?  should be on iso.qa
[10:42] <sil2100> It's on iso already?
[10:42] <sil2100> Last week it still wasn't
[10:42] <cjwatson> has been for a while
[10:43] <cjwatson> I thouht
[10:43] <cjwatson> +g
[10:43] <ogra_> asac, i saw someone mention it on one ML
[10:43] <ogra_> but not sure there is even a bug for it
[10:43] <ogra_> it seems to be very random
[10:43] <cjwatson> anyway I get http://iso.qa.ubuntu.com/qatracker/milestones/321/builds linked from the front page
[10:43] <ogra_> (i have seen it too before)
[10:43] <ogra_> sil2100, on it
[10:43] <ogra_> cjwatson, no products there yet
[10:43] <cjwatson> oh, "no build available".  hmm.
[10:43] <ogra_> there is a section
[10:43] <ogra_> but stgraber need to add some content for us :)
[10:43] <asac> ogra_: who would usually right person to talk about what info to extract when i get to that point again?
[10:43] <cjwatson> right, ok, can be done manually then :)
[10:43] <asac> is that powerd? or rather unity?
[10:43] <ogra_> i pinged him about that during debconf ... he had no time and we both forgot again
[10:43] <ogra_> asac, krillin ?
[10:43] <asac> both
[10:43] <sil2100> ogra_: thanks :)
[10:43] <asac> first on n4 yesterday
[10:43] <asac> today on krillin
[10:44] <asac> think its all same same
[10:44] <ogra_> asac, krillin has a very specific kernel fix
[10:44] <ogra_> i have never seen it on mako here
[10:44] <asac> right. i had it yesterday for hours on mako
[10:44] <ogra_> i think since the kernel change got in i see it on krillin ... but really rarely ... every third or second day once
[10:45] <ogra_> asac, so yeah, file a bug, that points more towards powerd then
[10:45] <asac> ogra_: who owns tpowerd? doesnt help to file a bug if i cannot extract any info i am sure... folks will say they cannot reproduce
[10:45] <asac> so next time i see i want to talk what to extract to help debugging
[10:45] <brendand> sil2100, where can i see the version of X package in proposed for RTM?
[10:45] <cjwatson> brendand: rmadison <package>
[10:46] <ogra_> asac, well, phonedations ... kind of ... i think
[10:46] <brendand> cjwatson, rmadison of course
[10:46] <cjwatson> brendand: or https://launchpad.net/ubuntu-rtm/+source/<sourcepackage>/+publishinghistory
[10:46] <sil2100> brendand: right, rmadison and check the ubuntu-rtm/14.09 version
[10:46] <asac> ogra_: ok so ChickenCutlass :)
[10:46] <asac> will just go through him next time
[10:46]  * asac leaves ogra alone who surely has more important things to fix like image not flashing :)
[10:47] <asac> lol
[10:47] <ogra_> asac, twiddling thumbs waiting for the publisher is my main job currently :P
[10:47] <ogra_> fixes are uploaded
[10:47] <sil2100> ogra_: ;)
[10:47] <cjwatson> ogra_: waiting for which packages?
[10:47] <sil2100> ogra_: fixes or reverts?
[10:47] <ogra_> cjwatson, android-tools
[10:48] <asac> ogra_: can you extend the testplan for that component so we test upgrading nmext time?
[10:48] <ogra_> sil2100, fixes ... the adb not starting was a dumb quoting issue in an upstart script (' vs ")
[10:48] <asac> not sure how to do, but thats the key to avoid these in future i am sure
[10:48] <asac> think its about adding that you flash another time after first try
[10:48] <cjwatson> ogra_: right, so you're currently waiting for proposed-migration and then the publisher, but yeah :)
[10:49] <ogra_> asac, both packages will get QA testing in silo 13 today, so yes, there will be a test plan attached we can re-use later
[10:49] <ogra_> (for rtm)
[10:49] <ogra_> asac, the prob is that you can not easily test android-tools on krillin at all ... thanks to the device tarball bind mounting upstart jobs over the originals
[10:50] <asac> ok
[10:50] <ogra_> we need to drop that habit :P
[10:50] <asac> well. think that needs to be tackled or at least started
[10:51] <asac> maybe its a tooling problem that we can improve without having to kill that habit short term
[10:51] <ogra_> upstart jobs need to be fixed in the package, not by overlaying with a device specific hack
[10:51] <ogra_> (this is ok during porting, but part of the porting work should be to get the fixes merged in the actual packages :) )
[10:52] <sil2100> ev: ok, so... the ~/silos directory has the complete state of the backend for the CI Train, so it actually has all the config files and project files without which we can't build or publish things properly
[10:52] <sil2100> ev: when are the backups made?
[10:52] <ev> daily
[10:53] <sil2100> ev: where do we have the backups stored?
[10:55] <ev> sil2100: we're going to move them to Swift
[10:56] <ev> sil2100: is there a pattern under silos we could exclude?
[10:56] <ev> some of the build dirs, perhaps?
[10:56] <bzoltan> brendand: ToyKeeper mentioned that she had trouble with the phablet-click-test-setup --distribution=ubuntu-rtm --series=14.09
[10:58] <brendand> bzoltan, oh i didn't hear about that
[10:58] <bzoltan> brendand: I just got it crashing
[11:00] <brendand> bzoltan, btw i just confirmed a bug in your new silo
[11:01] <brendand> bzoltan, i'll check if it's in utopic and file a bug
[11:01] <brendand> oh crap - i can't flash utopic
[11:01] <brendand> ogra_, can i flash utopic yet?
[11:01] <ogra_> brendand, nope, still waiting for one package ... then 1.5h build time
[11:02] <ogra_> (for the image)
[11:02] <cjwatson> it's waiting for autopkgtests
[11:02] <brendand> bzoltan, so something breaks dialer-app
[11:02] <sil2100> ev: let me think...
[11:02] <brendand> bzoltan, when you drag up the recent calls list it messes the ui up
[11:02] <sil2100> ev: for sure we can get rid of the build-area/ directory inside
[11:02] <brendand> bzoltan, like this: http://people.canonical.com/~brendan-donegan/recent.png
[11:03] <cjwatson> which are done, actually, so should work on the next pass
[11:03] <brendand> bzoltan, it's not in the silo ToyKeeper just landed, but the new one
[11:03] <sil2100> ev: the ubuntu/ directory should be removable as well
[11:03] <brendand> bzoltan, i assure you i only upgraded uitk, nothing else
[11:03] <brendand> bzoltan, the AP tests for dialer-app did not fail, so are not adequate to catch this
[11:04] <bzoltan> brendand:  we have the standup  right now ... could you please join
[11:04] <bzoltan> brendand: Mumble - orange room
[11:04] <ev> sil2100:  thanks
[11:04] <sil2100> ev: the most important things in the silo directories are: the config file, *.project* files and the bzr source directories
[11:04] <brendand> bzoltan, actually i'm just going on my lunch breal
[11:04] <brendand> break
[11:04] <brendand> bzoltan, and i don't have mumble set up anyway
[11:05] <Mirv> popey: reminders done too
[11:05] <brendand> haven't since 2012
[11:05]  * popey hugs Mirv 
[11:05] <bzoltan> brendand: :D
[11:05]  * Mirv thinks fresh air would sound good
[11:06] <brendand> Mirv, is the air quite fresh in Finland in September?
[11:06] <brendand> Mirv, or still warm?
[11:06] <Mirv> brendand: usually a bit "fresher", now +20'C
[11:06] <brendand> Mirv, well that's no shirt weather here in GB
[11:07] <bzoltan> Mirv:  we need you on the standup
[11:08] <bzoltan> brendand:  it is possible that the UITK in the silo9 is not thr right one
[11:09] <bzoltan> brendand:  the point here in Finland is that when you talk about 20'C then you have to put the + sign :)
[11:09] <popey> psivaa: http://91.189.93.70:8080/job/generic-mediumtests-utopic-python3/285/console getting core dumps in music app...
[11:09] <popey> psivaa: related... /tmp/hudson8910191033881077787.sh: line 81: 10540 Aborted                 (core dumped) qmlscene /tmp/main.qml
[11:10] <popey> psivaa: seems strange given the music app main file isn't called main.qml... so wondering where that is coming from?
[11:13] <psivaa> popey: looking
[11:14] <sil2100> brendand: hey, you done with silos for now?
[11:16] <brendand> bzoltan, you mean not the one you tested?
[11:16] <brendand> sil2100, semi done. bzoltan will confirm if i'm testing the right uitk or not
[11:17] <brendand> sil2100, but i also have to have lunch now
[11:17] <brendand> sil2100, did you want me to check something out? i can take care of it when i come back online
[11:17] <sil2100> brendand: no worries - after you're done, could I interest you in some autopilot investigations? ;)
[11:17] <bzoltan> brendand:  I am afraid that the UITK on the silo is missing a fix what landed on Ubuntu Utopic
[11:18] <bzoltan> sil2100: brendand: so something might be very wrong
[11:19] <bzoltan> brendand: Note that I have just learned today from ToyKeeper that the phablet-click-test-setup in default uses the Utopic tests and not the RTM tests....
[11:19] <bzoltan> brendand:  so, let's rewind
[11:22] <ogra_> ah, android-tools moved on a bit :)
[11:23] <sil2100> bzoltan: if this was a sync from ubuntu to ubuntu-rtm, then everything from UITK from ubuntu should be in that silo - but maybe you're missing some dependencies that are required?
[11:23] <sil2100> bzoltan: and yeah, our tool seem not to be completely ready for RTM handling...
[11:24] <brendand> bzoltan, well i leave it up to you to provide a silo that is tested and ready for landing in RTM. let me know when that's the case
[11:24] <bzoltan> sil2100:  I am afraid that the RTM silo was synced with the Ubuntu Silo before it still got a fix
[11:25] <bzoltan> brendand:  OK, but for that I would need a functioning phablet-click-test-setup :(
[11:25] <bzoltan> brendand:  but better be safe and check twice and hurry and make a mistake
[11:27] <brendand-afk> sil2100, just tell me the details and i will look at it after an hour
[11:28] <sil2100> bzoltan: let me check how the silo is configured, maybe all we need is just press 'build'
[11:28] <bzoltan> sil2100: that is what I hope
[11:29] <sil2100> bzoltan: hm, it seems to be up-to-date to what's in utopic!
[11:32] <popey> why was there no image 30 for krillin built last night?
[11:32] <popey> 29 is latest, and that's yesterday, right?
[11:32] <ogra_> popey, archive screwup
[11:32] <popey> ah okay
[11:33] <ogra_> rtm you mean, right ?
[11:33] <popey> yes
[11:33] <popey> thanks
[11:33] <bzoltan> sil2100:  zsombi just checked on Utopic image and the problem is not there
[11:33] <ogra_> should pop out of the builder soon
[11:35] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch ... rootfs is already done ...
[11:35] <psivaa> popey: the actual cause appears to be a transient error:  'Autolaunch error: X11 initialization failed.'. when running 'jack_control start'
[11:36] <psivaa> for the failure in http://91.189.93.70:8080/job/generic-mediumtests-utopic-python3/285/consoleText that is
[11:36] <popey> hmm
[11:36] <psivaa> there were some xorg, x11 related packages upgraded
[11:36] <popey> ah okay
[11:37] <ahayzen> popey, so does that mean it is 'no us' ? but something in the platform?
[11:37] <popey> yes, not your fault
[11:37] <popey> .... this time....
[11:37] <ahayzen> lol
[11:37] <psivaa> popey: yes
[11:37] <popey> ☻
[11:37] <psivaa> popey: i say this transient because the next job with the same parameters succeeded. please ping us if you see this again
[11:37] <ahayzen> whats pulling down jack_control? or does that get pulled with part of pulse/gst?
[11:37] <popey> ok thank you!
[11:38] <popey> yeah, that's odd, i wouldn't have expected to see jack at all
[11:38] <ahayzen> psivaa, it seems to be randomly happening...over the past day or so i would say we've had it ~3-4 times and if we rerun it then usually passes
[11:40] <psivaa> ahayzen: hmm, yes seeing the same reason here: http://91.189.93.70:8080/job/generic-mediumtests-utopic-python3/279/consoleText
[11:40] <psivaa> let me dig in a bit more
[11:40] <ahayzen> psivaa, thanks
[11:43] <pete-woods> brendand-afk: we have started compiling the sheet you asked for here: https://docs.google.com/a/canonical.com/spreadsheets/d/17FjOXaT-OsTnuSPnyv7kzEfubJadTaEjDO1gSAjRNCM/edit#gid=0
[11:51] <davmor2> thostr_: grooveshark scope has no album art any more is this a known issue?
[11:52] <bzoltan> brendand-afk: sil2100: Mirv: I am blocked with the RTM validation of the UITK -> http://pastebin.ubuntu.com/8318350/
[11:53] <ogra_> cjwatson, gah, my ssh connection to nusakan has dropped, do i need to re-run without --live ? seems while the rtm rootfs has built it didnt get published
[11:54] <cjwatson> ogra_: did you run it in screen?
[11:54] <ogra_> indeed not :P
[11:54] <cjwatson> get into the habit :)
[11:55] <ogra_> heh, yeah
[11:55] <cjwatson> ogra_: I expect you will need to rerun without --live, yes
[11:55] <ogra_> ok
[11:55] <cjwatson> it doesn't appear to be running now
[11:55] <ogra_> i build directly on nusakan so raraely nowadays that i dropped the habit ... i used to use screen
[11:55] <psivaa> ahayzen: popey: still no concrete idea why 'jack_control start' fails intermittently this way. something underneath is racy. i'd talk to fginther to about it
[11:56] <cjwatson> I have a local "s" command that I basically always use when connecting to DC machines, so I don't forget
[11:56] <cjwatson> #! /bin/sh
[11:56] <cjwatson> exec ssh -t "$1" screen -ARD
[11:56] <ogra_> bah, stale lock
[11:56] <ogra_> lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-build-image-set-ubuntu-touch-ubuntu-rtm-14.09-daily-preinstalled"
[11:56] <ogra_> Another image set is already building!
[11:56] <cjwatson> wait one moment then
[11:56] <ogra_> k
[11:56] <ahayzen> psivaa, thanks for looking into it
[11:57] <ogra_> hmpf ... and the iso tracker forgot all my checkmarks ... i get all images listed and it doesnt keep it when i uncheck the checkboxes ... weird
[11:57] <cjwatson> ogra_: ok, try again
[11:57] <ogra_> cjwatson, yep, better
[11:58]  * cjwatson -> lunch
[11:58] <cjwatson> btw I've hopefully sped up the proposed-migration cycle a bit by filtering out some junk from http://people.canonical.com/~ubuntu-archive/testing/utopic_probs.html which was taking ages to analyse
[11:59] <ogra_> yay
[11:59] <ogra_> thanks
[11:59] <cjwatson> still needs work but it should help
[11:59] <Mirv> sil2100: just so you know, I triple-checked that yes the uitk rtm landing seems intact and identical to utopic archive version, so whatever problem comes from something else than the uitk being wrong version.
[12:00] <Mirv> (identical, but rebuilt)
[12:01] <ogra_> sil2100, could you sync ubuntus latest lxc-android-config and android-tools into rtm silo 13 ? (or Mirv if you feel like)
[12:03] <sil2100> Mirv: so just as I expected, thanks!
[12:04] <sil2100> ogra_: I'm in the middle of consumption but let me take a look at that :)
[12:04] <thostr_> davmor2: not known... just wondering why 7digital still has...
[12:05] <davmor2> thostr_: I'll write up a bug for it then
[12:06] <thostr_> davmor2: thanks
[12:09] <imgbot> [12:10] <ogra_> there we go
[12:12]  * ogra_ hugs sil2100 
[12:14] <thostr_> davmor2: just check, album art seems to work for us
[12:15] <thostr_> davmor2: the issue is, that we switched from lastfm to 7digital for album art retrival
[12:17]  * sil2100 hugs ogra_
[12:17] <davmor2> thostr_: https://bugs.launchpad.net/unity-scope-grooveshark/+bug/1368198  I see it on rtm for krillin and mako
[12:18] <davmor2> thostr_: it might be that there is a scope update that you have that I don't
[12:18] <thostr_> and 7digital does not provide such a rich album art db
[12:18] <ogra_> sil2100, hmm, the custom tarballs cause the same prob we have with the krillin device ones ... i guess we need to make sure to also have the cusom guys coordinate their tarball pushes with us
[12:20] <sil2100> ogra_: who's responsible for those?
[12:20] <ogra_> sil2100, i guess cwayne
[12:20] <ogra_> or at least he should knwo if he isnt
[12:20] <davmor2> thostr_: just added another screenshot to the bug, that shows a search for bat out of hell 7d shows it grooveshark doesn't
[12:29] <brendand> pete-woods, that's useful information, but what i was hoping for was a list of the test cases in each plan with the heading 'test,tester,result,comments'
[12:29] <imgbot> [12:29] <imgbot> [12:30] <brendand> pete-woods, we're sort of looking for explicit confirmation that each test was run and passed
[12:30] <ogra_> langpacks galore
[12:31] <ogra_> asac, btw, i can confirm your "screen doesnt shut off" bug on krillin now
[12:33] <pete-woods> brendand: so you want us to enumerate each test in the wiki page, and write "tested" next to it in the spreadsheet?
[12:33] <Ursinha> morning
[12:34] <pete-woods> because that's pretty much what will happen
[12:34] <brendand> pete-woods, 'pass/fail/skipped'
[12:34] <brendand> pete-woods, if skipped, comment why
[12:34] <pete-woods> surely skipped would not be acceptable?
[12:35] <asac> ogra_: ok ... is there new image with the fixed android tools already?
[12:36] <brendand> pete-woods, normally it wouldn't yes - but i there might be some cases
[12:36] <asac> h i see that image build is in progress
[12:36] <asac> 237 ... /me will wait
[12:36] <ogra_> asac, see above ... 237 is building since 15min
[12:36] <brendand> pete-woods, at least we'd know it was skipped for X reason, not that someone just chose not to run it
[12:37] <brendand> pete-woods, if doing this really feels like a lot of overhead then please let us know, but we're kind of trying to get better traceability into this process. you're being used as a guinea pig
[12:37] <pete-woods> it's quite a lot of overhead, yes
[12:37] <pete-woods> now you've added this second part
[12:37] <brendand> pete-woods, really? initially perhaps
[12:37] <pete-woods> because someone has to go through the wiki page, and turn it into a form to fill in
[12:38] <pete-woods> every time they run the test
[12:38] <brendand> pete-woods, you can do as little as copy it into a text file
[12:38] <brendand> pete-woods, and append notes to each line
[12:38] <pete-woods> if you want a tick list for running the steps, we need something better than a wiki page manually transformed into a form
[12:39] <thostr_> brendand: I can see where you come from, but I'm wondering if that really improves testing
[12:40] <thostr_> brendand: since somebody who doesn't test properly can just tick off all tests
[12:41] <thostr_> brendand: wouldn't it be sufficient as first step to add two more columns to ci sheet if necessary
[12:41] <thostr_> brendand: that would be a) name of tester and b) comments about the test
[12:43] <brendand> thostr_, device tested on too
[12:43] <thostr_> brendand: sure
[12:44] <thostr_> brendand: but let's not overdue it, otherwise I feel that people will just ignore it and put in random stuff if at all
[12:44] <brendand> thostr_, pete-woods - to be honest i really don't see how, if the tests are actually being stepped through, that it's so much overhead just to write the outcome next to it. it can even be handy for the tester to see which tests they have run already
[12:45] <thostr_> brendand: it's the little heres and theres that add up
[12:45] <dbarth> will we get another round of images today / tomorrow?
[12:45] <brendand> thostr_, you do realise this requirement was provoked by the fact that whoever ran the test plan for this silo very obviously did *not* run all the tests on the test plan
[12:45] <thostr_> brendand: I'm fully aware of this, therefore my comments
[12:46] <thostr_> brendand: what we (I) need to fix is the attitude of individuals
[12:46] <sergiusens> sorry for meddling, but sloppy testing can't be prevented; people that don't have a "testing" mindset generally miss a lot of things
[12:47] <thostr_> brendand: adding more buerocracy won't help
[12:47] <thostr_> sergiusens: +1
[12:47] <brendand> sergiusens, but the problem is right now we have so little ability to trace what actually happened and try and improve things
[12:48] <brendand> thostr_, i really don't feel it's bureaucracy - transparency is what we're aiming for
[12:48] <pete-woods> yes, but relying upon a "sloppy tester" to provide the information about whether he was sloppy or now seems flawed
[12:50] <brendand> thostr_, pete-woods - we should be able to distinguish between a case where someone has been sloppy and one where someone made a mistake or misunderstood something
[12:52] <brendand> thostr_, pete-woods - can either of you actually tell me why this happened? is it because the test plan wasn't run full stop, or another reason?
[12:52] <thostr_> brendand: yes, which is because of sloppy testing
[12:52] <thostr_> brendand: the very same guy would have ticked all tested ok boxes
[12:53] <brendand> thostr_, i will add that what you suggested is definitely an improvement
[12:54] <thostr_> brendand: good. and as said, the rest is up to me to fix
[12:55] <ev> sil2100: 1:47 PM <Spads> ev: ./var/lib/jenkins/citrain-preprod_old
[12:55] <ev> ^ can we kill that?
[12:55] <Spads> sil2100: hi!
[12:55] <Spads> it's dated 5 September
[12:55] <brendand> sergiusens, slopppy anything usually comes down to part of a process being difficult to understand or otherwise flawed
[12:55] <sil2100> ev: yes, I guess this is some backup from the past
[12:55] <brendand> sergiusens, e.g. ambigious test cases
[12:55] <sil2100> Spads, ev: so feel free to wipe this one out
[12:56] <Spads> cooool
[12:56] <brendand> sergiusens, it's not that common actually for people to make mistakes just because
[12:57] <sergiusens> brendand: everyone makes mistakes; test plans that are manual will always have human error; be it sloppy or not
[12:57] <brendand> sergiusens, heck even automated tests do :)
[12:58] <brendand> sergiusens, human error all over the shop
[12:58] <sergiusens> brendand: it would be nice to have something to tick when testing; but it would be another manual thing to do (even the setup for it)
[12:59] <sergiusens> brendand: I guess what I'm saying is; no one would complain if it gets 'autocreated' on silo assignment and I just have to tick things (which I do visually while reading from the wiki plans anyways)
[12:59] <brendand> sergiusens, ok for now we won't require that level of detail - let's see if the additional information that thostr_ suggested gives us all the information we need
[13:00] <sergiusens> brendand: it could be free form now, heck I do that
[13:00] <brendand> sergiusens, do you provide testing notes with your silos?
[13:00] <sergiusens> brendand: I just add something into the comments saying I only tested certain surface areas as the MPs don't cover other isolated components
[13:00] <sergiusens> brendand: if I have a special comment on why or what, yes
[13:01] <davmor2> dbarth: hit a snag,  can you add the ppa, open reminders, click on create account and then try and add an evernote account, for me I get the reauthorise popup I click on yes and online accounts crashes
[13:01] <davmor2> dbarth: _usr_bin_online-accounts-ui.32011.crash which has gone to errors.ubuntu.com
[13:03] <dbarth> davmor2: i've seen this one
[13:03] <dbarth> davmor2: ah no, not *that* particular one
[13:03] <brendand> sil2100, is this something we can add to the spreadsheet - tester name, device tested on, test comments
[13:03] <dbarth> hmm
[13:03] <brendand> sil2100, they might fit in other fields already i guess
[13:04] <sil2100> brendand: regarding lander testing?
[13:04] <brendand> sil2100, we could change the 'Testing pass' format to 'Yes (30) - brendand, krillin'
[13:04] <pete-woods> it'd be better with separate fields for the data
[13:04] <brendand> sil2100, comments could go in comments, but that's kind of overloaded right now
[13:04] <brendand> pete-woods, i agree - if it doesn't cause any issues adding new fields
[13:05] <sil2100> brendand: the device name would make sense - as for the tester, we usually assume it's one of the landers doing it
[13:05] <sil2100> So not sure if that's required
[13:05] <brendand> sil2100, there can be several landers though
[13:05] <brendand> sil2100, we already had this case that it wasn't immediately apparent who did the testing
[13:14] <brendand> sil2100, so i would really like to add that
[13:14] <pete-woods> sil2100: I think brendand is looking for there to be a log of who ran the tests (as opposed to who filled in the sheet), so we can educate "sloppy" testers
[13:14] <brendand> sil2100, that way i don't need to waste my, and another persons time, we can talk to the person directly
[13:15] <brendand> pete-woods, not even always sloppy
[13:16] <brendand> pete-woods, sometimes people are working with broken tools, poorly defined test cases etc
[13:16] <pete-woods> sure, I understand that
[13:16] <brendand> in fact there's a perfect example from yesterday where recording the result of each test would have prevented a mix up in landing an apparmor silo
[13:16] <sil2100> brendand: makes sense
[13:17] <tedg> brendand, I have an assana ticket to add that to ci train, so the test cases get listed there.
[13:17] <tedg> Sorry, ci airline
[13:17] <brendand> tedg, ah the airline
[13:17] <tedg> brendand, Big task there is pulling the test items out of the branches and putting them in the ticket.
[13:18] <tedg> So, I think the most important thing today is getting a common format for the tests.
[13:18] <tedg> Though, that discussion leads to flame wars more quickly than I realized :-)
[13:18] <brendand> tedg, oh i was just talking to balloons about this last night
[13:18] <brendand> tedg, oh you don't need to tell me that
[13:18] <brendand> something for D.C. i think
[13:19] <tedg> brendand, And honestly, I *really* don't care about the format. I just want it to be documented and have a tool to verify I'm doing it right :-)
[13:20] <dbarth> davmor2: could not reproduce on utopic
[13:20] <dbarth> davmor2: do you have a pointer to that crash file? is that https://errors.ubuntu.com/problem/a6d442cbf6ce43f0fe5feaf8ee61106574d3991b ?
[13:21] <brendand> bzoltan, so what's up with that silo?
[13:21] <brendand> bzoltan, will i get to retest it any time soon (today)?
[13:23] <davmor2> dbarth: let me try and figure it out for you
[13:26] <tedg> So is it safe to upgrade my mako to the latest image?
[13:26] <tedg> I'm a bit confused by the message of all the devices being down in the lab.
[13:27] <ogra_> tedg, OTA is fine, fresh flash isnt
[13:28] <ogra_> (you might need to re-enable developer mode via the UI though)
[13:28] <tedg> ogra_, K, thanks!
[13:28] <ogra_> tedg, anouther 30min and there is a fixed image (oi hope)
[13:28] <tedg> Oh, that's better :-)
[13:28] <ogra_> be my guineapig ;)
[13:30] <tedg> Haha, you may want a guineapig with a faster internet connection ;-)
[13:31]  * ogra_ wonders if rtm 30 will ever finish its apparmor run :( 
[13:32] <ogra_> this is so awful :(
[13:32] <ogra_> 3min apparmor and counting ...
[13:34] <bzoltan> brendand:  We confirmed that the RTM silo has the same UITK what was released to  Utopic
[13:35] <brendand> bzoltan, i still can't install utopic to confirm i see the bug there. were any of your team able to check?
[13:35] <bzoltan> brendand: I am struggling with setting up my device ...
[13:36] <bzoltan> brendand:  zsombi said that the problem is not there on Utopic
[13:36] <brendand> bzoltan, i'd like to verify that myself - but it could be that dialer-app was updated to compensate for the change
[13:37] <zsombi> bzoltan: brendand: at least not with the image I've tested with...
[13:37] <bzoltan> brendand: sounds complicated
[13:40] <bzoltan> brendand:  the boot time just tripled for my device
[13:45] <jdstrand> ogra_: I've been thinking about how to ship cache files either as part of the click or as a separate download in the upgrade process. obviously not for rtm, but I think there is something there
[13:45] <jdstrand> I'll bring it up with my team post-rtm
[13:45] <jdstrand> (we've always said we could do that, and the work we did this cycle would support that)
[13:46] <jdstrand> that should help developers who upgrade to the latest all the time
[13:47] <ogra_> jdstrand, but when apparmor gets updated we'll have to re-generate again
[13:47] <ogra_> which will re-introduce the issue
[13:48] <jdstrand> ogra_: what I am thinking about takes that into account
[13:48] <ogra_> oh, cool
[13:48] <ogra_> yeah, thne that might work indeed
[13:49] <jdstrand> cjwatson: so, rsyslog is stuck: http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/update_excuses.html
[13:49] <jdstrand> rsyslog-mysql/armhf unsatisfiable Depends: dbconfig-common
[13:49] <jdstrand> oh heh
[13:49] <jdstrand> cjwatson: nm, looks like someone noticed it :)
[13:49] <jdstrand> I needed to refresh the page :)
[13:49] <imgbot> [13:49] <imgbot> [13:50] <sil2100> \o/
[13:50] <ogra_> well
[13:50] <ogra_> dont party to early
[13:51] <sil2100> _o_
[13:52] <ogra_> sil2100, hmm, somehow android-tools didnt end up in rtm 13
[13:52] <ogra_> oh !
[13:53] <ogra_> my mako refuses to OTA
[13:53]  * ogra_ looks for charger to get that working ... nice, we have a battery check now :) 
[13:54]  * ogra_ was just heavily shocked to find the same bug ... to then notice ther version isnt the latest ... phew
[13:55] <ogra_> ok, adb comes up in 237 ... no issues
[13:55] <ogra_> tedg, safe to upgrade
[13:57] <sil2100> davmor2: are you taking care of the unity8 silo?
[13:57] <ogra_> hmm
[13:57] <ogra_> mterry, i dont get asked for the existing pin when switching to swipe in 237 (utopic)
[13:58] <davmor2> sil2100: I was I just hit issues in online accounts and the edges fix doesn't seem to of fixed anything
[13:58] <mterry> ogra_, that can happen if you've recently changed password -- cached policykit authentication
[13:58] <ogra_> (settung pin and pw finally works as wexpected though :) )
[13:58] <sil2100> davmor2: oh?
[13:58] <sil2100> davmor2: damn
[13:58] <ogra_> mterry, uh, i thought pk cant cache
[13:58] <ogra_> mterry, that has always been the complaint from gksudo fans :)
[13:58] <sil2100> davmor2: btw. do you remember if the edges bug appeared on normal ubuntu as well?
[13:59] <davmor2> sil2100: never checked
[13:59] <sil2100> davmor2: since I wonder how they were fixing it, and since they mentioned it's fixed in ubuntu now I wondered if it was reproducible there as well
[13:59] <mterry> ogra_, it can if you set the policy type to something like auth_admin_keep
[13:59] <sil2100> davmor2: anyway, did you make sure you have all the packages from the silo installed?
[13:59] <ogra_> ah, good to know
[14:00] <davmor2> I'm double checking that now but it's hard to tell
[14:01] <brendand> ogra_, how do i recover my mako now? shouldn't power+volup boot in fastboot mode?
[14:01] <davmor2> bregma: power + vol up + vol down
[14:01] <ogra_> dunno, might be power+vol-dn or power and both vol buttons
[14:01]  * ogra_ hast had to do that in ages
[14:01] <davmor2> brendand: even ^
[14:02] <ogra_> sil2100, do i need to dput android-tools to rtm silo 13 ?
[14:02] <sil2100> ogra_: let me check
[14:03] <sil2100> ogra_: is 4.2.2+git20130218-3ubuntu33  not up-to-date enough?
[14:03] <ogra_> sil2100, no
[14:03] <ogra_> thats the broken version
[14:03] <sil2100> ogra_: btw. is it a problem if the lxc-android-config has ~rtm appended to the version number?
[14:03] <ogra_> not for me :)
[14:04] <sil2100> ogra_: so, I can press the build button and it will fetch android-tools from ubuntu and build it, but... it will append that ~rtm bit (which I guess is not wanted every-time)
[14:04] <ogra_> i dont really care
[14:05] <ogra_> the next version will surely be higher anyway
[14:05] <sil2100> ogra_: ok, let me press
[14:05] <sil2100> Yeah, that's the point actually
[14:05] <ogra_> ubuntu33 needs to go and get bruned
[14:06] <ogra_> (that was a 4 line upstart job  change ... but somehow a wrong quilt patch ended up in the same upload ... )
[14:08] <sil2100> ogra_: ok, I think I need to handle this better... anyway, could I ask you to dput the 0ubuntu34 version to the PPA?
[14:08] <sil2100> ogra_: since I see that the ~rtm addition can be troublesome here
[14:08] <ogra_> heh, sure, np
[14:08] <sil2100> ogra_: I must add a flag 'dont add the ~rtm' to the build job :|
[14:08] <sil2100> Since for packages that we build using CI Train it makes sense
[14:08] <ogra_> what makes it troublesome ?
[14:09] <sil2100> But for others, well, my heuristics don't do the right job
[14:09] <ogra_> ah, beacuse for the +git and stuff in the version ?
[14:10] <sil2100> ogra_: yeah, you only increment the ubuntu versioning with each release here, while the sync code tries to out-smart everyone and append ~rtm to the upstream version
[14:10] <sil2100> Which was not bumped for a while
[14:10] <sil2100> (as it assumes it's bumped with every release)
[14:10] <sil2100> Well, something I have plans to improve ;p
[14:10] <ogra_> yeah
[14:11] <ogra_> and likely wont be for another looong while :)
[14:11] <ogra_> in fact we should fork it to udbd
[14:11] <ogra_> :)
[14:11] <ogra_> instead of adbd
[14:11] <sil2100> hehe
[14:11] <ogra_> there is not much left of the original code :)
[14:17] <bzoltan> ogra_:  what could be the reason for the extreme long boot time? I am still on #235
[14:18] <ogra_> bzoltan, apparmor upgrade
[14:18] <bzoltan> ogra_:  What should I do?
[14:18] <ogra_> it regenerates all profiles ... and does that before the screen is initialized
[14:18] <ogra_> so it sits on the bootloader screen til it finished
[14:20] <bzoltan> ogra_:  In the last 2-3 hours I simple could not flash and set up for testing my mako ... random reboots, boot times like 5-10 minutes, random failing network setup ...
[14:21] <ogra_> i dont see that here
[14:21] <ogra_> i saw a 5min boot after upgrading to 237 ... but thats expected
[14:22] <ogra_> (and only happens on very first boot after OTA or flashing)
[14:24] <bzoltan> ogra_:  5 minutes? good to know ...
[14:24] <ogra_> well, or 3.5, i didnt stopwatch it :)
[14:24] <ogra_> it takes very long
[14:24] <bzoltan> ogra_: ohh, it does
[14:25] <ogra_> but you only get that when there were new apparmor bits usually
[14:25] <bzoltan> ogra_:  I am flashing my device like 20+ times a day
[14:25] <ogra_> well, as jdstrand said above ... there are plans to improve that
[14:26] <jdstrand> bzoltan: does that device have a ton of apps on it or just the default ones?
[14:26] <bzoltan> jdstrand:  just the default
[14:26] <jdstrand> right, it won't take terribly long for just the default apps
[14:26] <bzoltan> jdstrand:  All I do is flash and set up for testing ... but today was a bad bad day
[14:26] <jdstrand> sounds like today was not apparmor-- it won't take 2-3 hours :)
[14:27] <bzoltan> jdstrand:  it takes ages ... 3-5 minutes + random reboots + netwok config does not work + click test setup does not work + whatever
[14:27] <jdstrand> also, with default apps, we use precompiled policy
[14:27] <jdstrand> yeah, that sounds no good
[14:28] <brendand> agh what's wrong with my mako
[14:28] <bzoltan> brendand:  welcome to the club, dude
[14:28]  * jdstrand refrains from updating his mako
[14:28] <brendand> bzoltan, it seems dead
[14:29] <jdstrand> bzoltan: curious, are you on the rtm branch?
[14:29] <bzoltan> brendand:  boostrap might help .. thatis what I am doing right now ...
[14:29] <brendand> bzoltan, mine is just dead
[14:29] <bzoltan> jdstrand:  no, on Utopic.. on RTM there are more  problems
[14:29] <bzoltan> brendand:  like bricked?
[14:29] <jdstrand> huh. mako on rtm has been 'ok' for me (annoying not responding to touch after being in my pocket bug notwithstanding). I think that may be fixed now
[14:30] <ogra_> brendand, how dead ?
[14:30] <ogra_> mine is just fine after OTA to 237
[14:32]  * tedg is fearfully flashing 237
[14:33] <sil2100> brendand: don't scare us
[14:34] <bzoltan> sil2100:  I am straggling with my mako and with the tools all day. Not kidding... a wasted day
[14:35] <sil2100> bzoltan: on 237 or 235?
[14:35]  * tedg is now paranoid, is the ubuntu logo spinning slower than before?
[14:35] <ogra_> tedg, come on, have a little trust in my :)
[14:35] <ogra_> *me
[14:36] <bzoltan> sil2100:  237 is in the queue
[14:36] <sil2100> davmor2: did you get any info from Saviq on the edges bug-fix?
[14:36] <davmor2> sil2100: no I was in a meeting
[14:36]  * Saviq never got pubg
[14:36] <Saviq> pung
[14:36] <tedg> 237 flashed and works for me. Scopes, music, etc.
[14:36] <tedg> mako
[14:36] <bzoltan> sil2100:  but it is a combination of problems ... 235 become super slow to boot
[14:36] <tedg> ogra_, ^
[14:36] <ogra_> tedg, adn ?
[14:36] <ogra_> err
[14:36] <ogra_> adb
[14:36] <sil2100> Saviq: so, davmor2 reported that the qtmir landing doesn't seem to fix the input bug
[14:36] <sil2100> Saviq: for ubuntu-rtm
[14:37] <tedg> ogra_, Yeah, got a shell as phablet
[14:37] <Saviq> sil2100, it fixes one part of it
[14:37] <sil2100> bzoltan: ugh
[14:37] <sil2100> Saviq: oh, so it's not a complete fix then?
[14:37] <Saviq> sil2100, davmor2, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1295623/comments/21
[14:39] <tedg> Cool, and 237 has the versions of systemd-shim and upstart that I need.
[14:39]  * tedg does a happy dance.
[14:41] <ogra_> tedg, awesome !
[14:42] <dobey> anyone have a good suggestion to test on rtm without having a device without rtm, and without reflashing and killing what i'm currently working on, on a device? can not the test plan and qa signoff be a single step process?
[14:44] <brendand> dobey, you mean can QA run the tests for you?
[14:45] <dobey> brendand: right, is there an exact need for me to run the test plan and tick "yes" in that column on the spreadsheet before QA does the exact same thing?
[14:45] <ogra_> tedg, does "adb shell env" give you upstart and dbus addresses too ?
[14:46] <ogra_> thats the main purpose of the fix
[14:46] <tedg> ogra_, Yes: http://pastebin.ubuntu.com/8319459/
[14:47] <ogra_> \o/
[14:47] <ogra_> no more "sudo -u phablet -i" in scripts from now on :)
[14:47] <tedg> Heh, I'm still not over automatically typing "phablet" into the sudo prompt though.
[14:47] <sil2100> davmor2: once you're around, could you comment if what you see in the silo is what is expected as per the comment Saviq made? ^
[14:50] <davmor2> sil2100, Saviq: I'm just reading it now, so I have hit both I think.  I dragged up the additional scopes and got hit by it there where the scopes screen I couldn't do any thing with at all,  the other was by the test case of holding the browser icon on the apps scope while dragging out the launcher and opening the app there too
[14:51] <Saviq> davmor2, if you could not do anything at all (not even laucher or right edge), that sounds like either unity8 was hanging / crashing
[14:51] <dobey> brendand: does that make sense?
[14:52] <Saviq> davmor2, do you have steps to repro the dash overview issue?
[14:52] <sil2100> brendand: do you know if we had any exploratory dogfooding made in the last few days on krillin?
[14:52] <davmor2> Saviq: no I was just running various tests for the silo and that is part of unity8 so it is tested
[14:53] <brendand> dobey, really it is the development teams responsibility to make sure their silo is tested. QA just provides a final verification. this may include running the test plan as well as additional testing
[14:53] <davmor2> Saviq: I'm currently reflashing to ensure I got everything installed from the silos and then I'll be retesting so I'll keep an eye out for it and any crashers
[14:54] <brendand> dobey, you present something to us that you believe is of sufficient quality to land, and we attempt to prove otherwise
[14:55] <Saviq> davmor2, k thanks
[14:55] <brendand> dobey, do you have an issue with being able to run the tests?
[14:56] <brendand> dobey, overloaded device resources maybe (by what you've been saying)
[14:56] <cjwatson> dobey: is it runnable in the emulator?
[14:56] <cjwatson> at least minimally
[14:57] <dobey> brendand: yes, i don't have rtm on my mako, and i'm working on something else so i'd rather avoid flashing it at the moment.
[14:58] <dobey> cjwatson: probably, but i don't have an emulator set up and not quite sure how to at this point.
[14:58] <ogra_> bzoltan1, gah, the spreadheet cheated me (i edited one line above your line 25 and after "enter" it jumped into your field) i might have set your "testing pass" wrongly now
[14:58] <brendand> dobey, can someone else test?
[14:58] <dobey> brendand: that's what i'm asking :)
[14:58] <brendand> dobey, apart from us :)
[14:58] <ogra_> davmor2, have fun with silo 13 ;)
[14:59] <cjwatson> dobey: https://wiki.ubuntu.com/Touch/Emulator
[14:59] <cjwatson> armhf is dog slow, --arch=i386 was at least somewhat reasonably fast last I tried
[14:59] <davmor2> ogra_: not touching it I'm having enough fun with 10 and 17
[14:59] <ogra_> heh, k
[15:00] <dobey> yeah, i did armhf once a long long time ago, and it was completely unusable for me
[15:01] <dobey> would be neat if --arch=amd64 worked...
[15:02] <davmor2> dobey: you want to ditch those crappy low powered machines you have for work and buy a beast it works really slowly then instead of not at all ;)
[15:03] <dobey> davmor2: if a core i7 with 16 GB RAM is "low powered" then something is seriously wrong with the world
[15:03] <brendand> dobey, --arch=i386 will still work on amd64
[15:03] <davmor2> dobey: that was my point ;)
[15:03] <brendand> dobey, to some degree of 'work'
[15:03] <dobey> brendand: sure
[15:05] <dobey> ooh. 14MB/s from the image server. nice
[15:10] <bzoltan> ogra_:  you accidentally flipped that tested switch just 3 minutes after the silo actually passed the tests. You have magic power. Do you want to join the SDK team? :D
[15:11] <ogra_> lol
[15:18] <brendand> bzoltan, zsombi - bad luck - i have the bug in utopic too. you are getting booged :P
[15:19] <brendand> bzoltan, dunno how zsombi didn't see it
[15:21] <sil2100> brendand: what's up?
[15:21] <dobey> ok, emulator is not working so great. mouse clicking doesn't work so great, and typing correctly in the emulator is pretty well impossible :-/
[15:22] <sil2100> davmor2: so, what's the state of QA sign-off of the unity8 silo? Is it really broken and -1?
[15:22] <brendand> sil2100, you wanted me to do something earlier right? i never heard from you :)
[15:24] <sil2100> brendand: yeah, wanted to have some test results for 237 first through, but it seems to proceed slowly - anyway, did we have any exploratory testing for krillin images this week?
[15:26] <bzoltan> brendand: have you removed the ~phablet/autopilot/ubuntuuitoolkit ?
[15:26] <brendand> sil2100, i've only been on silos, davmor2 would know better
[15:26] <sil2100> davmor2: pong
[15:26] <brendand> bzoltan, it's nothing to do with autopilot
[15:26] <brendand> bzoltan, https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1368295
[15:26] <davmor2> sil2100: nothing yet
[15:27] <sil2100> davmor2: did you do any exploratory tests this week?
[15:27] <brendand> bzoltan, i haven't run any AP tests
[15:27] <bfiller> sil2100: if I want to just sync a package from ubuntu to ubuntu-rtm, how do I enter that in the sheet?
[15:27] <davmor2> sil2100: no as there was no image to consider.
[15:27] <brendand> bzoltan, although i found it because of the dialer-app AP tests
[15:27] <bzoltan> brendand:  ohh ... in that case you caught me :) thanks for the bug
[15:27] <sil2100> davmor2: I thought we're doing exploratory testing per-image, at least per selected images every now and then :)
[15:28] <bzoltan> brendand: why on earth it did not show on my tests -> http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/ap-2014_09_10-19_29_44-dialer_app-1.tests
[15:28] <davmor2> sil2100: om26er_ has been testing image on mako from utopic and rtm while everyone else has been concentrating on silos
[15:29] <brendand> bzoltan, the dialer-app tests aren't that complete
[15:29] <sil2100> Ok
[15:29] <sil2100> om26er_: hey!
[15:29] <brendand> bzoltan, there is no test to check that
[15:29] <bzoltan> brendand:  okey.. good to know
[15:29] <brendand> bzoltan, i only noticed it because i watched the test run
[15:29] <sil2100> om26er_: how does the ubuntu-rtm situation look like for mako?
[15:29] <bzoltan> brendand:  ahh.. watching the tests? That is so 80's
[15:29]  * sil2100 hopes for it to be at least some approximation of how things look
[15:30] <brendand> bzoltan, should i deliberately look away :P
[15:30] <davmor2> sil2100: broken I can tell you that ;)
[15:30] <bzoltan> brendand:  :D depends on your wallpaper
[15:30] <brendand> bzoltan, but the version in the silo is right and i can continue testing?
[15:30] <sil2100> davmor2: but but..!
[15:31] <sil2100> davmor2: it can't be THAT broken, right?
[15:31] <bzoltan> brendand:  yes, that is confirmed ... the silo has exactly the same as Utopic
[15:31] <davmor2> sil2100: don't make me list the ways we get told off for spamming the channels :P
[15:32] <brendand> bzoltan, so i'll finish testing and see if there are any more issues. you may as well fix them all at once
[15:33] <om26er_> sil2100, davmor2 i am testing utopic today
[15:34] <davmor2> om26er_: how was rtm yesterday then?
[15:35] <bzoltan> brendand:  if you see the same problem with the clock and the messaging app then it  is a clear UITK bug, if not than the app does something funny
[15:35] <om26er_> davmor2, the manual plan succeeded
[15:35] <om26er_> davmor2, it was fine
[15:36] <brendand> bzoltan, i don't agree with that
[15:36] <brendand> bzoltan, they are not going to be using the same code
[15:36] <bzoltan> brendand:  we fix it regardless of anything
[15:36] <brendand> bzoltan, even if slightly similar
[15:37] <brendand> bzoltan, well the fix may be in dialer-app, but your silo caused the regression so you need to investigate
[15:37] <bzoltan> bzoltan:  No question about that.
[15:38] <brendand> bzoltan, messaging and clock seem fine
[15:38] <bzoltan> brendand:  Good to know.
[15:39] <bzoltan> brendand:  i do not promise fix over night, but tomorrow it will be nailed down
[15:42] <bfiller> sil2100: can I have a silo for line 57 when you have a chance please?
[15:42] <sil2100> bfiller: hey! Sure, one moment, let me see if it's possible
[15:42] <alecu> hi trainguards: both installation of new apps and uninstallation seem to be broken on #237
[15:43] <alecu> is that known?
[15:46] <sil2100> bfiller: oh, but you already seem to have a sync silo for ubuntu-keyboard
[15:47] <bfiller> sil2100: I didn't see it, which one?
[15:47] <sil2100> bfiller: I see silo 11 is already assigned with ubuntu-keyboard and syncing from ubuntu/utopic
[15:47] <brendand> alecu, what error do you get?
[15:48] <bfiller> sil2100: ah ok
[15:49] <bfiller> sil2100: does the sync silo need to get rebuilt if the original silo was reconfigured with additional MR's or does that happen automatically? I just want to make sure what's in the sync silo matches what was released in the ubuntu silo yesterday
[15:50] <alecu> brendand: no error during uninstallation, and the error cannot be seen on installations; I'm enabling debugging now to see if I get some more info
[15:50] <bfiller> sil2100: nm, it looks correct
[15:50] <sil2100> bfiller: it's targetting ubuntu now, so if you press build (and mention 'ubuntu-keyboard') then you'll double-check if it's up-to-date there
[15:53] <brendand> alecu, yeah i confirm that on utopic. unfortunate
[15:59] <ogra_> sil2100, i'll be a minute late
[15:59] <ogra_> (or two)
[16:04] <alecu> trainguards, I think pkcon is broken in image #237, was there any landing for click? (not the scope, but click itself)
[16:04] <alecu> cjwatson: mvo_ ^
[16:05] <alecu> phablet@ubuntu-phablet:~/.cache/upstart$ pkcon -p remove "com.ubuntu.developer.webapps.webapp-amazon;1.0.9;all;local:click"
[16:05] <alecu> Failed to contact PackageKit: Error calling StartServiceByName for org.freedesktop.PackageKit: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PackageKit timed out
[16:05] <cjwatson> click was landed recently-ish but the packagekit plugin wasn't changed
[16:06] <cjwatson> packagekit was changed in rtm at the same time to add an option to packagekit; but that upload had been in devel-proposed for a while
[16:06] <alecu> it's the same when trying to install any click:
[16:06] <cjwatson> the click change was in 235
[16:09] <cjwatson> alecu: what log file would I expect to see this in when installing from the scope?
[16:11] <alecu> cjwatson: it should be in .cache/upstart/scope-registry.log, but it seems to only be logged after setting the click scope to debugging mode via an env var.
[16:11] <Mirv> bzoltan: MP:s not approved https://ci-train.ubuntu.com/job/ubuntu-landing-003-2-publish/17/console
[16:11] <alecu> cjwatson: anyway, it's easy to see by running the commands via phablet-shell
[16:12] <cjwatson> alecu: yeah, does udm leave the downloaded click packages anywhere?
[16:12] <cjwatson> so I don't have to scrabble about for one
[16:12] <alecu> cjwatson: since pkcon is returning zero, udm is deleting the files; I'll send some clicks your way
[16:13] <alecu> cjwatson: but you can also see it when trying to uninstall:
[16:13] <alecu> cjwatson: http://pastebin.ubuntu.com/8320061/
[16:15] <cjwatson> right.  this doesn't really feel like click breakage, I suspect something wrong with packagekit/policykit/something, but what ...
[16:16] <alecu> sounds reasonable
[16:16] <cjwatson> stricter permissions somewhere?
[16:16] <cjwatson> wondering if it could be fallout from the developer mode stuff
[16:17] <Mirv> sil2100: hey. consider running https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-003-2-publish/build?delay=0sec forced, after checking that yes indeed the landing seems to be already in rtm, somehow weirdly still in the dashboard but not in the spreadsheet
[16:17] <cjwatson> guess I could strace dbus and see what it's doing
[16:22] <cjwatson> it's executing packagekitd, at least
[16:23] <cjwatson> which dies quickly
[16:23] <alecu> cjwatson: when doing a dbus call like this, dbus activation will start the process and then wait for it to expose the dbus interface that's being called.
[16:24] <cjwatson> yeah I know
[16:24] <alecu> so, it must die before exposing the interface, because I don't see packagekitd running
[16:25] <cjwatson> 6512  16:23:32.190353 write(1, "Failed to load the backend: opening module aptcc failed : /usr/lib/arm-linux-gnueabihf/packagekit-backend/libpk_backend_aptcc.so: undefined symbol: forkpty", 155) = 155
[16:25] <cjwatson> That's novel
[16:25] <sergiusens> can I get a silo for line 54?
[16:26] <cjwatson> libpk_backend_aptcc.so doesn't link against libutil
[16:28] <alecu> should I assign the bug to packagekit? https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1368246
[16:28] <cjwatson> yes please, I'm still investigating but the missing linkage is a smoking gun
[16:29] <cjwatson> the question is how it ever worked
[16:29] <cjwatson> alecu: do you have a confirmed image number where it previously worked?
[16:30] <alecu> cjwatson: I think it worked on #236; I can reflash and check
[16:30] <cjwatson> alecu: would be useful to know, thanks.  I'll fix it in parallel though
[16:32] <dbarth> seb128: ping? qq did you unblock the uss location silo btw? i see it is still mentioned as "after silo 15" or so
[16:33] <seb128> dbarth, yeah, not sure but I think those changes landed in rtm, since we synced u-s-s from utopic
[16:33] <dbarth> so the line can be killed?
[16:34] <dbarth> i'll double the bug is gone while testing something else
[16:34] <dbarth> double check
[16:35] <seb128> yes, I think so
[16:41] <AlbertA2> jibel: on ubuntu-rtm/landing-001 QA testing.... automated CI testing has already ran...no need to worry about that...
[16:41] <cjwatson> alecu: building a candidate fix on the porter box now
[16:42] <alecu> great
[16:43] <jibel> AlbertA2, are the results published somewhere?
[16:43] <AlbertA2> kgunn: camako: ^
[16:47] <camako> AlbertA, if you go to the build page, you can find the build artifacts.. CI testing should be one of them
[16:48] <cjwatson> alecu: any luck?
[16:50] <AlbertA2> camako: ok
[16:50] <AlbertA2> jibel: https://launchpadlibrarian.net/184437882/buildlog_ubuntu-rtm-14.09-armhf.mir_0.7.1%2B14.10.20140909.1~rtm-0ubuntu1_UPLOADING.txt.gz
[16:51] <dobey> alecu, cjwatson: i can definitely confirm that pkcon install-local worked on 235 on mako, since i did it plenty (but it did require me to do --allow-untrusted)
[16:52] <cjwatson> the latter's expected now, yes
[16:52] <alecu> cjwatson: it's dog slow to download images here... still 75% of 236.
[16:52] <cjwatson> I think apt innocently dropped -lutil for some other reason and this exposed a latent packagekit bug
[16:53] <AlbertA2> jibel: and for ubuntu-rtm/landing-005, to answer the question posted - the fix touches code that is also used in krillin hence why it must be tested for krillin too...
[16:53] <cjwatson> but I'm trying to find the actual change to make sure
[16:56] <cjwatson> got it, http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=223ae57d468fdcac451209a095047a07a5698212
[16:57] <cjwatson> no longer references openpty so the linker drops the -lutil linkage
[16:57] <cjwatson> makes sense now
[17:03] <bzoltan> ogra_: nice ... phablet-network says "Error: No Wi-Fi device found."
[17:07] <dbarth> seb128: image 33 contains the fixes; i'll suppress the line now
[17:07] <cjwatson> alecu: fix uploaded.  doesn't affect rtm since it has an older apt.
[17:07] <cjwatson> have to run to dinner now
[17:07] <cjwatson> thanks for the heads-up
[17:07] <cjwatson> also https://github.com/hughsie/PackageKit/pull/11
[17:09] <alecu> great, thanks!
[17:09] <alecu> btw, probably no longer needed, but I just confirmed that 236 was broken
[17:10] <cjwatson> alecu: right, the apt change landed in 236
[17:11] <fginther> robru, are you online today?
[17:11] <robru> fginther: I am, what's up?
[17:11] <cjwatson> sil2100,robru: heads-up for the above conversation between alecu and me; doesn't affect RTM; I suggest building a new devel-proposed image once "rmadison -s utopic packagekit" says 0.8.17-4ubuntu3
[17:16] <lool> Hey trainguards; we've fixed the main issue with the positioning engine for location-service; would like to land the changes now; it's probably location-service branch + lxc-android-config upload
[17:16] <lool> in utopic for now
[17:16] <lool> May I take row 57?
[17:17] <sil2100> robru: ^ ? :)
[17:18] <robru> hey hey
[17:18] <lool> sil2100: for native pkgs, am I supposed to use regular version numbers in silo, and the source + bins get copied to Ubuntu
[17:19] <lool> I've listed stuff on line 57; waiting for silo
[17:20] <davmor2> sil2100: hey so dbarth has managed to reproduce the bug and it looks like there is a temporary work around we can use for evernote account creation.  So I am going to let dbarth file the bug as I'm sure he can add more detail and then carry on testing silos 10 and 17
[17:21] <davmor2> and see if we can't get them landed
[17:22] <dbarth> +1 bug filed
[17:23] <dbarth> and nice catch davmor2, legendary bug-finding-fu :)
[17:23] <ogra_> yeah ... long term he will own launchpad :)
[17:23] <ogra_> karma: 3986231590856103856
[17:24] <davmor2> ogra_: haha
[17:30] <lool> robru: is that enough to assign a silo?
[17:31] <lool> heya, if you have a minute, lp:~phablet/ubuntu-location-provider-here/trunk didn't autoland the last MP; I merged it by hand, would you know what's preventing this?
[17:33] <sil2100> lool: robru will be your guide, but in overall it's usually tricky when native packages are related - usually it's best to use a rule of the thumb: if you see that the given package doesn't impact RTM much and is safe to do a bin copy, then a binary copy should be fine
[17:34] <sil2100> robru: btw. I'm merging some fixes to the sync thing - if you notice any additional issues, please feel free to revert that
[17:36] <davmor2> ogra_: actually my karma stays around 1650-1700 because I mostly just file bugs you don't get much karma for find them only fixing them :D
[17:42] <lool> sil2100: okay; thanks!
[17:45] <robru> sil2100: ok
[17:46] <robru> lool: one sec
[17:46] <robru> lool: why does it say "WIP" under merge proposals?
[17:48] <lool> robru: we will submit an updated merge proposal (I have one here, but I'm not 100% sure it's the one we want to send)
[17:48] <lool> robru: should I leave this empty until we have the final one? (in an hour or so)
[17:50] <robru> lool: It's not clear to me what you're trying to accomplish with this landing request. why would I give you a silo with no MPs? it's certainly not valid to write 'WIP' in the MP field.
[17:51] <lool> robru: I'd like to land lxc-android-config there, then let thomas list his mp
[17:51] <robru> lool: also, what's the deal with lxc? you said sync: but the landing is for utopic. That makes no sense. sync means "sync from utopic to rtm". so sync only makes sense in the context of an rtm silo
[17:51] <robru> ok
[17:51] <lool> ok; I thought was for sync out of the silo into archive
[17:52] <lool> and had to be listed when you were uploading sources
[17:52] <robru> lool: you have to list sources when you're uploading sources. The 'sync:' syntax is just for RTM.
[17:53] <robru> lool: so I fixed your request and got you silo 2. you can upload lxc in there now
[17:53] <lool> robru: yup, understood now
[18:11] <robru> sil2100: hey what happened with your latest branch on cu2d?
[18:13] <robru> sil2100: like, it merged with test failures.
[18:13] <robru> hmmm
[18:25] <sil2100> robru: uh?
[18:25] <sil2100> robru: strange, I didn't touch that places at all
[18:26] <sil2100> robru: as you can see it's nothing in my branch
[18:28] <Ursinha> sometimes tests fail because of unintended side effects :) (I don't know what is the case here)
[18:29] <robru> sil2100: what I can see is that you changed the build job xml template, which I happen to have a test against (I wrote a test that confirms the new string.format templating works, and it happens to check the exact results of loading build.xml.tmpl, which your commit changes the result of ;-)
[18:30] <robru> sil2100: not sure how that managed to land on trunk, working with Ursinha to prevent that from happening again, but also I'm changing that test to just check for the important bits of build.xml without being so flaky about unimportant changes there
[18:30] <bfiller> robru: silo 15 can be published again, all MR's are now approved
[18:33] <robru> bfiller: ok published, you're now building in rtm12 https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-012-1-build/12/console
[18:33] <bfiller> robru: ty
[18:33] <sil2100> robru: it landed?
[18:33] <robru> sil2100: yeah your branch is in trunk
[18:34] <sil2100> robru: that's confusing - https://code.launchpad.net/~sil2100/cupstream2distro/cu2d-syncfixes/+merge/234346 <- says it's not merged yet
[18:35] <tvoss> sil2100, hey :) welcome back
[18:35] <tvoss> sil2100, got a question for line 9 in the spreadsheet
[18:35] <Ursinha> sil2100: that branch was changed from Merged to Needs Review, I think (if that's what you're using to infer that)
[18:35] <sil2100> tvoss: hey!
[18:36] <sil2100> Ursinha: that might be the case here, strange thing as the autolander said it failed as well ;)
[18:36] <sil2100> tvoss: what's up?
[18:36] <robru> sil2100: yeah, so what happened was that you probably marked the branch approved, so the -autolanding job came in and said "oh, it's approved, lets merge that to trunk, ok now that it's merged I'll run the tests again just to be safe. ooops, test failure! reject! needs fixing!" but it's in trunk already...
[18:36] <tvoss> sil2100, so line 8 landed in utopic, have a hard time making sense of line 9
[18:36] <Ursinha> sil2100: apparently that's not considering the test result to proceed with the merging, we're working on it
[18:37] <robru> sil2100: anyway don't worry about your code branch, I have some other refactoring going on, I merged it into the work I'm doing.
[18:37] <Ursinha> well, fginther mostly as he's the man who knows the stuff, I watch and learn
[18:37] <sil2100> tvoss: it seems it's failing to build, hmm
[18:37] <sil2100> Ursinha, robru: thanks ;)
[18:37] <robru> sil2100: you're welcome!
[18:38] <tvoss> sil2100, ah, got it
[19:19] <sergiusens> robru: hey, I have a line request since 8am and I don't see lack of silos being an issue
[19:19] <sergiusens> and now I also added line 59
[19:22] <bzoltan> ToyKeeper:  I finally managed to provision  my mako for RTM testing. It was everything but easy. No I started to run the tests, but I already see that tests crash without much reason and without any result
[19:26] <ToyKeeper> bzoltan: Sorry, I'm missing a little context.  Didn't you already have a mako set up for that?  The one which tested UITK on image mako-rtm 32?
[19:27] <bzoltan> ToyKeeper:  we agreed with brendand to run the tests again, because we have found a visual problem what was not discovered by the AP tests. https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1368295
[19:28] <bzoltan> ToyKeeper:  and so i started to provision my device and it failed big time...
[19:29] <bzoltan> ToyKeeper:  it is not going to be a joyride ... something is wrong
[19:30] <ToyKeeper> bzoltan: I heard about the dialer-app bug, but what's wrong with provisioning?  Did mako's feed hit a bump today?
[19:30] <ToyKeeper> I've gotten a little out of touch since I spend all my time on krillin these days.
[19:30] <bzoltan> ToyKeeper:  the dialer app thing is a minor problem, we will fix it tomorrow
[19:31] <bzoltan> ToyKeeper: My mako is just unstabe, or the tools are unstable...no idea
[19:32] <bzoltan> ToyKeeper:  as start the boot time went up to 6 minutes from 1, as second the phablet-network is unreliable or the network service is unreliable. phablet-network fails or the device does not connect to the wlan after reboot
[19:33] <bzoltan> ToyKeeper:  it reboots randomly for hack knows what reason...
[19:33] <ToyKeeper> Oh, hmm.  I've never used phablet-network.  Seemed irrelevant since I'm not using network-manager.
[19:34] <bzoltan> ToyKeeper:  One Ubuntu release (236) had no adb support
[19:34] <ToyKeeper> No adb is definitely a big problem.
[19:34] <bzoltan> ToyKeeper:  phablet-network could be important if you script the process
[19:35] <ToyKeeper> bzoltan: No, no need: adb shell nmcli d wifi connect APNAME password APPASSWD iface wlan0
[19:36] <bzoltan> ToyKeeper:  Well... that is something I will not ever put in a script :) for obvious reasons ...
[19:37] <bzoltan> ToyKeeper:  but it is a good fallback solution
[19:38] <ToyKeeper> Just put the private details in ~/.private/wap_info or something, and source it in the script.  No need to publish the details on launchpad.
[19:39] <bzoltan> ToyKeeper:  I make this script for the whole SDK team... it should be simple. I expect the phablet-network to work. It is a tool from the ubuntu archive.
[19:40] <bzoltan> ToyKeeper:  but that is not the only troublemaker ... more scary that AP tests simple crash
[19:40] <ToyKeeper> I've been trying to use NetworkManager for almost a decade, and have never gotten it to function reliably on a notebook, so I use something else.  phablet-network is a neat idea, but it relies on NM so I can't use it.
[19:42] <bzoltan> ToyKeeper:  I am using nm for almost 3 years without problem. I am lucky :) But I am not sure that the problem here is the nm ... the wlan0 interface just disappears sometimes from the device
[19:42] <ToyKeeper> That would definitely be an issue.
[19:43] <sil2100> o/
[19:44] <ToyKeeper> As for tests failing, I found that several test suites had high failures rates...  49/51 failed on unity8, 7/7 failed on calendar_app, 17/17 failed on music_app, 13-29/41 failed on gallery_app.
[19:44] <bzoltan> ToyKeeper:  It is soon 11pm here, so I give it up for today...
[19:44] <ToyKeeper> online_accounts_ui didn't even run (found 0 tests).
[19:44] <bzoltan> ToyKeeper:  not failing .. _crashing_
[19:45] <ToyKeeper> In any case, it sounds like I should avoid updating mako for a while, since I'm not actively involved in fixing whatever just failed.
[19:46] <bzoltan> ToyKeeper: LOL ... my mako has a wlan12 interface
[19:49] <slangasek> can anybody explain to me what I'm doing wrong here?:
[19:49] <slangasek> ~ ~/bin/ubuntu-emulator create --arch=i386 --channel=ubuntu-touch/ubuntu-rtm/14.09 rtm
[19:49] <slangasek> Failed to locate latest image information
[19:49] <bzoltan> ToyKeeper: brendand: I stop the RTM silo9 UITK validation. I give it an 8 hours rest and try again in the morning :)
[19:50] <bfiller> robru: need silos for line 55 and 60 when you have time
[19:52] <robru> bfiller: line 55 is missing target distro (column H)
[19:53] <bfiller> robru: fixed
[19:53] <bzoltan> slangasek:  are you sure that there is an i386 build of the RTM?
[19:53] <robru> bfiller: thanks. hm, seems there are 0 rtm silos available... i'll see if I can free one up
[19:53] <slangasek> bzoltan: well, apparently there isn't - the channel exists and is empty!
[19:54] <slangasek> bzoltan: thanks, I was just about to check that
[19:54] <bzoltan> slangasek:  it would be cool to have an RTM emulator
[19:54] <robru> bfiller: you got utopic10 at least
[19:54] <bfiller> robru: thanks, silo 11 and 12 in rtm are good to be published
[19:54] <slangasek> bzoltan: yes, I would say it should have been a baseline requirement ;)
[19:54] <slangasek> let me fix that
[19:55] <bzoltan> slangasek:  :) go for it
[19:56] <slangasek> oh, it's because I wasn't using -proposed and we don't have any promoted images yet :(
[19:57] <robru> brendand: ToyKeeper: mandel: what's going on with silo rtm-6? it's been awaiting signoff since august 29th... would be nice to get that either approved or rejected so we can reclaim the silo.
[19:58] <robru> elopio: ^
[19:58] <elopio> robru: last comment from rvr: According to mandel, this was working with previous images, but something else must be changed that prevents the location-service to work as expected. They are looking into that and will ping us when ready.
[19:59] <elopio> I'm not sure if the process is to wait for the developer, or to reject it so the silo can be reused.
[20:01] <brendand> robru, august 29th?
[20:02] <brendand> robru, it wasn't set to QA sign-off until tuesday
[20:04] <robru> brendand: well the packages in the ppa were built on the 29th.
[20:04] <robru> elopio: not a hard rule there... we're out of silos so I'm looking for ones to free. don't want to screw them if they're actively working on it, it just happened to look very stale an inactive based on simple heuristics...
[20:06] <elopio> robru: that comment is from this morning, so I would hope mandel to get back to us tomorrow. It would be nice if he can keep the silo, but if you need it I guess he'll also understand.
[20:09] <brendand> robru, you probably want to ask mandel why it took him a week and a half to test it
[20:09] <cjwatson> can I build a new devel-proposed image so that click package installation works again?
[20:09] <cjwatson> or are we just going to wait for cron?
[20:12] <brendand> robru, 18 has been sitting around since the beginning of the week as well
[20:14] <brendand> robru, and 3 seems to be having some trouble
[20:14] <Saviq> fginther, hey, could you please delete https://code.launchpad.net/~ps-jenkins/unity8/ubuntu-utopic-proposed
[20:15] <robru> brendand: wait what's happening in 3? was it published?
[20:15] <Saviq> fginther, or at least run http://people.canonical.com/~msawicz/unity8/strip-u8-tags.py on it
[20:15] <brendand> robru, it was signed off
[20:15] <brendand> or maybe not
[20:16] <robru> brendand: signed off or not, rtm has what's in that silo! ;-)
[20:16] <robru> freeing it...
[20:16] <brendand> robru, i suppose it was classed as 'bugfix only'
[20:16] <fginther> Saviq, I can delete that
[20:17] <Saviq> fginther, I know you can, you're the only one ;)
[20:18] <fginther> Saviq, done
[20:19] <Saviq> fginther, thans
[20:19] <Saviq> k
[20:19]  * Saviq needs to get used to using more force
[20:19] <cjwatson> ok, I guess nobody really objects; image build requested, will run shortly
[20:24] <robru> Warning: I am about to deploy a massive overhaul to ci train. It may shoot deadly beams into your eyes and then explode, so get your safety goggles ready.
[20:24] <imgbot> [20:29] <robru> bfiller: you got silo rtm3 for your font sync, and congrats on being the 2000th landing in citrain ;-) https://ci-train.ubuntu.com/job/prepare-silo/2000/console
[20:31] <kenvandine> robru, did you break the spreadsheet?
[20:31] <kenvandine> :-D
[20:31] <kenvandine> column C is broken
[20:31] <robru> kenvandine: yeah I broke something...
[20:32] <kenvandine> ok, i need to reconfigure... but the train got angry
[20:32] <robru> kenvandine: actually I think the spreadsheet might have just crapped on itself... I was only tinkering with jenkins
[20:33] <kenvandine> damn spreadsheets :)
[20:34] <kenvandine> seb128, ^^^ that'll hold up getting that other fix in there
[20:34] <seb128> kenvandine, k
[20:41] <robru> bfiller: https://launchpad.net/ubuntu/+source/ttf-ancient-fonts-symbola this package name you're trying to sync doesn't seem to exist
[20:44] <robru> kenvandine: ok sorry was putting out a different fire. what's up with your thing?
[20:44] <robru> kenvandine: which row / silo?
[20:45] <kenvandine> robru, row 61
[20:45] <kenvandine> it's building in silo 4
[20:45] <kenvandine> it won't let me reconfigure it because the spreadsheet doesn't know it's in a silo
[20:47] <kenvandine> robru, and scrolling up i see some older ones with no status that are already checked as tests passed and qa verified
[20:48] <kenvandine> probably already landed, but no status
[20:51] <robru> hm
[20:52] <kenvandine> robru, thanks, can i reconfigure now?
[20:53] <robru> kenvandine: already did ;-)
[20:53] <kenvandine> thx :)
[20:53] <kenvandine> robru, did you kick a new build?
[20:53]  * kenvandine will if not
[20:54] <robru> kenvandine: oh, nope
[20:55] <kenvandine> ok, good
[20:55] <kenvandine> i'm doing it
[21:00] <robru> kenvandine: which ones in the spreadsheet did you say looked like they'd been landed but had wrong status?
[21:00] <robru> found a couple in silos missing their status, wasn't sure what landed.
[21:02] <kenvandine> robru, 41
[21:02] <kenvandine> shows testing passed...
[21:02] <kenvandine> so must have been built
[21:03] <kenvandine> line 33 too
[21:03] <kenvandine> oh... you're finding them :)
[21:04] <ralsina> trainguards, I swear line 43 has already landed :-)
[21:05] <kenvandine> ralsina, QA even tested it
[21:05] <ralsina> yep :-)
[21:05] <kenvandine> ralsina, robru: so it was in a silo at least
[21:05] <ralsina> it was in rtm-8
[21:05] <ralsina> [17:34:48] [queuebot] Silos: ubuntu-rtm/landing-008 (ralsina) Landed. Cleaning silo. (account-polld, ubuntu-push)
[21:06] <ralsina> that's 30 minutes ago
[21:08] <robru> yeah the spreadsheet is messed, sigh
[22:04] <ToyKeeper> robru: Er, what?  Silo rtm-6 is that old?  I see an archived card for it which was marked as "pass" on Aug 26, then a new card for the same silo number which was created today.
[22:04] <imgbot> [22:04] <imgbot> [22:05] <robru> ToyKeeper: yup it's just been sitting there since the 29th as far as I can see
[22:05] <ToyKeeper> robru: The latest status I see on the card is from a few hours ago.  "Victor wrote: According to mandel, this was working with previous images, but something else must be changed that prevents the location-service to work as expected. They are looking into that and will ping us when ready."
[22:07] <ToyKeeper> robru: I see this in the IRC log, which I think is when the card got created: 2014-09-08 08:37:56 -queuebot	trainguards, ubuntu-rtm/landing-006: Packages built. Testing pass. QA needs to sign off.
[22:07] <ToyKeeper> Before that, the previous event was at 2014-08-29 06:45:04
[22:08] <ToyKeeper> I'm guessing the 08-29 event probably got missed by the auto-card-creator (was buggy at the time) and not noticed by any humans (who thought the bot was functional).
[22:08] <robru> hmm
[22:09] <ToyKeeper> In any case, it got lots of attention today and is apparently waiting on upstream fixes.
[22:09] <robru> ToyKeeper: no worries now, three other silos freed up, so no pressure to free that one. just curious that it's been around so long
[22:09] <ToyKeeper> I don't really know the story; this is just what I could dig up.
[22:13] <robru> ToyKeeper: no worries, thanks