[00:08] <ribru> bfiller: messaging-app conflicts with rtm26
[00:09] <bfiller> ribru: rtm26 safe to ignore for now as that won't land in 10/30 image
[00:09] <ribru> bfiller: ok cool
[00:09] <ribru> bfiller: you got rtm 4
[00:09] <bfiller> ribru: thanks
[00:13] <ribru> bfiller: you're welcome
[00:15] <ribru> bfiller: rtm 9 ;-)
[00:15] <bfiller> ribru: awesome
[01:11] <infinity> ribru: Curious.  So, I have literally zero insight into how it's being used in the CI infrastructure.
[01:11] <infinity> ribru: I can tell you that it's harmless for it to fail to load, but no idea without access to all the moving parts to tell you how it's broken or how to fix it.
[01:12] <ribru> infinity: well I can't speak for all of CI, but within ci train / lp:cupstream2distro, this is the only file that references it: http://bazaar.launchpad.net/+branch/cupstream2distro/view/head:/chroot-tools/.pbuilderrc
[01:13] <ribru> infinity: barry mentioned he was also bit by this eatmydata issue, so it seems like eatmydata is just broken for all of vivid as far as I can tell. that config works fine as-is for trusty and utopic. and I confirmed the package is installed and file present in vivid. so there's something else going on causing it to fail to load
[01:14] <infinity> ribru: Well, there has been a pretty massive version bump (26 to 82) between utopic and vivid, so it's possible calling conventions changed or something.
[01:14] <ribru> hrm
[01:15] <infinity> http://bazaar.launchpad.net/+branch/cupstream2distro/view/head:/chroot-tools/.pbuilderrc
[01:15] <infinity> Or that.
[01:15] <infinity> Err.
[01:15] <infinity>     + debian/rules: move shared library to /usr/lib/<triplet>/libeatmydata.
[01:15] <infinity> That.
[01:16] <ribru> hrm
[01:16] <ribru> infinity: https://wiki.ubuntu.com/PbuilderHowto#eatmydata not sure why I didn't think to google this earlier ;-)
[01:16] <ribru> barry:  ^^ ;-)
[01:18] <infinity> So you probably want something like export LD_PRELOAD="${LD_PRELOAD:+$LD_PRELOAD:}/usr/lib/$(dpkg-architecture -a$ARCH -qDEB_HOST_MULTIARCH)/libeatmydata/libeatmydata.so"
[01:19] <infinity> But only for vivid+
[01:19] <ribru> infinity: -a$ARCH?
[01:19] <infinity> Also, oh god, why do we still have pbuilder in our infrastructure, it burns, make it stop.
[01:20] <infinity> ribru: It seems that script has $ARCH as the target dpkg arch.
[01:20] <ribru> infinity: lol. too many other fires to put out before that one. but all of ci train / jenkins /etc is going away Real Soon Now, so let's cross our fingers that the new uci-engine isn't using it
[01:20] <ribru> ah
[01:21] <ribru> infinity: what's the easiest way to conditionalize "if vivid: foo; else: bar" in this case
[01:21] <ribru> or query the version of eatmydata installed..
[01:21] <infinity> ribru: You have $DIST, you can test.  Simlper to test for older dists, though with all this having a short life (in theory), it makes little difference.
[01:22] <ribru> infinity: slippery slope though, don't want to be sloppy just in case it sticks around too much longer ;-)
[01:22] <infinity> ribru: But I'd use a case.
[01:23] <ribru> infinity: is pbuilderrc just a shell script? it seems to be calling mkdir but other than that I'm not sure if it has full shell support to do whatever
[01:23] <infinity> ribru: Looks like shell to me.
[01:24] <infinity> ribru: case $DIST in\n  precise|trusty|utopic) do_old_way;;\n  *) do_new_way;;\nesac
[01:25] <ribru> infinity: there's no easy way to do version number matching with apt-cache or something right?
[01:25] <infinity> ribru: You're not in the chroot at that point, so no.
[01:25] <ribru> crap
[01:25] <ribru> no wait
[01:25] <infinity> ribru: And, if the chroots are tarballs (which it looks like), you can't even look in them yet.
[01:25] <ribru> infinity: but it just calls lsb_release to populate $DIST, that must mean it's inside the chroot, doesn't it?
[01:26] <ribru> otherwise $DIST would just be the $DIST of the host system
[01:26] <infinity> ribru: No, it's not actually using that.
[01:26] <infinity> ribru: Those lines populate the variables to the host system's setup if you don't feed it better defaults, which you obviously do.
[01:26] <ribru> hmmmm
[01:27] <ribru> ok
[01:32] <ribru> infinity: can I trouble you for a quick review? https://code.launchpad.net/~robru/cupstream2distro/fix-eatmydata/+merge/239782
[01:39] <ribru> bfiller: rtm 12 ;-)
[01:39] <bfiller> ribru: nice
[01:40] <ribru> infinity: https://ci-train.ubuntu.com/job/upgrade-chroot/114/console well I pushed that branch into production and it seems to be not working. Hrm
[01:43] <ribru> no qa?
[01:44] <ribru> that's better
[01:48] <infinity> ribru: Got it all sorted out?
[01:48] <ribru> infinity: sure didn't!
[01:48] <ribru> infinity: tried it your way and the wiki way (which suggests relative instead of absolute path), both are still spewing like crazy in vivid
[01:49] <infinity> ribru: So just make the vivid path not use the LD_PRELOAD at all, and we can revisit it later if speed is a huge issue.
[01:49] <ribru> infinity: seems reasonable.
[01:49] <infinity> ribru: Certainly not something I want to debug blind at 8pm on a day off. ;)
[01:49] <ribru> infinity: just gonna play with a bit in a local chroot since tinkering with jenkins remotely is fiddly.
[01:50] <ribru> infinity: haha, didn't realize it's a day off for you. regular day for me. Ok I'll try a couple things and if it fails I'll just disable it. thanks for the input
[03:04] <imgbot> [04:19] <imgbot> [04:19] <imgbot> [05:39] <Mirv> ribru: thanks!
[05:41] <Mirv> ribru: I'll free up 15 soonish, but I'll make a copy of it for utopic desktop users somewhere as some like using it
[05:46] <Mirv> ribru: the eatmydata seems familiar and is harmless. we should just get it properly installed so that it could do its job (speed up i/o)
[05:51] <ribru> Mirv: you're welcome. My latest branch disables eatmydata for vivid until a solution can be found. If you have any insight, branches welcome ;-)
[05:55] <ribru> Mirv: the pbuilder howto wiki mentions a change to eatmydata in vivid and suggests and alternate configuration but i wasn't able to get it working. Preprod is useless here but feel free to tinker with it in production. lp:cupstream2distro /chroot-tools/.pbuilderrc
[05:56] <ribru> Mirv: check the commits on my latest merge to see what didn't work....
[06:02] <Mirv> ribru: thanks, I'll check them. I'm sure eatmydata was not a crucial part of our performance anyway, it's more of a desperate measure in case of slow hard drives etc
[06:03] <ribru> Mirv: i don't have any hard metrics on the performance with out without it. Maybe we should put some timers on the build job and try building the same packages in utopic and vivid ;-)
[06:04] <ribru> Mirv: you know, a million times, and average the results, like python's mtimeit ;-)
[06:07] <Mirv> it could help a bit in the packages unpacking part which is quite i/o bound
[07:26]  * Mirv converts utopic silos to vivid
[08:28]  * ogra_ tries to decypher ribru's mail ... 
[08:59] <sil2100> hmmm
[09:00] <ogra_> i guess we want tvoss around before touching anything
[09:02] <Mirv> hmmmm
[09:03] <ogra_> though looking at https://launchpadlibrarian.net/188458283/buildlog_ubuntu-vivid-amd64.location-service_2.1%2B15.04.20141027.1-0ubuntu1_FAILEDTOBUILD.txt.gz this is a clear test failure, not sure how it wouold related to mis-merging
[09:03] <ogra_> *would relate
[09:09] <Mirv> sil2100: so, after robru accepted my yesterday's cu2d branch and did some additional fixes, I've changed most utopic silos to be now vivid
[09:10] <Mirv> also, first vivid publish done
[09:16] <ogra_> sigh
[09:16] <ogra_> apport right after OTA to 133 ... my UI hangs
[09:16] <ogra_> and kills the session
[09:17]  * ogra_ sees a fresh unity8 crash file 
[09:21] <sil2100> ogra_: yeah, anyway I would indeed wait for tvoss, not sure if he'll be around today though
[09:21] <sil2100> Mirv: \o/
[09:25] <dbarth> good morning, is vivid available for mako currently?
[09:25] <dbarth> --channel=ubuntu-touch/vivid gives me an error like
[09:26] <dbarth> Failed to locate latest image information
[09:27] <ogra_> dbarth, that would mean we have promoted something :)
[09:27] <ogra_> you would want vivid-proposed ... (but you should simply not use versioned channels, so devel-proposed) ...
[09:27] <sil2100> Would be nice to find some cycles to promote a devel channel image anyway, at least sometimes in the nearest future
[09:28] <ogra_> there were no successful image builds yet
[09:29] <dbarth> ogra_: ok, makes sense; i should have known better... ;)
[09:29] <dbarth> hmm, but vivid-proposed says the same
[09:30] <sil2100> Not sure if we build vivid images yet
[09:30] <sil2100> ogra_: right?
[09:31] <dbarth> ah
[09:31] <ogra_> sil2100, i saw one failed attempt
[09:31] <dbarth> so i can still stack my brand new vivid silo on top of my utopic image?
[09:31] <ogra_> havent checked deeper yet, i was waiting til desktop images build
[09:33] <pstolowski> trainguards, Mirv I've fixed the URL in line #57
[09:34] <Mirv> dbarth: essentially yes, but you need to add the silo url manually since apt-add-repository would add it as "utopic" to sources.list
[09:35] <dbarth> ah ok np
[09:35] <dbarth> we're really on the edge with vivid today ;)
[09:35] <popey> \o/ browser locked up
[09:42] <sil2100> psivaa_: hey!
[09:52] <pstolowski> trainguards hey, can i get a silo for line #57?
[09:56] <Mirv> pstolowski: sure, we just have a meeting ongoing
[10:08] <popey> davmor2: quick, make a webapp from that!
[10:08] <sil2100> Wompwompwomp
[10:09] <davmor2> popey: not a bad idea I'll look into it after
[10:10] <Mirv> with not one but two Qt silos it looks like I'm breaking up the usability of http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q= a bit :( so much scroll, no fun.
[10:10] <Mirv> I'll free up the utopic once I've vivid up to speed and have made backup of the utopic to somewhere
[10:10] <sil2100> Much scroll? Very big
[10:10] <sil2100> Wow wow
[10:10] <sil2100> ;)
[10:11] <Mirv> exactly!
[10:16] <ogra_> W: Failure trying to run: chroot /build/chroot mount -t proc proc /proc
[10:16] <ogra_> W: See /build/chroot/debootstrap/debootstrap.log for details
[10:16] <ogra_> P: Begin unmounting filesystems...
[10:16] <ogra_> sil2100, ^^^^ thats the armhf image build failure
[10:17] <ogra_> fails very early on ... when greating the first chroot
[10:17] <ogra_> *creating
[10:20] <sil2100> hm, doesn't make much sense, why is that failing?
[10:21] <sil2100> We need someone from the elders to check that out
[10:21] <ogra_> thats just fallout, most likely some packages couldnt be unpacked, sadly you cant see that bit
[10:21] <sil2100> (a reference to the presentation from Alexander last week)
[10:21] <ogra_> debootstrap isnt very verbose
[10:21] <ogra_> yeah
[10:21] <ogra_> i pinged adam about it
[10:22] <ogra_> i'll try a deboostrap myself here
[10:22] <sil2100> debootstrap for vivid worked fine on i386 (or amd64?) on the citrain jenkins though
[10:22] <ogra_> yeah, it does
[10:22] <ogra_> it does also for thex86 images
[10:23] <ogra_> (for touch)
[10:24] <ogra_> ubuntu-core fails the same way
[10:24] <ogra_> https://launchpadlibrarian.net/188476083/buildlog_ubuntu_vivid_armhf_ubuntu-core_FAILEDTOBUILD.txt.gz
[10:25] <ogra_> for all arm builds https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core/
[10:25] <ogra_> so i guess infinity is aware already
[10:51] <sil2100> btw. I really hate car mechanics, gave them my car before flying off to Washington and they had a week to finish some maintenance
[10:51] <sil2100> They were even saying it might be done earlier
[10:51]  * ogra_ did the same with his coffee machie 
[10:51] <ogra_> got it back yesterday :)
[10:52] <sil2100> But it seems that they will only be done on Thu, so I'm stuck without a car for 2 more days :o
[10:52] <sil2100> heh ;)
[10:52] <ogra_> well, at least you will be able to get to work ...
[10:52] <brendand> sil2100, coffee is way more important than driving though
[10:52] <ogra_> ++
[10:53]  * brendand will try rolling back the image to see if messaging_app AP tests stop crashing
[10:54] <sil2100> ogra_: btw. poked on #ubuntu-unity regarding hud, but best indeed if we wait for Saviq to be back
[10:54] <ogra_> right, or mzanetti
[10:55] <brendand> ogra_, what image had the hud removal?
[10:55] <sil2100> cihelp: hey! We would need someone from CI to help us out with smoketesting dashboard results - is anyone available for that today?
[10:55] <ogra_> brendand, 126
[10:56] <brendand> ogra_, oh that long ago. hmm
[10:56] <ogra_> yeah
[10:56] <ogra_> brendand, well, that was friday
[10:57] <ogra_> (or rather even sat. ... it was dropped on fri. image built on sat.)
[11:00] <popey> Mirv: could you please upload calendar to store http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.calendar_0.4.531_all.click
[11:01] <Mirv> sil2100: I hate car mechanics too, that's why I drive 50+km and travel back with public transport when my car requires service, just because I've finally found one place that actually treats customers well
[11:01] <Mirv> or if it's a one day job, I work from a nearby cafe and simply drive back at eod
[11:05] <sil2100> Mirv: lucky! I mean, I would be willing to do that as well, but the car mechanics that are just like 100m from my apartment were normally timely
[11:05] <ogra_> sil2100, oh ... can we actually turn line 61 into "landed" state somehow ?
[11:05] <sil2100> ogra_: looking
[11:05] <ogra_> (hud removal ... )
[11:06] <sil2100> Sure, doing
[11:06] <sil2100> Done
[11:07] <ogra_> thx
[11:08] <brendand> ogra_, i flashed 128. i guess if the messaging tests do well here then we can rule out the hud removal. let's see
[11:09] <ogra_> hmm
[11:09] <ogra_> i actually wonder if the framework itself specifies the hud somewhere
[11:09] <brendand> although it looks like it's already crashed
[11:09] <brendand> :/
[11:09] <brendand> before i even got to run them
[11:09] <ogra_> or unity-voice-service
[11:10] <ogra_> (without haveing a dependency)
[11:12] <brendand> ogra_, it takes a really long time to restart unity8 too
[11:12] <ogra_> sometimes, yeah
[11:12]  * ogra_ has seen that here too
[11:23] <Mirv> popey: calendar uploaded
[11:23] <popey> thanks
[11:27] <brendand> ogra_, we should probably all be collecting stack traces when we have these crashes
[11:28] <ogra_> brendand, well, mine seem to all be uploaded to e.u.c
[11:29] <ogra_> https://errors.ubuntu.com/?package=unity8&period=day
[11:29] <ogra_> hmm
[11:29] <brendand> ogra_, shit - look at thursday/friday
[11:30] <brendand> ogra_, although perhaps that's just the effect of the release
[11:31] <ogra_> hmm, so this is better https://errors.ubuntu.com/?package=unity8&period=week&pkg_arch=armhf
[11:32] <brendand> ogra_, 128 seems to be a lot more stable and that was after the hud removal
[11:32]  * ogra_ wonders where ubuntu-rtm errors actually go 
[11:33] <ogra_> there is no way to look them up on errors.u.c it seems
[11:34] <brendand> ogra_, yeah they all seem to be from utopic
[11:34] <ogra_> right, which doesnt have the most recent unity8
[11:35] <ogra_> ev, do we have errors.u.c for ubuntu-rtm somewhere ?
[11:35] <ogra_> now that we land in vivid the utopic data doesnt help much anymore (as the vivid data wont since everything moved on)
[11:37] <asac> unity is again spinning the spinner and doedsnt come back
[11:38] <ogra_> asac, see above ... thats what we are researching
[11:38] <asac> ok cool any info?
[11:38] <ogra_> sadly all our info sources dont really help much ... pointing to utopic or vivid
[11:39] <ogra_> utopic is to old, vivid has moved on beyond whats in 14.09
[11:39] <asac> and?
[11:39] <asac> i dont see how that prevents us from figurinng this
[11:39] <ogra_> that measn we cant get proper info from errors.u.c
[11:39] <ogra_> beyond that brendand is going back through the images atm
[11:39] <asac> i thought that we fixed that
[11:40] <ogra_> if we did i wouldnt know how to get that info summary
[11:40] <asac> e.g. we have the right symbols on retracers for derived distro
[11:40] <ogra_> do you ?
[11:40] <asac> yes
[11:40]  * asac asks pitti in -touch
[11:47] <popey> Mirv: also, please upload sudoku. http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/lastSuccessfulBuild/artifact/generic-click-builder-utopic-armhf/output/com.ubuntu.sudoku_1.1.312_all.click
[11:48] <asac> ogra_: sil2100: https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8%3A6%3A__assert_fail_base%3A__GI___assert_fail%3A__GI___pthread_mutex_lock%3A__gthread_mutex_lock%3Astd%3A%3Amutex%3A%3Alock
[11:48] <asac> tahts the unity crash ogra is seeing
[11:48] <asac> brendand: ^
[11:48] <asac> if thats our crash, thats the starting point
[11:48] <asac> started on oct 10 on RTM
[11:48] <asac> what landed on oct 9/10 ?
[11:48] <asac> :)
[11:49] <satoris> Mirv: any idea why line 41 has been given up on and if there is something we need to do to get it back on track?
[11:50] <ogra_> asac, depends :) image 94,95 and 96 were built in that timeframe http://people.canonical.com/~ogra/touch-image-stats/rtm/
[11:50] <ogra_> 94 had an ubuntu-app-launch
[11:50] <brendand> asac, but that would have been in the bq image then
[11:50] <brendand> asac, there's no way we wouldn't have noticed when qa-ing it
[11:50] <ogra_> 95 a new UITK
[11:50] <asac> pulse
[11:50] <asac> :)
[11:51] <asac> we have a playback crash here
[11:51] <ogra_> and 96 a new unity8
[11:51] <asac> ogra_: so maybe its indeed OOM because you have soooo many albums?
[11:51]  * ogra_ wonders if thats a red herring 
[11:51] <brendand> ogra_, i feel like it is
[11:51] <asac> good
[11:51] <asac> i got a new unity one
[11:51] <ogra_> the "feelable" crashyness only started end of last week
[11:52] <asac> that really tears down everything here
[11:52] <ogra_> yeah
[11:52] <ogra_> i have that on nearly every reboot
[11:52] <asac> https://errors.ubuntu.com/oops/47162672-5e98-11e4-a34f-fa163e22e467
[11:52] <asac> thats mine
[11:52] <asac> from just now
[11:52] <brendand> ogra_, only 10 crashes since two weeks doesn't stack up if that's the one crash
[11:52] <ogra_> brendand, did you try something pre 126 yet ?
[11:52] <ogra_> right
[11:52] <asac> ig guess thhat might have to get processed first
[11:53] <brendand> ogra_, no. 128 seemed more stable though. but still not totally stable
[11:53] <ogra_> right
[11:53] <ogra_> i remember at the airport 128 was rather stable for me while it constantly crashed for davmor2
[11:53] <brendand> ogra_, i'll try pre 126 next
[11:54] <brendand> ogra_, yeah but davmor2 is special :)
[11:54] <ogra_> true
[11:54] <ogra_> i know that i manually rolled back the hud stuff though ... when searching for the apt issue
[11:55] <ogra_> that might have gotten me this tiny bit better stability
[11:56] <brendand> ogra_, yeah the hud i think is the top culprit right now
[11:56] <ogra_> well, i guess rather unity-voice-service than the hud actually
[11:56] <ogra_> missing dep or so
[12:04] <davmor2> ogra_: please do a very careful review of sadtrombone.webapp on your phone ;)
[12:04] <ogra_> davmor2, you mean i should press the button very gentile ?
[12:04] <ogra_> whoops ...
[12:05] <ogra_> s/gentile/gentle/
[12:05]  * ogra_ has french day today 
[12:05] <ogra_> :P
[12:05] <davmor2> ogra_: haha
[12:10] <asac> brendand: can we have a bug for the crashes? see -touch
[12:10] <asac> unity8
[12:10] <davmor2> ogra_: I wonder if it is webapp containers that is making the phone unstable?  we both seemed to get lock ups on or around the g+ app right?
[12:11] <davmor2> brendand: ^
[12:11] <davmor2> just a guess, I'm trying to find some common ground
[12:11] <Mirv> satoris: it was to utopic, where you don't land anymore. I'll assign a vivid silo for i tnow.
[12:12] <sil2100> Anyway, it seems we're a bit low on manpower from the CI team today
[12:12] <brendand> asac, yeah will do
[12:12] <brendand> can i point to the ci crashes in a public bug?
[12:12] <sil2100> asac: if you could subscribe landing-team-trackers to then - awesome
[12:12] <satoris> Mirv: ok, thanks.
[12:12] <asac> brendand: sure; those are public anywya, no?
[12:13] <brendand> asac, for RTM on krillin?
[12:14] <asac> brendand: hmm. i think posting the link should be fine given that the link is protected?
[12:14] <asac> brendand: is this only on krillin?
[12:14] <asac> brendand: are the links for downloading protected?
[12:14] <brendand> asac, yes
[12:15] <asac> brendand: then its fine i guess...
[12:15] <brendand> asac, only on krillin? hmm, we have no evidence to the contrary since not many people are using mako
[12:36] <ogra_> sil2100, you said at the airport there was a silo for ricmm's fix for the ~70 UITK test failures ... i dont seem to see it anywhere (nor do i see a spreadsheet entry for it)
[12:36] <sil2100> ogra_: there's a branch for it prepared, but I didn't know anything about a silo - bzoltan_ just mentioned that they have it and are planning on releasing it with the next UITK (whatever that meant)
[12:37] <sil2100> bzoltan_: ^ any news on landing the AP test failure fixes?
[12:47] <Mirv> sil2100: not yet landed https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/bug-lp1382414/+merge/239290
[12:48] <Mirv> ETA is most probably this week, since it was discussed last week
[12:51] <sil2100> We would really need this in before the cut-off
[13:13] <fginther> sil2100, morning
[13:14] <fginther> sil2100, did you get a response on your dashboard query from a couple hours ago?
[13:19] <ogra_> fginther, i dont think we did
[13:29] <Mirv> bregma: ^ unity 14.04 SRU made it in, running merge&clean
[13:30]  * bregma does a happy dance
[13:32] <fginther> ogra_, sil2100, I've restarted the portion of the smoketesting that failed due to an unrecoverable device. Looking for other issues...
[13:33] <sil2100> fginther: no, didn't get any :)
[13:33] <sil2100> fginther: thanks! Do you know if plars will be around today as well?
[13:33] <fginther> sil2100, other then the lack of results, any other known issues?
[13:34] <sil2100> Oh!
[13:35] <sil2100> fginther: what about psivaa_? Do you know if he's also away?
[13:39] <barry> ribru, infinity i saw the eatmydata errors when i was updating my vivid chroots.  now i don't see them.  go bother someone else you gremlins
[13:41] <sil2100> hah
[13:41] <sil2100> ;)
[13:57] <brendand> ogra_, 125 is definitely much more stable
[13:57] <brendand> ogra_, anecdotally at least
[13:58] <brendand> ogra_, did you or sil2100 get to file that bug?
[14:02] <sil2100> brendand: not me, but 125 is the image before the hud removal
[14:02] <sil2100> http://people.canonical.com/~lzemczak/landing-team/ubuntu-rtm/126.commitlog
[14:03] <sil2100> So this should be the image that worsened things
[14:03] <brendand> bfiller, hey - you've got a lot of silos queued up :)
[14:03] <bfiller> brendand: indeed
[14:04] <bfiller> brendand: let me know if you have any questions about testing
[14:04] <brendand> bfiller, hopefully most of them should get looked at today - do you have any preference for the order they are done in?
[14:05] <sil2100> davmor2, brendand: so currently there are only 4 silos in the sign-off queue, right?
[14:06] <cwayne> jdstrand: we should figure out when to land apparmor-easyprof-ubuntu :)
[14:06] <bfiller> brendand: one sec, on standup
[14:08] <bfiller> brendand: silo 6 would be great to get in first
[14:11] <brendand> bfiller, both those bugs are approved?
[14:11] <bfiller> brendand: yes
[14:15] <tvoss> sil2100, ping
[14:15] <ogra_> tvoss, !
[14:15] <sil2100> ogra_: hey, did you get any info from -release regarding those chroots?
[14:15] <sil2100> tvoss: !
[14:15] <ogra_> tvoss, everything ok ?
[14:15] <sil2100> ogra_: the armhf ones during debootstrap for armhf
[14:15] <ogra_> sil2100, seems infinity isnt up yet
[14:15] <tvoss> ogra_, sil2100 mostly, everyone back home
[14:15] <ogra_> cool
[14:15] <sil2100> tvoss: \o/ really glad to hear that
[14:15] <ogra_> hop its wasnt anything bad
[14:16] <ogra_> *hope
[14:16] <ogra_> tvoss, so we tried to decypher ribru's mail but kind of failed
[14:16] <tvoss> ogra_, rota virus, kinda dangerous for little ones as they dehydrate fast and easily
[14:16] <ogra_> uh, yeah
[14:17] <tvoss> ogra_, the issue is that https://code.launchpad.net/~thomas-voss/location-service/fix-gps/+merge/239411 was meant to land, and I put that MP into the silo (see spreadsheet, although the line says "given up")
[14:17] <ogra_> tvoss, especially since the build failure he refers to seems to not be related to merging but seems to be some self test where the build does not find ofono on the dbus
[14:18] <tvoss> ogra_, nope, one of the tests times out, the ofono not there messages are perfectly fine and handled gracefully
[14:18] <ogra_> ah ,k
[14:18] <tvoss> ogra_, sil2100 the MP that landed is https://code.launchpad.net/~thomas-voss/location-service/fix-gps-integration-and-allow-for-decorating-provider-names
[14:18] <tvoss> ogra_, sil2100 at least in the binary packages. I think someone published a silo other than rtm 6
[14:19] <ogra_> tvoss, rtm 004
[14:19] <ogra_> that was long pending
[14:19] <ogra_> and landed yesterday
[14:19] <ogra_> (that was the one that missed the milestone due to QA failing a few times)
[14:23] <tvoss> ogra_, sil2100 so, at any rate, I would like that landing to be reverted and instead https://code.launchpad.net/~thomas-voss/location-service/fix-gps if possible at all
[14:24] <tvoss> ogra_, sil2100 but your call, I can just fix the test hang for AlbertA and we keep on movin
[14:24] <tvoss> g
[14:24] <ogra_> tvoss, but that means reverting a critical fix from milestone 1016
[14:24] <tvoss> ogra_, ack, so I will fix the test hang for AlbertA
[14:25] <AlbertA> tvoss: cool thanks!
[14:26] <ogra_> tvoss, well, it is your trunk :)
[14:27] <tvoss> ogra_, true, still unsure what happened as the respective branch wasn't merged automatically
[14:27] <ogra_> tvoss, hmm, it should have been when the silo landed indeed
[14:27] <ogra_> but thats a sil2100 question
[14:28] <sil2100> Trying to get my head around this as well
[14:28] <tvoss> ogra_, yeah, so something went wrong ... not sure what, though
[14:28]  * ogra_ has only seen cu2d from far far away
[14:28] <ogra_> sil2100, the silo had lxc-android--config in it too ... i wonder if the merging choked on that (unlikely though)
[14:29] <sil2100> ogra_, tvoss: the thing is... silo 004 had a sync request of location-service
[14:30] <ogra_> yes, plus lxc-android-config
[14:30] <sil2100> ogra_, tvoss: so there was no merge related to location-service in the landing, so no wonder nothing got merged
[14:30] <ogra_> oh
[14:30] <ogra_> right
[14:30] <sil2100> Not sure how this got into utopic though then
[14:30] <tvoss> sil2100, ah, interesting, but where did the binary packages come from?
[14:31] <ogra_> dput to the PPA ?
[14:31] <sil2100> tvoss: trying to figure that out, sadly it's all working on scraps of information
[14:31] <ogra_> lool, ^^^ do you knwo ?
[14:31] <sil2100> ogra_, tvoss: I would suppose it was a sync from utopic
[14:31] <ogra_> i doubt that
[14:31] <ogra_> since what landed in utopic was broken ...
[14:31] <ogra_> the issues were found on milestone day when the rtm silo was tested
[14:32] <sil2100> hm, I see 23 in vivid
[14:32] <ogra_> not before iirc
[14:32] <sil2100> So a sync from vivid that was maybe?
[14:32] <sil2100> hmmm
[14:33] <ogra_> so it landed in utopic ... then failde QA later in rtm ... and then was stuck for a week
[14:33] <sil2100> Actually that's really strange, since CI Train logs say:
[14:33] <sil2100> 2014-10-23 19:19:41,929 INFO Looking at location-service as per sync request
[14:33] <sil2100> 2014-10-23 19:19:44,505 INFO Grab code for location-service (2.1+14.10.20141023-0ubuntu1) from utopic to the 'build' directory
[14:33] <sil2100> So I think it got synced from some silo PPA :|
[14:33] <lool> sil2100, ogra_: lxc-android-config bzr is way out of sync; that's why everybody uploads changes, either to archive ot to PPA
[14:33] <lool> which is what I did here
[14:33] <ogra_> lool, thats fine
[14:33] <sil2100> lool: do you remember where you synced location-service from?
[14:33] <ogra_> lool, the location-service side is what broke
[14:33] <lool> sil2100: from an ubuntu PPA
[14:33] <ogra_> lxc-android-config isnt the issue
[14:33] <lool> I mean a regular anding PPA
[14:34] <lool> so it didn't land?
[14:34] <ogra_> well, i assue something happened to fix it between 10/16 and yesterday
[14:34] <sil2100> lool: seems it didn't
[14:34] <ogra_> where did that fix come from
[14:34] <sil2100> I mean, wait
[14:34] <lool> so
[14:34] <sil2100> I guess it's landed in both distros now anyway
[14:35] <lool> a) lxc-android-config package uploaded + location-service branch merged into ubuntu silo => this landed
[14:35] <ogra_> right, the question is if that is what we wanted :)
[14:35] <sil2100> So I suppose there only was the problem of the branch not being merged properly
[14:35] <lool> b) separate rtm lxc-android upload + copy of location-service into ubuntu-rtm PPA => this partially landed?
[14:35] <ogra_> lool, right ... on 10/16 the rtm equivalent failed QA
[14:35] <lool> it ended up passing QA
[14:35] <ogra_> i.e. your b) scenario
[14:35] <ogra_> lool, how ?
[14:35] <lool> it failed before the sprint
[14:36] <ogra_> there must have been a change inbetween
[14:36] <lool> wow, electricity went down here
[14:36] <ogra_> was that in a device or custom tarball ?
[14:36] <lool> but back up
[14:36]  * lool checks equipments brb
[14:37] <ogra_> dont lick your finger and touch power cables ! use a voltmeter instead !!
[14:37] <ogra_> :)
[14:37] <lool> ok, UPS took most of the hit, rest took it fine
[14:37] <ogra_> lool, so to make it pass QA something must have been fixed
[14:37] <lool> impressed by the microwave which has no battery but kept the time and the disher that just kept on going
[14:37] <ogra_> what/where was that
[14:38] <ogra_> device ? custom ? code change ?
[14:39] <lool> so the first time this failed, it was mostly me copying the lxc-android-config from ubutnu erroenously
[14:39] <lool> then I'm not sure whether we did a code update or not, I think not
[14:39] <lool> vruiz tested the version which landed last week
[14:39] <ogra_> you mean yesterday
[14:39] <lool> no, that was like thursday last week
[14:39] <lool> where's the archive of passed qa?
[14:39] <sil2100> lool: I think the trello board has that
[14:40] <ogra_> lool, http://people.canonical.com/~ogra/touch-image-stats/rtm/131.changes
[14:40] <ogra_> thats was yesterday
[14:40] <ogra_> not sure if it sat idle over the weekend though
[14:40] <lool> well the rtm build from yesterday shows the package being picked up
[14:40] <lool> I guess they only got published in rtm recently
[14:41] <ogra_> i remember you fixing lxc-android-config on 10/16 so QA could test
[14:41] <ogra_> but then it faild that test
[14:41] <lool> 27
[14:41] <lool> ogra_: yes, this is what I mention above
[14:41] <ogra_> then something must have happened that now makes QA pass
[14:41] <lool> but that's when we were trying to hit the 17th
[14:41] <lool> or 16th rather
[14:41] <ogra_> right
[14:42] <lool> and we had a fix on the 17th
[14:42] <lool> but that only started being QA-ed like wed last week
[14:42] <lool> on 22th
[14:42] <ogra_> and that landed in utopic
[14:42] <lool> QA passed 23
[14:42] <lool> no, I'm speaking of rtm
[14:42] <ogra_> well, utopic and rtm now have the same location-service
[14:43] <ogra_> so i assume you landed the fix in utopic on the 17th
[14:44] <lool> location-service landed on 23rd in utopic and yesterday in rtm
[14:44] <lool> sorry, I dont even know what problem we're trying to solve here
[14:44] <lool> ah no, it's *not* in utopic
[14:44] <lool> it's in vivid
[14:44] <ogra_> lool, just trying to do forensics to know the right thing landed where it should
[14:44] <lool> cause utopic was closing at the time
[14:45] <sil2100> Yeah
[14:45] <lool> i see the fixes in rtm and in vivid; do we need them in utopic?
[14:45] <ogra_> yeah, might sit in unapproved ... if at all
[14:45] <ogra_> lool, no, we just want to be sure the right thing is in rtm
[14:45] <lool> I dont think we even tried landing in utopic
[14:46] <lool> yeah, I think we're good on that one
[14:46] <lool> missing the startup fix now
[14:46] <ogra_> (and why the landing didnt get merged into trunk ... but i think we understood that already)
[14:46] <ogra_> (i.e. silo sync fro something that didnt land in utopic)
[14:48] <lool> right
[14:48] <ogra_> phew, so we're all fine
[14:49] <ogra_> lool, tvoss, btw, did you ever test location in a car ?
[14:49] <tvoss> ogra_, not me personally, but it's part of a larger test plan for the Here stuff
[14:49] <ogra_> works fine for about 5km :) then i have to restart the app to have it move along with me
[14:49] <ogra_> else the dot just gets stuck
[14:49] <ogra_> things seem to time out or so
[14:50] <lool> ogra_: I did in the past
[14:50] <lool> ogra_: actually what I've spotted last week is that whenever the screen turns off, updates stop; you have to start some location using app to have them resume
[14:50] <ogra_> i did it on a freshly bootstrapper install yesterday
[14:50] <lool> even walking
[14:50] <lool> ogra_: seems coherence with your experience
[14:50] <ogra_> i disabled screen blanking completely and had the phone on charger
[14:51] <ogra_> attached to the windshield
[14:51] <ogra_> it gets the fix within 1-2sec ... really nice ... just that it stops then
[14:51] <tvoss> ogra_, could you check that the gps provider was actually running?
[14:51] <tvoss> ogra_, I assume that you had a 3G data connection enabled?
[14:51] <ogra_> tvoss, hard to do while driving :)
[14:52] <ogra_> yep
[14:52] <ogra_> and the maps were properly updating when moving
[14:52] <ogra_> juust the dot wasnt anymore after some time
[14:53] <ogra_> (i could zoom and move the map with a finger and it downloaded fine, so the network was good)
[14:53] <ogra_> it looked like either trust-store timing out the permission or the provider itself timing out
[14:54] <tvoss> ogra_, the map was moving?
[14:54] <tvoss> ogra_, then you certainly had location updates
[14:54] <ogra_> i could move it
[14:54] <ogra_> it was moving while the dot moved
[14:54] <pmcgowan> I am curious, what is the real solution to keeping the screen on when navigating? Should we have a manual toggle?
[14:55] <ogra_> and when the dot stopped moving i could swipe it around and got map updates for the missing tiles
[14:55] <tvoss> ogra_, so if you could check prior to the drive that the location service command line actually has --provider gps::Provider, that would help me
[14:58] <ogra_> tvoss, http://paste.ubuntu.com/8720282/ ... that should be the respective logfile (as you will notice i switched to googlemaps at some point to see if it behaves any better)
[14:59] <ogra_> smells like the dbus backend vanishes somehow
[15:00] <tvoss> ogra_, hmmm, that's interesting. Did you reopen the page?
[15:00] <tvoss> ogra_, at any rate: mind filing a bug against location-service and trust-store?
[15:05] <barry> ogra_, sil2100 quick sanity check on s-i 2.5.1 for rtm.  upstream tarball is ready to go so i'm prepping a source package for ubuntu-rtm only.  i don't plan on sru'ing 2.5.1 into utopic and vivid will get s-i 3.0 when that's ready.  so i want to version number the rtm package properly.  i'm thinking 2.5.1-0ubuntu1~rtm1.  that will sort higher than the last utopic/rtm of 2.5-0ubuntu1, lower than any vivid 3.0 release, but also lower than
[15:05] <barry> any 2.5.1 we might (for unforeseen reasons) want to release into vivid.  does that sound right?  also, i'm leaving it UNRELEASED in the assumption that the citrain will fill that in correctly.
[15:05] <barry> ogra_, sil2100 once the source package is tested locally, i'll then create an rtm silo only and use a source package upload to the ppa instead of a merge proposal, right?
[15:09] <ogra_> tvoss, yes, as i said above, every time the dot stopped moving i needed to restart the app to have it move again ... it works for about 3-5km then sits there
[15:17] <lool> trainguards, could we land rtm silo 24 now?
[15:17] <brendand> thostr_, do you have any feedback on silos 19 and 7? they appear to have changes that didn't make the list. i asked pete-woods yesterday, he said he needed to check with you
[15:18] <ogra_> barry, hmm, why dont you just want to push to vivid and rtm in parallel ?
[15:20] <thostr_> brendand: i was out yesterday and he today... will try to clarify... should have it by tomorrow at latest
[15:20] <ogra_> pmcgowan, i dont think there is any solution yet ... as per definition an app cant request the screen to be on constantly
[15:21] <ogra_> (i had some discussion with tvoss about that before ... seems extending the timeout is possible at some point, but not permanent-on state)
[15:21] <ogra_> (in my case for ebook reader stuff though)
[15:22] <barry> ogra_: i probably could, although i only wanted to land 3.0 in vivid and it'll be a little more work on my end to reconfigure my branches to do that.  if it would make the train run more smoothly, i'd be willing to do that (or at least try to)
[15:22] <asac> sil2100: when do you think will we have first vivid image popping out?
[15:23] <ogra_> barry, well, it will make switching rtm to vivid easier (which will happen in a far far future ... ) so you would have at least the last working code in vivid even if you couldnt land 3.0 yet
[15:23] <ogra_> asac, once debootsrap is able to produce armhf chroots
[15:23] <ogra_> asac, i pinged adam this morning but he seems to be out (and colin is on vac ... )
[15:24] <ogra_> the build falls over when debootstrapping
[15:24] <sil2100> asac: so, still waiting for some answers to why armhf chroots fail with debootstrap
[15:24] <sil2100> ogra_: maybe slangasek can help out?
[15:24] <sil2100> ogra_: btw. we have a bug number for the issues already?
[15:24] <ogra_> sil2100, i think adam is around now
[15:24] <barry> ogra_: so, just to be clear.  you're saying, land 2.5.1 onto the ubuntu train, which will land in vivid, then sync it over to rtm, and everything will work properly, right?  iow, just use the "normal" pre-vivid process
[15:24]  * ogra_ goes to #ubuntu-release
[15:25] <sil2100> barry: so, you want to upload s-i as a source package upload, right? Since it's not released by merges in the train, right?
[15:25] <ogra_> barry, i think thats a sil2100 question but thats how i would imagine it ... kind of ...
[15:26] <barry> sil2100: that's what i'm trying to figure out ;).  if i were to land it in vivid, then sync to rtm, i'd do a merge proposal like usual
[15:27] <sil2100> barry: oh, so normally you release it with merges in the train?
[15:27] <sil2100> Since the version number seems different than what the train uses - you have a flag that disables the version rewrite there?
[15:27] <barry> sil2100: yep
[15:28] <barry> X-Auto-Uploader: no-rewrite-version
[15:28] <barry>  
[15:29] <jdstrand> cwayne: yes-- it is actually apparmor, click-apparmor and apparmor-easyprof-ubuntu. an additional fix was identified as needed over the weekend for the apparmor change to make any effect
[15:30] <sil2100> Ok, excellent
[15:30] <jdstrand> cwayne: so that is built in the silo and I just have to test. however, there is another bug about the date on the device being set to 2014-01-01 that you and I need to discuss, but I am heading into a meeting atm
[15:30] <jdstrand> cwayne: let's talk in a little bit
[15:30] <barry> sil2100, ogra_ okay, i'll try to board the train with the usual ticket and ping you if i have problems
[15:30] <sil2100> barry: so, let me think about that, since it's not as easy-peasy as it is in other cases
[15:31] <barry> sil2100: okay.  ping me.  in the meantime, i'll continue to test things locally
[15:31] <sil2100> barry: anyway I would try to do it like this - try to land it for vivid for now (i.e. 2.5.1) and let's then try syncing that up to ubuntu-rtm
[15:32] <barry> sil2100: ok
[15:32] <sil2100> We might do a source sync for that, but I'm afraid that CI Train would wrongly interpret the version
[15:32] <barry> thx
[15:32] <sil2100> But I'll think of something ;)
[15:32] <barry> :)
[15:32] <sil2100> barry: since when doing a CI Train source sync, it will probably try changing the version to: 2.5.1~rtm-0ubuntu1
[15:32] <sil2100> barry: not sure if that's acceptable?
[15:33] <barry> sil2100: i don't care too much as long as it lands in rtm, but i don't think it's ever done that before and i've definitely done syncs from utopic->rtm
[15:33] <sil2100> barry: yeah, but when you were doing utopic->rtm syncs those were usually binary syncs
[15:34] <barry> sil2100: that is true
[15:34] <sil2100> barry: it *should* work as a binary sync right now too I guess, but more risky
[15:34] <sil2100> (since we no longer can be sure of that as in the past)
[15:34] <sil2100> Well, anyway, for now vivid, then we care about rtm ;)
[15:35] <barry> sil2100: ok.  and i still have a bit of local testing to do first before i'm ready for a silo, so if something hits you let me know.  rtm is of course the one we really care about :)
[15:35] <barry> right now
[15:40] <Mirv> lool: done. there was some sort of dashboard issue, but all seems fine when I checked manually.
[15:41] <brendand> Mirv, are you going to be testing silo 22?
[15:41] <Mirv> brendand: it's WIP still, lorn keeps on churning upstream fixes
[15:42] <Mirv> brendand: for testing, I'll probably refer to mr. zanetti and others who have reproduced the problem (although I nowadays think I know how I see that too)
[15:44] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141028-3ca60be.changes
[15:44] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141028-3ca60be.ods
[15:44] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141028-3ca60be.tar.xz
[15:45] <john-mcaleely> sil2100, ogra_ davmor2 brendand ^ new device tarball
[15:45]  * ogra_ checks what you broke again 
[15:45] <john-mcaleely> can I request a qa pass at your earliest convenience
[15:45] <john-mcaleely> :-_
[15:45] <john-mcaleely> :-) eve
[15:45] <john-mcaleely> n
[15:45] <davmor2> john-mcaleely: lalalalala not listening lalalalalala
[15:45] <ogra_> wheee dropping log noooooise \o/
[15:45] <john-mcaleely> davmor2, tsk
[15:46] <ogra_> get that in !!!
[15:46] <john-mcaleely> so it's fixes for alarms not always working, and cleanup performed during power management investigation
[15:46] <john-mcaleely> which we should get in so future investigations (!) have an easier life
[15:46] <john-mcaleely> both bugs are 'on the list', I believe
[15:47] <davmor2> john-mcaleely: I'll have a look after I finish this silo I'm testing
[15:47] <john-mcaleely> davmor2, yay. sounds good
[15:47] <john-mcaleely> davmor2, notably absent are the new modem binaries I mentioned last week. They've caused regressions, and are being re-worked
[15:49] <sil2100> davmor2, john-mcaleely: if Dave has time for it, then go for it
[15:50]  * ogra_ just wants the logging noise gone 
[15:50] <ogra_> screw the modems, land it already :)
[15:50] <john-mcaleely> ha. never have so many been pleased by printf changes
[15:50] <ogra_> heh
[15:58] <sil2100> fginther: can you check what's up with #133 krilling test results that it's not moving forward?
[15:59] <ogra_> i thought he did above
[16:00] <fginther> sil2100, sure, it failed again (for a different reason) and I restarted it again. but I do suspect some other results to be there
[16:01] <ogra_> well, reminders is known to be wonky due to using OAuth 1.0
[16:01] <ogra_> you likely want to skip that
[16:01] <ogra_> click_image_tests are also known to fail (but cwayne and mvo_ should be working on that )
[16:02] <ogra_> though the latter should make anything stuck
[16:02] <mvo_> ogra_: *cough* right - what was the url again?
[16:02] <sil2100> fginther: what was the reason for the failure this time?
[16:02] <fginther> wasn't reminders fixed to not hang the tests?
[16:02] <ogra_> mvo_, so i looked a bit deeper ... krillin doesnt use the click_list anymore for the test
[16:03] <fginther> sil2100, unity8-autopilot could not be installed: 'Err http://derived.archive.canonical.com/ubuntu-rtm/ 14.09/main python3-junitxml all 0.6-1.1build1
[16:03] <fginther>   Could not resolve 'derived.archive.canonical.com'"
[16:03] <ogra_> mvo_, seems the test calls "click list" on the device and compares it to http://people.canonical.com/~ubuntu-archive/click_packages/click_list ... which used to be our master list ... but due to the fact that we now have a custom tarball on krillin that removes clicks there and adds its own they wont match anymore
[16:03] <fginther> it couldn't hit "derived.archive.canonical.com" at all
[16:04] <ogra_> mvo_, so i think cwayne needs to provide you a different "krillin_click_list" to match against and the test needs to use that
[16:04] <mvo_> ogra_: oh, I see. what is the url again for hte test failure?
[16:04] <ogra_> mvo_, http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/132:20141027.1:20141015-32e0f27/634/click_image_tests/220717/ is the url of the last test
[16:04] <mvo_> ogra_: thanks
[16:05] <cwayne> mvo_: ogra_: i'm happy to get you a list
[16:14] <tvoss> fginther, around?
[16:15] <bdmurray> sil2100: what needs to happen next with bug https://bugs.launchpad.net/ubuntu-rtm/+source/whoopsie/+bug/1339916? I see it was approved in the spreadsheet.
[16:16] <lool> Mirv: thanks
[16:16] <fginther> tvoss, yes
[16:17] <ogra_> bdmurray, add a line to the spreadsheet for it to request an rtm silo
[16:17] <ogra_> oh, sorry
[16:17]  * ogra_ should read sentences to the end :P 
[16:17] <ogra_> oh, other spreadsheet
[16:17] <ogra_> bdmurray, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&pli=1#gid=0
[16:17] <ogra_> you want an rtm landing entry there
[16:18] <ogra_> bdmurray, once you got a silo assigned, you dput the change to the silo PPA and test it ... the rest is handled by QA and the landing team then
[16:19] <ogra_> bdmurray, note that the version needs to be on top of the last rtm package though ...
[16:19]  * ogra_ looks that up 
[16:19] <ogra_> bdmurray, https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000775.html ... you want rtm5 most likely
[16:20] <sil2100> bdmurray: yeah, so if it's approved, we need to get it to RTM through the train - is this change landed in vivid/utopic already?
[16:20] <sil2100> bdmurray: I mean, where is it landed, to vivid or to utopic?
[16:20] <ogra_> sil2100, utopic
[16:20] <bdmurray> sil2100: utopic and vivid (presumably)
[16:21] <sil2100> bdmurray: ok, then we can do a binary sync then
[16:21] <ogra_> sil2100, and then there was an lxc change on top of it which blocked us from syncing it over
[16:21] <sil2100> bdmurray: just fill in an landing entry for it an I'll fill in all the details to do a sync
[16:21] <bdmurray> sil2100: it also requires a change to lxc-android-config
[16:21] <sil2100> Ah
[16:21] <ogra_> sil2100, new lxc version and according changes ... we cant use utopic at all as base for rtm for this package anymore
[16:21] <ogra_> neither vivid i guess
[16:22] <ogra_> since that has the same packag
[16:22] <ogra_> e
[16:22] <ogra_> (and a dep on a newer lxc version)
[16:22] <sil2100> ogra_: then a sync of whoopsie and then upload a custom lxc-android-config
[16:23] <ogra_> right
[16:23] <ogra_> based on https://launchpad.net/ubuntu-rtm/14.09/+source/lxc-android-config/0.208rtm4
[16:26] <brendand> sil2100, did the spreadsheet get messed up?
[16:26] <sil2100> brendand: what's wrong?
[16:27] <brendand> sil2100, ubuntu-rtm/landing-004 says line 65 in its description
[16:27] <brendand> sil2100, but line 65 is definitely not that
[16:28] <davmor2> Saviq: I've just had the phone reboot/unity8/mir/lightdm/crash it's one of them anyway on the ubuntu spinning logo I'll check the crash files after, but it was on receiving the osd for google syncing contacts
[16:28] <ogra_> looks like 66 though
[16:28] <ogra_> off by one
[16:28] <ogra_> davmor2, reboot ?
[16:28] <ogra_> thats definitely a kernel or driver issue then
[16:29]  * ogra_ has never seen that 
[16:29] <bdmurray> sil2100: I seem to only have view access so can't add a new landing entry
[16:29] <davmor2> ogra_: ubuntu spinning logo, I'm assuming reboot is the wrong term and I know how Saviq likes specifics so I covered them all :)
[16:30] <ogra_> phew ...
[16:30] <sil2100> bdmurray: oh no!
[16:30] <sil2100> Let me fix that :)
[16:30] <ogra_> davmor2, so the known issue then
[16:31] <davmor2> ogra_: yes but a fresh log/crash file for Saviq to poke hopefully :)
[16:31] <kenvandine> anyone know why 4 of the 7 powerppc builders have a status of "Manual"?
[16:31] <ogra_> i think asac collected one and me too
[16:31] <ogra_> kenvandine, probably a question for #ubuntu-release
[16:31] <kenvandine> causing long wait times for the vivid silo builds :/
[16:31] <ogra_> but likely simply because they arent ready yet
[16:32]  * ogra_ thinks we were a bit fast with opening this time round ... to have all bits in place in time
[16:32] <kenvandine> perhaps
[16:33] <kenvandine> but it would be nice if all 7 were building :)
[16:33] <ogra_> (especiallly since soome arches will need some time to process all initial package builds)
[16:34] <sil2100> bdmurray: done
[16:34] <asac> sil2100: when do you think can we do v landings?
[16:34] <asac> slangasek: ^^
[16:34] <sil2100> asac: we're doing v landings already
[16:34] <asac> sil2100: when do we do first image you think?
[16:35] <bdmurray> sil2100: okay, I've added a landing entry
[16:35] <sil2100> asac: it's just that we don't have an image yet, not sure when that will be resolved though...
[16:37] <ogra_> asac, we already do them ?
[16:37] <sil2100> ogra_: I think I missed in the backlog, but do we have a bug for the chroot issue?
[16:39] <ogra_> sil2100, i dont think so, but infinity is digging, i assume it will be fixed soon
[16:40] <ogra_> obviously it isnt reproducable locally so i guess he needs to dig into the builders themselves
[17:05] <ribru> barry: are you saying you got eatmydata working without any configuration changes in vivid? wtf?
[17:06] <barry> ribru: no, only that it hasn't shown up again yet.  but the day is young
[17:07] <ribru> barry: oh ok. because I found some wiki documentation for pbuilder that suggested some changes to make eatmydata work in vivid, but they didn't seem to work for me, I tried several variations.... after a while I just gave up and disabled it in vivid.
[17:11] <brendand> ogra_, did we try just rolling back the hud removal yet?
[17:11] <ogra_> brendand, did you confirm it is actually the hud ?
[17:11] <brendand> ogra_, no i still have no idea
[17:11] <ogra_> (i will have to rip it out again, even if i roll back, so i want to be 100% sure)
[17:13] <brendand> ogra_, well i mean did we try just installing the old version of the package - we don't actually have to revert it yet
[17:13] <ogra_> how do you mean "old version" ?
[17:13] <ogra_> it was ripped out completely
[17:13] <ogra_> just apt-get install hud
[17:13] <ogra_> that will revert the change easily ;)
[17:20] <davmor2> john-mcaleely: can you make the tarball so I can access it please it makes it so much easier to flash then ;)
[17:20] <john-mcaleely> davmor2, oh
[17:20] <davmor2> john-mcaleely: You don't have permission to access /~jhm/barajas/device_krillin-20141028-3ca60be.tar.xz on this server.
[17:21] <john-mcaleely> davmor2, please retry
[17:21] <john-mcaleely> davmor2, sorry!
[17:21] <davmor2> john-mcaleely: yay ta
[17:31] <sil2100> fginther: o/
[17:34] <sil2100> davmor2: you SLACKER!
[17:35] <davmor2> sil2100: sorry I thought it was off in the afternoon, you could of pinged :P
[17:35]  * ogra_ didnt get a calendar notification either 
[17:35] <davmor2> sil2100: I was too busy testing silos :P
[17:35] <ogra_> and ibn fact my phone calendar doesnt have the evening meeting at all anymore
[17:36]  * ogra_ forces a calendar sync
[17:37] <davmor2> sil2100: install sadtrombone app and you can play it :P
[17:37] <sil2100> I got an e-mail reminder
[17:37] <sil2100> ;p
[17:38] <davmor2> sil2100: I didn't
[17:38] <ogra_> yeah, it is obviously in my gcal
[17:38] <sil2100> davmor2: you testing the device tarball now?
[17:38] <ogra_> but not on my phone
[17:38] <davmor2> sil2100: yeap just moved onto it now I finished the silo I was on
[17:38] <ogra_> davmor2, what happened to failsauce ? i thought *that* was the recommended app for the task
[17:38]  * john-mcaleely excitedly awaiting results
[17:39] <john-mcaleely> well, awaiting, anyway
[17:39] <john-mcaleely> :-)
[17:39] <davmor2> ogra_: it probably is but popey said to make it so I did :)
[17:39] <popey> it works
[17:40] <davmor2> popey: and passed all the tests
[17:40] <ogra_> heh
[17:43] <sil2100> fginther: one quick question though - do you know if the http://ci.ubuntu.com/smokeng/utopic/touch/ dashboard is configured to fetch images from devel-proposed or utopic-proposed?
[17:45] <ogra_> sil2100, check the console log of one of the tests
[17:45] <ogra_> the u-d-f command should be in there
[17:45] <ogra_> (with channel name and all)
[17:46] <ogra_> + adb reboot bootloader
[17:46] <ogra_> + ubuntu-device-flash --password ubuntuci --bootstrap --developer-mode --channel ubuntu-touch/devel-proposed
[17:46] <ogra_> sil2100, ^^^^
[17:47] <sil2100> Found it as well, thanks!
[17:48] <ogra_> yay, and a calendar sync got me the meeting back
[17:48] <ogra_> so i wont miss the harps tomorrow
[17:58] <sil2100> Harps for the win!
[17:59] <ogra_> ++
[17:59]  * ogra_ finally finds a minute to subscribe to vivid-changes
[17:59] <ogra_> wow ... and i already missed a ton of packages
[18:01] <fginther> sil2100, it uses devel-proposed
[18:11] <asac> hmm. i kinda still feel i dont get a notification for system updates
[18:12] <asac> didnt see 133 krillin rtm by notification, but just through trying in system settingts
[18:12] <asac> Chipaca: ^
[18:18] <ogra_> asac, are you sure your networking was up and working ?
[18:19]  * ogra_ always missed them when he also had wlan issues 
[18:19] <ogra_> i did a --bootstrap today though ... we'll see how that goes
[18:34] <asac> ogra_: yeah pretty, but well :)
[18:35] <asac> next time i will monitor for new images and keep looking at state
[18:35] <asac> monitor here
[18:35] <ogra_> you can be sure to get an image every morning when getting up usually
[18:35] <asac> ogra_: so i cant rule out that temporarily the network was down, but i would anticipate that it picks it up first time it can talk tot he server again
[18:35] <asac> ok lets see what the next morning brings :)
[18:35] <ogra_> if davmor2 manages to test the device tarball successfully you might even see one tonight
[18:36] <asac> ok good news i guess :)
[18:37] <ogra_> finally dropping all the log spamming from the kernel
[18:37] <ogra_> silly hardcoded printfs in android kernels ...
[18:37]  * asac hopes this will give another boost in usability :P
[18:38] <ogra_> heh
[18:39]  * asac will do a out-of-wifi-walk-through-town scenario tomorrow morning - scheduled :P
[18:40] <asac> really hope the image is up to that so i can find more interesting bugs than "damn, this needs restarting" :)
[18:45] <plars> sil2100: hi, sorry I was unresponsive to your email earlier, at a conference this week but I think fginther talked to you already about reminders still appearing to cause problems?
[18:45] <ogra_> asac, use location ;)
[18:45] <plars> sil2100: what's the status of the new autopilot with internal test timeout landing? iirc there needs to be a phablet-test-run change for that as well
[18:45] <ogra_> plars, system-settings is also worrying ... startsd to fail out of the blue in 128
[18:46] <john-mcaleely> there are multiple anecdotal reports of upgrade notifications 'not working'
[18:46] <ogra_> (and constantly since)
[18:46] <asac> ogra_: why?
[18:46] <plars> ogra_: has anyone tried to reproduce yet?
[18:46] <ogra_> plars, nope
[18:46] <ogra_> asac, if i knew that i would have fixed it :P
[18:46] <sil2100> plars: I think that's still not there yet
[18:47] <sil2100> plars: but from what I saw, it's not only reminders causing trouble
[18:47] <plars> ogra_: nothing has changed for us since 10/21, and that was just where the default wifi config is pointing at
[18:47] <plars> nothing test related
[18:47] <ogra_> asac, the only thing in 128 was the apt rollback which cnat really affect system-settings
[18:47] <sil2100> plars: sometimes I saw the dashboard being stuck on some other test suite, like weather or system-settings
[18:47] <asac> ogra_: shall i try downgrading something?
[18:47] <plars> sil2100: yeah, ogra_ mentioned system-settings
[18:47] <asac> unfortunately i cant even reproruce, so i could only state a gut feeling that its "maybe more stable"
[18:48] <asac> ogra_: my backtrace from earlier today had media-hub in it
[18:48] <asac> that thing landed in 126 i was told
[18:48] <ogra_> asac, i'm not even sure it is a failing tests ... looking at the console log i see system-settings running something
[18:48] <ogra_> but the dashboard disagrees
[18:48] <asac> i am talkinga bout my crash locally
[18:48] <asac> that thing had media-hub in it
[18:48] <asac> https://errors.ubuntu.com/oops/47162672-5e98-11e4-a34f-fa163e22e467
[18:48] <asac> but was a bit bogus
[18:48] <ogra_> asac, kgunn is looking into that bug
[18:49] <asac> so if we also see something related to media-bug/audio etc. in the automation
[18:49] <ogra_> asac, bug 1386803
[18:49] <asac> i am sure its the same
[18:49] <asac> yeah
[18:49] <asac> righgt
[18:49] <ogra_> we were focused on hud initially
[18:49] <ogra_> but seems thats not it
[18:49] <ogra_> so now the other bits get inspected
[18:50] <asac> ok
[18:50] <asac> let me know what ended up causing the issue
[18:50] <asac> just wanted to point out that if automation has something related to audio/media-hub in trace
[18:50] <asac> its probably the same i saw locally here
[18:50] <asac> same with different paint
[18:50] <asac> heh
[18:51] <ogra_> well, for me its always scoperunner that crashes alongside
[18:51] <ogra_> judging by the timestamps in /var/crash
[19:10] <davmor2> john-mcaleely: so the tarball looks good, I've been tailing log files as I test it and they have been fairly quite appart from some of the apps but I'm assuming that is the app rather than random data as it shuts up again after I close it :)
[19:10] <davmor2> ogra_: ^ that should make you happy
[19:10] <ogra_> \o/
[19:11] <ogra_> :)))))))
[19:11] <ogra_> :D
[19:11] <ogra_> davmor2, syslog is the only interesting one for these changes anyway
[19:11] <ogra_> kernel all goes there
[19:13] <davmor2> ogra_: yeah I tail syslog still am infact :)  and other that apps that trigger hardware like the camera and tagger and here maps app/location it was mostly quite odd lines thrown in but nothing major
[19:13] <ogra_> awesome
[19:13] <ogra_> thats what i like
[19:14]  * ogra_ remembers having to do all these printf fixes for the nexus7 kernel back when we did desktop images for them ... it was pure horror
[19:15] <davmor2> ogra_: hahaha
[19:37] <john-mcaleely> davmor2, sounds good :-)
[19:38] <john-mcaleely> ogra_, so, when's a good time to publish it?
[19:38] <john-mcaleely> sil2100, ^
[19:38] <ogra_> any time is fine
[19:38] <john-mcaleely> I'll do it now then
[19:38] <ogra_> 3am UTC wouldnnt be so fine
[19:38] <ogra_> in case you planned to wait til tzhen :P
[19:38] <bfiller> ribru: could you publish silo 11 on rtm please?
[19:39] <john-mcaleely> ha. is that when the daily starts, or when the custom tarball lands?
[19:39] <davmor2> ogra_: john-mcaleely is not you he goes to sleep ;)
[19:39] <ogra_> daily
[19:39] <ogra_> well, that might be true for this week actually :)
[19:39] <john-mcaleely> aha :-)
[19:40] <ribru> bfiller: dnoe
[19:40] <ribru> done
[19:40] <john-mcaleely> ogra_, davmor2 sil2100 new tarball published
[19:40] <john-mcaleely> thank you!
[19:40] <bfiller> ribru: thanks
[19:40] <ogra_> yay, thanks
[19:40] <ribru> bfiller: you're welcome
[19:40] <davmor2> john-mcaleely: awesome
[19:42] <pmcgowan> hi guys was there an issue with the 130 image not starting properly?
[19:58] <ribru> bfiller: rtm 6 and 14
[19:59] <bfiller> thanks ribru
[19:59] <ribru> bfiller: you're welcome
[20:14] <ogra_> asac, i just got the notification here fyi
[20:14]  * ogra_ OTAs to silent logs 
[20:16] <ogra_> et voila ...
[20:16] <ogra_> session crashed directly after SIM PIN -> PIN
[20:33] <jdstrand> fyi, rtm silo 003 but 'QA signoff needed' is marked as 'yes'. it was formerly 'no', but someone changed it I think. I was going to land it tonight (the changes are really small-- adds an apparmor rule, adds an extra option to apparmor_parser invocations in the boot script and click-apparmor, and adjusts the parser to not unconditionally regenerate the cache when providing that option)
[20:33] <ogra_> jdstrand, convince olli_ ...
[20:33] <jdstrand> davmor2: you said you'd test the custom tarball tomorrow, but you can't do that until the above ^
[20:34] <ogra_> technically every landing in rtm needs QA signoff atm
[20:34] <jdstrand> I don't really care if someone does it, there was just coordination happening
[20:36] <jdstrand> I've got to step away for a while; I'll be back later
[20:38] <ribru> ugh, dashboard is missing lots of spreadsheet data but the spreadsheet seems fine, not sure why it's not picking that up. great
[20:43] <jdstrand> ok, updated the comments in the spreadsheets to reference all the changes
[20:43] <jdstrand> spreadsheet*
[20:59] <asac> ogra_: ack notification retrieved and processed
[20:59] <ogra_> asac, 50% of the vivid image failures are fixed ... thanks to adam ... i'll do the other half tomorrow
[21:00] <asac> ogra_: debootstrap probs?
[21:00] <asac> is there a tracking bug?
[21:00]  * asac thinks not
[21:00] <ogra_> yeah, these are fixed
[21:00] <ogra_> nope
[21:01] <ogra_> they were builder related
[21:01] <asac> ogra_: what other failures do we have now?
[21:01] <asac> ah, image building?
[21:01] <ogra_> yes
[21:01] <asac> or ppas etc.?
[21:01] <asac> ogra_: just touch or all images?
[21:01] <asac> uknow?
[21:01] <ogra_> next bit is to find a way to make livecd-rootfs find that it is on rtm and switch some configs back and forth
[21:01] <ogra_> just touch armhf
[21:01] <ogra_> well, all armhf actually
[21:01]  * asac impatient while unity spinner is spinning on first boot after upgrade
[21:02] <ogra_> well, it crashed immediately for me
[21:02] <ogra_> after sim pin and pin entering
[21:02] <asac> hmm. did i enter the pin?
[21:03] <ogra_> asac, since we use a hardcodded /etc/passwd in touch newly added users break the build ... i need to find a way to conditionally add all the new systemd users when building o vivid
[21:03] <asac> i think the fact that i cant remember that i entered the pin means that i didnt get that far
[21:03] <asac> but *shrug&
[21:03] <asac> -rw-r-----  1 phablet  whoopsie    11295 Oct 28 22:00 _usr_lib_arm-linux-gnueabihf_ubuntu-app-launch_desktop-hook.32011.crash
[21:03] <ogra_> asac, thats "normal"
[21:03] <ogra_> non issue
[21:03] <ogra_> (recoverable error about a duplicated icon entry)
[21:04] <asac> we won't try to fix that?
[21:05] <asac> ok phone is running
[21:05] <asac> i dont see a unity crash in /var/crash though
[21:05] <asac> it just took ages and came up
[21:05] <ogra_> lucky you
[21:05] <asac> guess because of the crash file getting dumped above?
[21:05] <ogra_> yeah
[21:05] <asac> ogra_: you say it will happen if i reboot?
[21:05] <ogra_> apport running
[21:05] <ogra_> asac, for me it happens always on first boto after OTA
[21:05] <ogra_> *boot
[21:06] <asac> maybe it crashes without a .crash?
[21:06] <ogra_> nah
[21:06] <asac> i swear it took very very long to boot
[21:06] <ogra_> i have plenty of crash files
[21:06] <asac> ok
[21:06]  * asac reboots phone and sees what happens in /var/crash
[21:09] <asac> who is working on the app scope still being empty?
[21:09]  * ogra_ forgot who, but someone is 
[21:09] <ogra_> thostr_ perhaps ... iirc he was in the dicussion this morning
[21:11] <pmcgowan> asac, it was marcus I believe
[21:11] <ogra_> oh, right
[21:12] <asac> ok pinged the bug
[21:12] <asac> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1382039
[21:13] <asac> seems the bug suggests its all on tedg :)
[21:13] <ogra_> luckily the workaround is just a down-swipe away :)
[21:13] <asac> lets see what folks say
[21:13] <ogra_> you want votes ?
[21:13]  * tedg perks up
[21:13] <asac> doesnt give me much sleep that there is a workaround :)
[21:13] <asac> ogra_: votes for what?
[21:13] <asac> that this needs fixing? :P
 lets see what folks say
[21:13] <asac> yeah, what they say who needs to do what to get this fixed
[21:14] <ogra_> i thought if tedg needs to fix it :)
[21:14] <asac> hehe
[21:14] <tedg> Oh, it's fixed in silo, we just need Saviq to land it :-)
[21:14] <asac> thanks. keep the bug posted on such great progress :P
[21:14] <ogra_> damn ... i was hoping i could get some bribes out of that :)
[21:14] <asac> heh
[21:14]  * ogra_ likes that voting idea
[21:15] <asac> guess depends on how many votes you have
[21:15] <asac> think we could give folks for flawless landings some virtual cash
[21:15] <ogra_> i vote for not moving to systemd ... just causes my first headdache in vivid
[21:15] <asac> they could use that to vote for bugs and folks :)
[21:17] <sil2100> ogra_: \o/ good to hear about the debootstrap
[21:18] <ogra_> sil2100, well, livecd-rootfs hacks ahead
[21:18] <ogra_> its not done
[21:20] <ogra_> damn
[21:22] <ogra_> this gets really tricky ... stgrabers hardcoding of passwd|greoup|shadow in the images assumes that you have an md5sum of the original file ... which you only have after one successful build
[21:24] <slangasek> E: config/hooks/99zz-check-uid-gid.chroot failed (exit non-zero).
[21:24] <slangasek> SUCCESS!
[21:24] <ogra_> lol
[21:24] <ogra_> yeah, it likes to be ironic :)
[21:24] <slangasek> well I'm very glad the hook did its job ;)
[21:25] <ogra_> well, i guess i could just take an utopic passwd, add the lines, generate an md5  and hope for the best ...
[21:25] <ogra_> which will then fail on /etc/group
[21:25] <ogra_> smells time consuming
[21:26] <ogra_> hmm, and we would also want it conditional ... only on vivid
[21:26] <slangasek> but a local build will give you the full environment that triggered the failure, you can then extract both /etc/passwd and /etc/group from it
[21:27]  * ogra_ doesnt really feel like maintaining livecd-rootfs-rtm instead 
[21:27] <slangasek> only on vivid> don't we always use the version of livecd-rootfs corresponding to the target release?
[21:27] <ogra_> yes
[21:27] <ogra_> but we have only one trunk
[21:27] <slangasek> ok, so
[21:27] <ogra_> of which we roll the packages
[21:27] <slangasek> you're going to have to get used to that
[21:27] <ogra_> and i dont want to maintain an rtm livecd-rootfs
[21:27] <slangasek> because releases from trunk to 14.09 are not going to happen
[21:28] <ogra_> hmm, k
[21:28] <slangasek> however, as olli_ and I were just discussing, we do expect to be able to use a single source trunk for both vivid development and a "14.10-devel" branch
[21:28] <ogra_> we tried to keep it in sync in utopic vs rtm
[21:28] <slangasek> so in that case, yeah, it needs to be clever
[21:29] <ogra_> that mens it needs multiple md5's
[21:29] <ogra_> that will become fun over time :)
[21:30] <slangasek> unfortunately, yes
[21:30] <slangasek> in practice though I think you only ever need two sets at a time
[21:30]  * ogra_ adds sqlite to the brannch to be future proof :P 
[21:30] <slangasek> one for current devel, one for previous stable
[21:30] <ogra_> yeah, thats true
[21:31] <ogra_> luckily we roll ... that means no point releases for old images
[21:31] <slangasek> exactly
[21:31] <ogra_> so i dont need to look to far back at least
[21:46] <ogra_> sil2100, you should perhaps enable the ML on https://launchpad.net/~landing-team-trackers
[21:46] <ogra_> saves you from long CC lists for such mails ;)
[21:46] <fginther> has anyone tried 134 yet on a krillin? the smoke test jobs all failed "phablet-network"
[21:47] <sil2100> ogra_: another ML you say? ;)
[21:47] <ogra_> fginther, runs happily here after a first boto crash of the session
[21:47] <ogra_> sil2100, well, only for announcements ... not for conversation
[21:47] <popey> fginther: I'm on 134 here
[21:47] <fginther> ogra_, popey, thanks
[21:47] <popey> network works fine
[21:47] <ogra_> fginther, if the crash happens apport kicks in ...
[21:48] <fginther> I'll kick them again one at a time
[21:48] <ogra_> fginther, that might cause everything to behave really slow for a bit ...
[21:48] <fginther> ogra_, that makes sense
[22:13] <sil2100> ogra_: so, I wanted to G+ my landing e-mail, but it didn't appear in the archive yet
[22:13] <sil2100> Been waiting for like ages
[22:14] <sil2100> Will G+ it later
[22:14] <sil2100> o/
[22:15] <ogra_> hmm
[22:15]  * ogra_ noticed odd behavior of the ML archive before ... 
[22:57] <kgunn> trainguards: does anyone understand the comment on line 22 wrt u-s-c in ubuntu-rtm/landing-001 ?
[22:58] <kgunn> e.g. i believe it's still needed
[22:59] <ribru> kgunn: sorry otp. my guess would be that there's a new sync that will take care of that sync as well. although 'line 67' seems like a stale reference, as line numbers can jump around.
[23:16] <ribru> kgunn: altough I don't see any other landings that reference u-s-c, so unfortunatley no, i don't know what that comment is supposed to mean, or who wrote it
[23:17] <kgunn> hmm
[23:24] <ribru> kgunn: if you're confident it's still needed and there's an approved bug for it, I guess just delete that comment, sounds like a mistake.