[00:00] <ogra_> sine which file to select is a completely image specific thing
[00:00] <slangasek> well, it's a hardware thing
[00:00] <ogra_> neither arch nor seed matter for this
[00:01] <ogra_> right, thats what i mean
[00:01] <slangasek> which in the future might mean we need runtime detection of the correct stack for a generic image
[00:01] <ogra_> yup
[00:01] <slangasek> so even livecd-rootfs is only an approximation, but it's certainly better than the mess we have now
[00:01] <cjwatson> Agreed
[00:01] <ogra_> (at the cost of shipping bloat)
[00:01] <cjwatson> Convergence => bloat ;-)
[00:01] <slangasek> ogra_: do you want to push the fix into livecd-rootfs?  (after the current bodged image finishes building, at least)
[00:01] <ogra_> heh
[00:01] <cjwatson> I mean, if that's how you define bloat, the implication is accurate
[00:02] <ogra_> not tonight anymore ... i just dropped by because i saw the mails on the ML (on my ubuntu phone btw, yay) ...
[00:02] <xnox> slangasek: i think, we need a package witch force configures the alternate to one or the other, and conflicts/removes the other-one. Kind of like qt4-default & qt5-default
[00:02] <xnox> (as much as i hate the qt*-default packages)
[00:02] <ogra_> slangasek, but if it can wait til EU business day i'm happy to take that
[00:03] <cjwatson> xnox: hm, that might work but I'd be worried about it entrenching the problem for upgrades and the like
[00:03] <ogra_> xnox, sneaking around the debian policy ?
[00:03] <slangasek> ogra_: I think it can wait, everyone's EOD by the time this image gets built
[00:03] <cjwatson> and hitting alternatives with a hammer always makes me scared
[00:03] <xnox> or in the postinst of the both stacks we can do use ubuntu-drivers magic to inspect modaliases and not configure the wrong package on a given hardware.... but that would work in apt world, but not in the system-image mode.
[00:03] <ogra_> slangasek, ok, then i'll take care tomorrow
[00:03] <slangasek> ogra_: great, thanks
[00:04] <cjwatson> xnox: Nor in any live filesystem build
[00:04] <xnox> yeap. =(
[00:04] <ogra_> xnox, i doubt modaliases even works
[00:04] <xnox> ogra_: well, they sure do install the right nvidia drivers.
[00:04] <ogra_> (never tried though)
[00:04] <ogra_> oh, i mean on the phone image indeed :)
[00:05] <xnox> ogra_: everything i say, usually comes from the prism of ubiquity installer =)
[00:05] <ogra_> :)
[01:02] <cjwatson> Oh, and ubuntu-touch-meta is waiting for a unity-scope-click autopkgtest which is in a huge queue, albeit quite close to the top of it
[01:02] <cjwatson> But the queue might be listed backwards ...
[01:03] <cjwatson> Like watching paint dry
[01:09] <cjwatson> http://d-jenkins.ubuntu-ci:8080/label/adt/load-statistics
[01:09] <cjwatson> oh hai gcc
[01:34] <slangasek> there we are, u-t-m into utopic
[01:34] <pmcgowan> slangasek, was just looking for the mr,
[01:34] <cjwatson> Not published yet
[01:34]  * slangasek nods
[01:35] <ToyKeeper> Hmm, given the ETA on a new build, I think I'll head off for dinner...  unlikely it'll be ready until after I get back.
[01:36] <cjwatson> Though publishing now
[01:36] <cjwatson> (It's in the "oh dear my new database servers haven't been plugged in yet" stage)
[01:40] <pmcgowan> slangasek, I missed the resolution, but I dont see any changes to u-t-m in lp
[01:41] <cjwatson> https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/+publishinghistory
[01:41] <cjwatson> The main package view is unhelpful when a change is mid-publication
[01:41] <cjwatson> Actually even more clearly, https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/+changelog
[01:42] <pmcgowan> thanks
[01:43] <pmcgowan> so what exactly broke?
[01:50] <slangasek> pmcgowan: the builds had an unintended reliance on some undefined behavior (ordering of package configuration), and because two packages were being configured in the opposite order from before, the mir client library config was pointing to a shouldn't-have-been-there-but-was mesa build instead of the android build
[01:51] <slangasek> (which comes back around to us having better auditing of new packages winding up on the image - I don't know when the mesa packages landed there, but it was probably several weeks ago and went unnoticed)
[01:51] <pmcgowan> +1 on better auditing of new packages --- sore point
[01:53] <pmcgowan> thanks guys
[01:54] <rsalveti> I think we always had the mesa packages in there
[01:54] <rsalveti> since mir decided to split the backends
[01:56] <cjwatson> Yup
[01:56] <cjwatson> First livefs build log matching /libmirclient.*mesa/ is 20140311
[01:56] <rsalveti> right
[01:56] <rsalveti> long long ago
[01:57] <pmcgowan> how do we prevent this type of thing from screwing us again
[01:57] <cjwatson> Probably corresponds to https://launchpad.net/ubuntu/+source/mir/0.1.6+14.04.20140310-0ubuntu1
[01:58] <cjwatson> We keep on plugging away at undefined behaviour in builds wherever we see it, and each time we find one that makes things more robust
[01:59] <pmcgowan> I still dont understand why this hit us today
[02:00] <pmcgowan> something deep in the tools?
[02:04] <cjwatson> I don't think it's worth tracking down
[02:04] <cjwatson> Nondeterministic behaviour is nondeterministic
[02:04] <imgbot> [02:04] <pmcgowan> computers are determinstic yes ?
[02:04] <cjwatson> There's probably something that tweaked things, but I don't see it as a useful exercise
[02:05] <pmcgowan> what happened here
[02:05] <cjwatson> Nondeterministic as in the behaviour is not specified
[02:05] <pmcgowan> hmmm
[02:05] <slangasek> pmcgowan: the ordering of package configuration by apt is undefined, so some small unrelated tweak in the system probably tripped it off
[02:05] <cjwatson> Or rather it's undefined when not constrained by dependencies
[02:05] <slangasek> the same update introduced three new packages and dropped one, which were legitimate changes that could have permuted apt
[02:06] <cjwatson> Trying to track this down will likely just lead to some entirely reasonable change
[02:06] <slangasek> ah, and looks like cjwatson beat me to triggering the rebuild
[02:06] <cjwatson> And won't tell us anything interesting
[02:06] <cjwatson> slangasek: Not I
[02:06]  * slangasek nods
[02:06] <slangasek> oh
[02:06] <cjwatson> cron? :)
[02:06] <slangasek> well, someone did, hopefully they made sure it was in the archive first :)
[02:06] <pmcgowan> just looking for a way to not get burned again
[02:06] <slangasek> heh, dunno
[02:06] <pmcgowan> you guys can tell me what that is
[02:07] <slangasek> pmcgowan: in this case, removing packages that don't belong on the image in the first place would have saved us
[02:07] <cjwatson> Whatever failure happened here happened months ago
[02:07] <pmcgowan> slangasek, omg _1 again
[02:07] <pmcgowan> +1
[02:07] <cjwatson> IMO the fundamental problem here is abusing selective package installation when runtime detection is the right answer
[02:07] <cjwatson> Removing packages that don't belong on the image is yet another fragile workaround for poor design
[02:08] <cjwatson> It's all too easy for that sort of thing to creep back in for one reason or another
[02:08] <rsalveti> yeah
[02:08] <pmcgowan> I buy that
[02:08] <rsalveti> best thing here would indeed mir to do the right thing during runtime
[02:08] <cjwatson> But if mir weren't relying on package-installation-dependent alternatives to behave appropriately for the hardware, we wouldn't have had this problem in the first place
[02:08] <cjwatson> Convergence will force sanity on this :)
[02:09] <pmcgowan> exactly
[02:09] <pmcgowan> lets go 156
[02:09] <pmcgowan> thanks guys
[02:10] <rsalveti> guess this build was started by cron
[02:10] <rsalveti> will be around to see if it's indeed a good one
[02:10] <cjwatson> Yeah
[02:11] <cjwatson> It started after the relevant publisher run finished
[02:11] <rsalveti> live build logs should tell us (and the x86 one gets done way before the armhf one)
[02:11] <cjwatson> Last one didn't, but usually yes :)
[02:11] <rsalveti> haha, indeed
[02:12] <pmcgowan> cjwatson, btw why are you awake?
[02:12] <pmcgowan> ;)
[02:12] <cjwatson> insomnia combined with too freaking much to do
[02:12] <cjwatson> combined with ooh-shiny about scalingstack
[02:13] <rsalveti> lol
[02:13] <pmcgowan> man
[02:13] <cjwatson> but I don't usually sleep that well anyway
[02:30] <rsalveti> update-alternatives: using /usr/lib/i386-linux-gnu/mir/platformgraphics/android/ld.so.conf to provide /etc/ld.so.conf.d/i386-linux-gnu_mirplatformgraphics.conf (i386-linux-gnu_mirplatformgraphics_conf) in auto mode
[02:30] <rsalveti> update-alternatives: using /usr/lib/i386-linux-gnu/mir/clientplatform/mesa/ld.so.conf to provide /etc/ld.so.conf.d/i386-linux-gnu_mirclientplatform.conf (i386-linux-gnu_mirclientplatform_conf) in auto mode
[02:30] <rsalveti> still same issue
[02:30] <rsalveti> https://launchpadlibrarian.net/180947443/buildlog_ubuntu_utopic_i386_ubuntu-touch_UPLOADING.txt.gz
[02:31] <rsalveti> slangasek: ^
[03:00] <slangasek> rsalveti: hmm
[03:13] <slangasek> rsalveti, cjwatson: right, even the direct seeding of libmirclientplatform-android doesn't fix it because something else in the ubuntu-touch dependencies alpha-sorts earlier and triggers pulling in -mesa <sigh>
[03:13] <slangasek> rsalveti, cjwatson: so I'm going to proceed with implementing ogra_'s livefs fix
[03:13] <slangasek> livecd-rootfs, I mean
[03:30] <bzoltan1> rsalveti: slangasek: may I get a manual ack to the QtCreator plugin in the silo5? I have ,moved the qlick-reviewers-tools to the Recommends form the Suggests section. Yes, it is a desktop only package and a super minor change.
[03:30] <bzoltan1> rsalveti: slangasek:  the qlick-reviewers-tools  is available in Utopic and Trusty of course
[03:34] <imgbot> [03:34] <imgbot> [03:46]  * ToyKeeper waits for 156 to finish flashing
[04:03] <veebers> slangasek: if I build the packages in my silo, will that impact or hold up other builders that people might want access to to get out of traincon0?
[04:05] <bzoltan> veebers: ToyKeeper: do you know anybody who could ack that ^^^ package?
[04:05] <bfiller> slangasek: what team do I need to be on set importance and assignee on ubuntu source package bugs (like this one: https://bugs.launchpad.net/ubuntu/+source/messaging-app/+bug/1346502)
[04:05] <veebers> bzoltan: ack as in QA approve? If so I only know of ToyKeeper. Otherwise robru perhaps?
[04:06] <bzoltan> veebers: no,  QA approve is not what I need, the package changed a dependency.
[04:06] <ToyKeeper> So... bad news.  Image 156 is broken in exactly the same way as 155.
[04:07] <ToyKeeper> cjwatson, slangasek: ^^^
[04:07] <veebers> bzoltan: ah right, not sure then sorry
[04:08] <ToyKeeper> bzoltan: Honestly, it's hard to move forward in the landing process at this time of day, since none of the right people are around.
[04:09] <ToyKeeper> ... and image 156 didn't fix the critical bug it was supposed to fix, so we're kind of stalled.
[04:10] <ToyKeeper> Late-NZ hours are sparsely populated.
[04:12] <veebers> ToyKeeper: Would you have any idea on when traincon-0 might be lifted (just out of interest)? i.e. if a new fixing image was spun up right now would it take, hours or 10's of minutes?
[04:21] <ToyKeeper> veebers: If the new image started now and had the correct fix in it, I think traincon could be lifted as soon as the .eu release manager logs on and checks the test results.
[04:25] <ToyKeeper> veebers: Yup, the crit that 155 was supposed to fix seems to be fixed...  so now we just need to fix the crit introduced in 155.
[04:27] <ToyKeeper> If that's fixable before 157 builds, I'd assume 157 will get promoted and end traincon 0 sometime in the next ~10 hours or so.
[04:30] <slangasek> bfiller: importance/assignee> Ubuntu bug control; https://wiki.ubuntu.com/UbuntuBugControl
[04:30] <slangasek> veebers: building in a silo is fine wrt TRAINCON-0, unless the silos are so committed that we don't have a place for critical builds
[04:31] <slangasek> ToyKeeper: yes, sorry, should've said - rsalveti IDed 156 as broken the same way as 155 during the build, I'm spinning 157 now which should fix it
[04:32] <slangasek> bzoltan: I've queued up https://ci-train.ubuntu.com/job/landing-005-2-publish/79/ to look at, but I need to run out to the store so it'll be a bit
[04:32] <bzoltan> slangasek: thank you
[04:33] <bfiller> slangasek: thanks
[04:38] <slangasek> bzoltan: alternatively, I may find myself with a few minutes to spare while waiting on livecd-rootfs to fully publish, and just get it done
[04:38] <bzoltan> slangasek:  that would be cool.. the whole release is two lines change :)
[04:39] <slangasek> yeah - change looks fine, now I need to find the button
[04:39] <slangasek> (which is basically "log in to jenkins")
[04:39] <slangasek> bzoltan: approved
[04:39] <imgbot> [04:39] <bzoltan> slangasek:  you rock. thanks
[04:40] <ToyKeeper> slangasek: Awesome, didn't know you were still around.  :)
[04:40] <slangasek> ToyKeeper: to my growing chagrin
[04:41] <ToyKeeper> People will be quite pleased to have the landing process unblocked though.  :)
[04:43] <olli> ToyKeeper, that's an understatement ;)
[05:30] <elopio> cihelp: something is wrong with the unity unlock script
[05:30] <elopio>   File "/usr/lib/python3/dist-packages/unity8/process_helpers.py", line 178, in _get_unity_pid
[05:30] <elopio>     return int(status.split()[-1])
[05:30] <elopio> ValueError: invalid literal for int() with base 10: 'start/running'
[05:31] <elopio> I guess that it's no longer printing the process id when it's run.
[05:31] <elopio> Saviq ^
[05:31] <elopio> This comes from the latest dash results: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/576/consoleFull
[05:40] <plars> elopio: 155 and 156 look like they are in bad shape, from the mailing list, I know 155 has a broken UI. I suspect 156 has the same problem but I haven't tried it yet locally
[05:41] <plars> elopio: yeah, see the scroll back, but never fear - 157 will save us all!
[05:41] <plars> :)
[05:43] <slangasek> well, I can't imagine why that would yield a 'start/running' result though
[06:04] <veebers> slangasek: sweet thanks, I just didn't want to tie up resources that were going to sorting out the crit issues.
[06:04] <veebers> ToyKeeper: I see, thanks :-)
[06:58] <slangasek> image 157 built successfully, not waiting for delta generation
[07:04] <imgbot> [07:04] <imgbot> [07:07] <slangasek> ToyKeeper, davmor2, sil2100: ^^ there; image 157 built without -mesa bits
[07:09] <ogra_> and does it boot ?
[07:09] <ogra_> :)
[07:11] <ToyKeeper> Awesome.  Flashing again...
[07:11] <slangasek> ogra_: that's for someone east of me to figure out ;P
[07:11] <ogra_> heh
[07:11] <ogra_> do we have any explanation why this happened at all ?
[07:12] <ToyKeeper> ogra_: Side effect of a long-standing build issue, and we simply saw more symptoms today.
[07:12] <ToyKeeper> The build pulls in both desktop and phone packages, and the result depends on which one gets configured first.
[07:12] <ogra_> hmm
[07:12] <ToyKeeper> It shouldn't be pulling in the desktop packages at all though.
[07:12] <ogra_> still interesting that it came just out of the blue
[07:12] <slangasek> no, that's really not interesting
[07:13] <ogra_> (i know about the alternatives issue, we have it since years in different variations)
[07:13] <slangasek> because the configure ordering of the packages is *arbitrary* and it was an accident that it worked at all before
[07:13] <ToyKeeper> Not sure what exactly changed to trigger new symptoms, but the fix is pretty much the same either way.  We need to get rid of the desktop packages anyway, to save space.
[07:13] <slangasek> this was a build that changed the set of packages installed (some packages added, some packages removed) - that's enough to trigger it
[07:14] <ogra_> that were many of the 150 builds before too
[07:14] <ToyKeeper> In some ways, it's kind of nice that this was brought up, since it provides an obvious way to reduce the image size right when we need to make it smaller.
[07:26] <jibel> 157 boots, there is a display but binder_2 uses 100% CPU
[07:31] <ToyKeeper> Right, duh.  First boot never sees media.
[07:31] <jibel> back to normal after another reboot.
[07:38] <ToyKeeper> Six crash dumps so far...  seems like we don't really put a high priority on that though.
[07:38]  * sil2100 has his fingers crossed for #157
[07:38] <sil2100> uh
[07:38] <ToyKeeper> The thumbnailer crashing is new, though.
[07:44] <ToyKeeper> Not sure when the next tester will be around, but I need to be up in a few hours and I'm not sure I should start a 2-hour testing session.
[07:44] <ogra_> ToyKeeper, davmor2 and popey should be around soon ... dont bother, get some sleep
[07:44] <sil2100> ToyKeeper: davmor2 should be up in around 30 minutes
[07:45] <sil2100> ToyKeeper: thanks for working on this and have have a nice night ;)
[07:45] <ogra_> ++
[07:45] <ogra_> and slangasek too !!!
[07:45] <sil2100> Indeed! I already said goodnights to slangasek though!
[07:45] <ToyKeeper> #157 definitely looks like a huge improvement so far, but that's without going into a lot of detail.
[07:46] <sil2100> ToyKeeper: that... that's one of the nicest things I heard recently!
[07:46] <sil2100> ;p
[07:46] <ogra_> yeah, compared to two unbootable images the one eyed image is king ;)
[07:47] <ToyKeeper> (in other words, nothing user-visible exploded yet)
[07:47] <ToyKeeper> 'night, and good luck.  :)
[07:48] <jibel> i've a gallry-app crash when I delete a picture with 157, https://errors.ubuntu.com/oops/50a2cd30-16f4-11e4-8cfb-fa163e4aaad4
[07:52] <sil2100> jibel: does it happen every time?
[07:52] <popey> is #157 okay to flash to?
[07:52] <jibel> sil2100, not every time.
[07:53] <jibel> popey, 157 is okay.
[07:53] <mhr3> sil2100, could you (or get someone to) help pete with silo 008? unity-scopes-shell now deps on location-service, which isn't buildable on arm64 etc, so scopes-shell is no longer buildable there either
[07:54] <sil2100> mhr3: uh, hmm...
[07:54] <tvoss> sil2100, mhr3 let me see if I can fix arm64 for location-service
[07:54] <mhr3> tvoss, it's also ppc and ppc64
[07:55] <tvoss> mhr3, ack, on my list
[07:55] <sil2100> mhr3: I'll try, but this basically means that we'll have to remove -shell for those 3 archs - can't we somehow work around it?
[07:55] <sil2100> Ah ok, that would be best
[07:55] <mhr3> pete-woods, fyi ^^
[07:57] <popey> thanks jibel
[08:02] <tvoss> sil2100, we would have to conditionally include build dependencies for location service to compile on arm64 and ppc
[08:02] <sil2100> tvoss: what build dependencies would that have to be?
[08:02] <tvoss> sil2100, I think libubuntu-platform-hardware-api-headers and libubuntu-platform-hardware-api-dev,
[08:04] <sil2100> tvoss: ok
[08:14] <Saviq> sil2100, hey, can you please upload http://people.canonical.com/~msawicz/ubuntu-touch.tar.xz to silo 6?
[08:17] <robru> Saviq, ah sorry about that, I uploaded it but I guess it was rejected
[08:18] <tvoss> sil2100, back ... did you reply to the list of build dependencies?
[08:19] <robru> Saviq, so I guess if I can't upload it with your signature, I'll need to upload it with my signature, which will require me to build the source package myself.
[08:19] <Saviq> robru, you should be able to just resign it with debsign
[08:19] <davmor2> boo!
[08:19] <Saviq> I *think*
[08:20] <davmor2> ogra_, sil2100: I'm guessing that 157 fixes the world if the spam I'm getting from irssi is right
[08:20] <davmor2> are we looking at this image for promotion then if it works?
[08:20] <robru> Saviq, debsign failed because I don't have your secret ey
[08:21] <Saviq> robru, oh interesting... just go for it, rebuild it
[08:23] <robru> Saviq, ok uploaded, should be good for real this time
[08:23] <seb128> you don't need to rebuild the source to sign a .changes/dsc
[08:23] <Saviq> robru, thanks
[08:23] <robru> Saviq, you're welcome
[08:23] <seb128> just design -k<key> .changes
[08:23] <seb128> debsign
[08:24] <robru> hmm
[08:24] <sil2100> tvoss: yeah, I said that it makes sense...
[08:24] <robru> seb128, thanks, too late ;-)
[08:24] <seb128> yw
[08:24] <popey> updated to #157 took 17 minutes at the google logo
[08:24] <sil2100> tvoss: but will location-service compile without libubuntu-platform-hardware-api-headers etc.?
[08:24] <tvoss> sil2100, yup, the build setup checks for the header files separately
[08:25] <robru> Saviq, yep, just got the email, looks accepted
[08:25] <sil2100> tvoss: ok, and it will still *work* for those platforms?
[08:25] <Saviq> robru, \o/
[08:25] <Saviq> robru, and shouldn't you sleep?
[08:25] <sil2100> robru is still in Europe or has a jetlag ;)
[08:26] <robru> Saviq, I'm in Strasbourg for GUADEC, it's 10AM here ;-)
[08:26] <Saviq> robru, ah good :)
[08:26] <sil2100> tvoss: if you have a branch for that, just push it to mhr3 or pete-woods so they can add it to their landing :)
[08:27] <pete-woods> tvoss: FYI I already have this MR for some packaging issues with location-service: https://code.launchpad.net/~pete-woods/location-service/dev-packaging/+merge/228457
[08:28] <tvoss> sil2100, *work* yes, but not using an android chipset :) which is somewhat expected I would say
[08:28] <sil2100> Indeed ;)
[08:33] <robru> sil2100, how's it going? is image 157 ok
[08:33] <robru> ?
[08:48] <sil2100> Ok, firefox crashing on closing hangouts is really annoying
[08:49] <sil2100> robru: davmor2 is dogfooding it now, but it boots on all supported platforms!
[08:49] <sil2100> (SHIP IT)
[08:49]  * davmor2 slaps sil2100 repeatedly
[08:49] <sil2100> Ouch
[08:52] <davmor2> sil2100: I has Music and video so that is mediascanner fixed now to ensure they work in the players :D
[08:54] <robru> sil2100, ah great
[09:06] <tvoss> sil2100, pete-woods https://code.launchpad.net/~thomas-voss/location-service/fix-1349746/+merge/228628
[09:06] <tvoss> pete-woods, could you add that mp to your silo?
[09:06] <pete-woods> tvoss: will do
[09:06] <tvoss> pete-woods, thank you
[09:07] <pete-woods> tvoss: actually I already added a change that does exactly the same thing (after what you said earlier in the channel)
[09:07] <pete-woods> was just checking whether it would build
[09:07] <pete-woods> tvoss: https://launchpadlibrarian.net/180965111/buildlog_ubuntu-utopic-ppc64el.location-service_2.0.1%2B14.10.20140729-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:09] <tvoss> pete-woods, ah, let me fix that
[09:14] <pete-woods> tvoss: https://code.launchpad.net/~thomas-voss/location-service/fix-1349746/+merge/228628
[09:14] <pete-woods> is that the change you're making?
[09:14] <pete-woods> whoops
[09:14] <pete-woods> I meant that: https://code.launchpad.net/~pete-woods/location-service/dev-packaging/+merge/228457
[09:14] <tvoss> pete-woods, yup
[09:15] <pete-woods> tvoss: ^
[09:15] <tvoss> pete-woods, yup
[09:15] <tvoss> pete-woods, let's take your branch then, I will abandon mine
[09:16] <pete-woods> tvoss: okay, just check it actually builds first, though :)
[09:28] <pete-woods> woot! ppc64el build succeeded!
[09:31] <pete-woods> tvoss: we still seem to have a depwait on ppc for libnet-cpp-dev
[09:31] <tvoss> pete-woods, okay, let me take a look
[09:34] <tvoss> sil2100, could you help here: https://launchpadlibrarian.net/180475523/buildlog_ubuntu-utopic-powerpc.net-cpp_1.0.0%2B14.10.20140718-0ubuntu1_MANUALDEPWAIT.txt.gz
[09:34] <tvoss> ?
[09:45] <cjwatson> tvoss: hm, how did that build anywhere?  net-cpp is in main, those packages are in universe
[09:45] <thostr_> can I get a silo for line 33
[09:45] <cjwatson> tvoss: I suspect there was actually a different failure in the PPA
[09:45] <tvoss> cjwatson, hmmm ...
[09:45] <cjwatson> but it may not be accessible any more
[09:46] <tvoss> cjwatson, so the build-dependencies are only used in testing
[09:46] <tvoss> cjwatson, I guess that's why
[09:46] <cjwatson> tvoss: ah, here's the real failure.  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-008/+build/6194260
[09:46] <cjwatson> tvoss: That might have passed if only somebody had hammered retry on it a few times at the time
[09:47] <tvoss> cjwatson, yup, agreed ... the test is testing timeout behavior -> recipe for flakyness
[09:47] <cjwatson> tvoss: but still, the main -> universe build-deps are a violation, they either need somebody to follow the MIR chain or we need to drop them
[09:48] <cjwatson> tvoss: that said, for the purposes of this change, you could just do a no-change rebuild of net-cpp in that silo, and we could make sure all its builds complete
[09:48] <tvoss> cjwatson, so it's only jsoncpp, correct?
[09:48] <cjwatson> tvoss: we don't actually need to address this right now
[09:48] <cjwatson> tvoss: and python-flask-script
[09:48] <tvoss> ah, looked up python-flask
[09:48] <cjwatson> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html says there are no MIRs filed for these as yet
[09:49] <tvoss> cjwatson, ack, putting it on my list to drop them
[09:49] <cjwatson> but anyway, just do a no-change rebuild in a silo for now and we should be able to get it built
[09:49] <tvoss> cjwatson, just asked pete-woods to do so
[09:49] <tvoss> cjwatson, I'm trying to add an mp to line 35 in the spreadsheet but I cannot edit that line anymore. Is it locked somehow?
[09:49] <cjwatson> how's dogfooding looking?  I think the libav megatransition might be about to land
[09:50] <cjwatson> sil2100: ^- can you check tvoss's spreadsheet problem?
[09:52] <tvoss> sil2100, I would like to have https://code.launchpad.net/~thomas-voss/location-service/fix-1349704/+merge/228632 added to the silo as it is waiting on silo6 anyways
[09:52] <tvoss> sil2100, if there are conflicts, I'm happy to handle them
[09:53] <tvoss> sil2100, and while you are at it: https://code.launchpad.net/~thomas-voss/location-service/fix-1347887/+merge/228561 should be fine, too
[09:55] <pete-woods> cjwatson: hi, could you reconfigure silo 8? (with the stuff tvoss was talking about in it)
[09:55] <pete-woods> I've just added a no-change MR for net-cpp
[09:55] <cjwatson> sure, one moment, although please note that normally you should ask the person listed under "CI Train support" in the topic
[09:56] <pete-woods> cjwatson: okay, good to know :) (this is really my first ci-train experience, so learning everything here)
[09:57] <cjwatson> pete-woods: done
[09:57] <pete-woods> thanks!
[09:59] <cjwatson> pete-woods: heh, I think it might need more force
[09:59] <cjwatson> "No new useful revision published compared to dest, no need to upload this component"
[10:00] <cjwatson> pete-woods: want me to sort it out?
[10:00] <cjwatson> needs PACKAGES_TO_REBUILD: net-cpp, FORCE_REBUILD: yes, I think
[10:00] <sil2100> tvoss, cjwatson: yeah, let me take a look, I've been having breakfast
[10:00] <pete-woods> cjwatson: okay, thanks, I'd like to learn the rules myself, so I can sort things out in a pinch :)
[10:01] <tvoss> sil2100, sure :)
[10:01] <cjwatson> pete-woods: ok, I suggest aborting the current build and rerunning with the parameters above
[10:01] <cjwatson> there's a little red x in the top right of the jenkins console view if you haven't seen it
[10:01] <pete-woods> yep, that's my favourite jenkins button so far :)
[10:02]  * sil2100 checks the permissions
[10:04] <sil2100> tvoss: could you try editing the spreadsheet now?
[10:04] <tvoss> sil2100, ack
[10:05] <sil2100> pete-woods: just so you know, use the red abort button with caution with build jobs ;)
[10:05] <pete-woods> sil2100: okay, I just use it when it goes into the waiting on buildwaits forever state usually
[10:05] <sil2100> pete-woods: it can lead to CI Train staying in an unknown state, if the build job gets aborted before the .config files are generated
[10:05] <sil2100> pete-woods: and that's the right way to go :)
[10:05] <pete-woods> okay, will watch out for that
[10:06] <sil2100> tvoss: give me a sign if it works, since maybe some permissions got lost during the spreadsheet modifications
[10:07] <tvoss> sil2100, nope
[10:07] <tvoss> sil2100, not working, let me restart chrome
[10:07] <sil2100> tvoss: hmm, ok, back to the drawing board then
[10:08] <tvoss> sil2100, nope, still not working
[10:09] <sil2100> tvoss: are you logged into the google account on the spreadsheet?
[10:09] <sil2100> tvoss: as I don't see you on the list of logged people
[10:09] <tvoss> sil2100, of course not ... face -> desk
[10:09] <sil2100> ;)
[10:10] <Saviq> tvoss, google is quite nasty recently when it comes to logging you out
[10:10] <Saviq> sil2100, could we have a silo for line 37?
[10:10] <cjwatson>  final: abiword,acoustid-fingerprinter,alsa-plugins-extra,amide,aria2,aubio,audacious,audacious-plugins,audacity,avbin,avifile,bino,blender,bombono-dvd,cairo-dock-plug-ins,calligra,cantata,charybdis,chromaprint,claws-mail,cmus,criu,crtools,cups,curl,darktable,dff,digikam,dvbcut,dvdstyler,dvswitch,dwb,dynalogin,echoping,emacs24,empathy,eog-plugins,event-dance,evolution,evolution-data-server,exim4,exiv2,ffdiaporama,ffmpeg2theora,ffmpegt ...
[10:10] <ogra_> psivaa, the dashboard looks like we only have one device running tests ...
[10:11] <cjwatson> ... humbnailer,ffmpegthumbs,ffms2,filezilla,forked-daapd,freetds,fuse-emulator-utils,gallery-app,geeqie,gexiv2,gimplensfun,glib-networking,gmerlin-avdecoder,gmerlin-encoders,gnash,gnome-color-manager,gnome-commander,gnome-documents,gnome-online-miners,gnunet,gnutls28,goldendict,gpac,gpscorrelate,grilo-plugins,gst-libav1.0,gthumb,guvcview,gwenview,handbrake,harvid,hedgewars,hugin,idjc,imms,inspircd,ircd-ratbox,jd,jitsi,jugglemaster,kde ...
[10:11] <cjwatson> ... -runtime,kdeplasma-addons,kfilemetadata,kid3,kino,kphotoalbum,kradio4,krename,lebiniou,lftp,libabw,libam7xxx,libaudclient,libav,libavg,libcdr,libdlna,libe-book,libetonyek,libetpan,libextractor,libfreehand,libgadu,libgdata,libgroove,libinfinity,libkexiv2,libmicrohttpd,libmspub,libmwaw,libodfgen,libphash,libquicktime,librelp,libvisio,libwpd,libwpg,libwps,liggghts,lightspark,linphone,lives,loudmouth,luminance-hdr,lynkeos.app,marble,m ...
[10:11] <sil2100> Saviq: o/
[10:11] <cjwatson> ... ediatomb,merkaartor,minbif,minidlna,miro,mlt,moc,motion,mpd,mplayer2,mpop,mpv,mrpt,msmtp,mythexport,neon27,nepomuk-core,network-manager-openconnect,ngircd,nifti2dicom,ola,opal,openconnect,opencv,openscenegraph,osm2pgsql,ovito,pan,paraview,pcp,performous,pinot,plasma-nm,protobuf-c,pyexiv2,qemu,qmmp,qutecom,rawstudio,renpy,riemann-c-client,rtmpdump,shotdetect,silan,spek,squeezelite,strigi,subsurface,survex,transcode,tupi,ubuntustudi ...
[10:11] <cjwatson> ... o-meta,ucommon,ufraw,vdr-plugin-xineliboutput,viewnior,visp,vlc,vtk,vtk6,webfs,weechat,wireshark,writerperfect,wxsvg,x264,xbmc,xine-lib-1.2,xjadeo,xmlsec1,xmms2,xpra,yade,yaz,yorick-av,zoneminder
[10:11] <cjwatson> finally!
[10:11] <cjwatson> (sorry, slightly larger paste than I expected)
[10:11] <tvoss> sil2100, mind reconfiguring?
[10:11] <ogra_> crazy
[10:11] <sil2100> Saviq: with override conflicts?
[10:11] <sil2100> tvoss: sure
[10:11] <Saviq> sil2100, yup, thanks
[10:12] <psivaa> ogra_: let me take a look at it.. loading of dashboard takes ages for me
[10:13] <ogra_> psivaa, yeah, and it might be a dashboard issue after all ... but i only see what looks like only one device
[10:13] <cjwatson> so that's a 206-package migration, took weeks to organise and just had to go for it, please don't ask me to back it out ... :-)  I hope the phone won't be affected significantly, but if it is let's try to move forward rather than back
[10:13] <cjwatson> proposed-migration should be *much* faster after this
[10:13] <ogra_> we should make a policy that forbids more than 50 reverse build deps if you are not libc :P
[10:14] <cjwatson> because code reuse is for other people? :P
[10:14] <ogra_> heh
[10:14] <ogra_> because it makes transitions easier :)
[10:15] <psivaa> ogra_: only one mako has finished running the tests. the other two are still running
[10:15] <psivaa> so you're right :)
[10:15] <ogra_> heh
[10:17] <Saviq> sil2100, actually, recon on silo 5 please
[10:17] <Saviq> sil2100, had to add scopes...
[10:17] <sil2100> Saviq: ok ;)
[10:17] <sil2100> davmor2: soooo... how's it going so far?
[10:18] <davmor2> sil2100: so far so good
[10:21] <sil2100> ogra_, psivaa: but so far that one device that finished looks relatively ok... 3 additional failures in calendar though
[10:21] <ogra_> yeah
[10:21] <ogra_> well, lets see how the other two come out
[10:23] <cjwatson> pete-woods: uh
[10:23] <cjwatson> pete-woods: please don't reupload like that
[10:24] <sil2100> Oh, whole silo rebuild?
[10:24] <pete-woods> cjwatson: what did I do wrong?
[10:24] <cjwatson> pete-woods: we can retry individual failed builds; hammering the build button in citrain does an entire new upload to the PPA, which triggers a rebuild on all architectures, which is wasteful
[10:24] <cjwatson> in fact I'd already retried the failed build
[10:24] <cjwatson> pete-woods: just hands off the build button for the moment please :)
[10:24] <sil2100> ;)
[10:25] <pete-woods> cjwatson: it's an actual change — we disabled the flaky test for the moment
[10:25] <cjwatson> citrain's "Build" operation really needs to be called "Upload"
[10:25] <cjwatson> ah!
[10:25] <cjwatson> ok, my bad, I didn't think to check that the "null-commit" branch was still null
[10:25] <pete-woods> yeah, it's not, needs a new name
[10:25] <cjwatson> shame you didn't change the commit message
[10:26] <pete-woods> forgot to do that!
[10:26] <cjwatson> too late now unless we do yet another upload
[10:26] <sil2100> hm, this gives me an idea... maybe I could add a 'rebuild uploaded packages' button in CI Train?
[10:26] <pete-woods> that would be really useful!
[10:26] <cjwatson> do you mean "retry failures"?
[10:26] <sil2100> That would try rebuilding the failed builds in the silo PPA - but I wonder if I have API access to that
[10:26] <cjwatson> you do
[10:27] <cjwatson> build.retry()
[10:27] <sil2100> Then awesome
[10:27] <sil2100> Let me add that later
[10:27] <cjwatson> well, anything in ~ci-train-ppa-service does
[10:27] <cjwatson> don't just say "rebuild uploaded packages" though, because that implies that you can rebuild something that succeeded that way
[10:27] <sil2100> Yeah, righto, I meant rebuilding failed uploaded packages
[10:27] <sil2100> ;)
[10:28] <cjwatson> right, "retry" is the terminology for that in Launchpad so it should match
[10:49] <pete-woods> would this "retry" button nudge the buildwait failures, like are in silo 8?
[10:49] <sil2100> Dep-wait failures you mean?
[10:50] <pete-woods> yes, that's what I meant
[10:50] <sil2100> Not sure yet, but those actually get resolved by themselves once the dependency appears
[10:50] <pete-woods> sure, but you have to wait like an hour sometimes
[10:51] <cjwatson> retry generally ought to prod those explicitly
[10:51] <cjwatson> seeing as you need the watch-only machinery anyway
[10:51] <cjwatson> maybe you should be able to limit by arch
[10:51] <cjwatson> or something
[10:52] <sil2100> I guess I might add various filtering, like per-arch and per-project
[10:52] <cjwatson> pete-woods: FWIW it's a cron job that runs at :25 and :55
[10:52] <pete-woods> oh, so max 30 minutes then :)
[10:52] <cjwatson> should be yes
[10:52] <pete-woods> 3 mins to go :)
[10:53] <pete-woods> I take it it'd be a ton of work to make the depwait retrigger happen in an event-based manner, rather than cron based?
[10:53] <cjwatson> yep
[10:53] <pete-woods> fair enough
[10:53] <cjwatson> let me introduce you to the Launchpad team with one full-time developer
[10:54] <pete-woods> wowsers
[10:54] <cjwatson> actually I think two now - but anyway, seriously understaffed
[10:54] <cjwatson> gotta prioritise
[10:54] <pete-woods> this is the only company I have ever worked at where there are more projects than people
[10:56] <cjwatson> the other problem with making the dep-wait retry job be event-based is that IIRC it's much cheaper to compute this way round, so there's some tradeoff involved
[10:57] <pete-woods> I believe in making the computers work harder, so I don't have to :)
[10:58] <pete-woods> but seriously, if you're the only guy making this whole thing work, then I totally understand
[11:05] <pete-woods> so the build still hasn't kicked off 10 minutes after :55. is there usually a big queue of stuff that you have to wait for?
[11:07] <sil2100> davmor2: how far are you from finishing? :)
[11:07] <davmor2> another 30 minutes or so
[11:11] <cjwatson> pete-woods: Not me, I only chip in from time to time
[11:11] <cjwatson> pete-woods: seems to be running now
[11:11] <pete-woods> cool :)
[11:11] <cjwatson> there may have been a short queue, yeah
[11:12] <cjwatson> pete-woods: cheaper to compute - can make a practical difference, especially if you overflow a time slot or end up massively slowing something else down that something else relies on being quick
[11:12] <cjwatson> anyway, I'm handwaving
[11:13] <cjwatson> pete-woods: (Launchpad is mainly William, under CI)
[11:13] <pete-woods> okay, that's good to know
[11:15] <psivaa> ogra_: sil2100: some app tests failed miserably... failing to launch the app it seems. i'd rerun the tests if there is no objection
[11:16] <sil2100> ugh
[11:16] <psivaa> i.e. if dogfooding showed any similar behaviour
[11:16] <sil2100> psivaa: is that problems with launching the app or screen unlock?
[11:16] <psivaa> davmor2: ^ did you notice anything similar.. sorry i dint read the backlog if you've already said anything to that effect
[11:17] <sil2100> psivaa: did all those happen on one device?
[11:17] <psivaa> sil2100: in two devices
[11:17] <psivaa> sil2100: it's in launch app step afaics
[11:18] <sil2100> Grrr
[11:18] <sil2100> psivaa: ok, try re-launching, let's see how it goes
[11:18] <davmor2> psivaa: seems to be fine here which apps I've only tried a few
[11:20] <psivaa> davmor2: sil2100: ack, thanks
[11:25] <sil2100> davmor2: it fails launching for instance notes, gallery, clock, camera etc.
[11:25] <sil2100> davmor2: on smoketesting that is
[11:27] <davmor2> sil2100, psivaa: they all open but take about 7-10 seconds
[11:27] <ogra_> oh, look, only 101 failures :P
[11:27] <sil2100> oh?
[11:28] <sil2100> I don't see anything specific in 155
[11:29] <ogra_> tvoss, send some diplomats, quick !
[11:29] <sil2100> There was only upstart and lightdm
[11:30] <psivaa> sil2100: ogra_: davmor2: rerun of the gallery app test is not looking great. see similar failures as the original run ones on the first look
[11:32] <ogra_> sil2100, and android
[11:32] <sil2100> :|
[11:32] <sil2100> Why did we have a new android on 156?
[11:32] <sil2100> I mean, 155
[11:33] <sil2100> ARGH
[11:33] <ogra_> sd card support for the emulator it seems
[11:33] <ogra_> *shouldn't* have any impact
[11:33] <sil2100> We need moar eyeballs
[11:34] <sil2100> olli, pmcgowan: we seem to be having some problems with our latest images, we would need some people helping out in identifying which component broke
[11:34] <ogra_> i wonder if building gallery with exiv2 statically doesnt give us all the shared lib gives
[11:35] <pmcgowan> sil2100, different issues than the ones in 156?
[11:35] <sil2100> ogra_: yeah, but that would just be gallery, while we had many other apps having the problem
[11:36] <sil2100> pmcgowan: yeah, so it seems now that some applications have problems starting during tests in smoketesting - and as what davmor2 mentioned, those apps seem to launch very slow
[11:36] <ogra_> there are a lot weird qmlscene errors in the notes-app log
[11:36] <sil2100> It seems to have started with 155 (most probably), as 154 had good test results
[11:37] <ogra_> sil2100, and apparmor denies the world ...
[11:37] <ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/580/artifact/clientlogs/notes_app/syslog/*view*/
[11:37] <ogra_> i guess we have our issue there ...
[11:38] <pmcgowan> ogra_, the new apparmor then?
[11:38] <ogra_> well, that only had a minor change in a totally different area
[11:38] <ogra_> not sure how it could cause this
[11:38] <pmcgowan> did ap change?
[11:38] <ogra_> nope
[11:39] <ogra_> and the apparmor change should only allow additional access to the files in /var/lib/extrausers ...
[11:39] <ogra_> (which it apparently does fine, else mediascanner would crash again)
[11:40] <sil2100> Crap
[11:41] <ogra_> jdstrand, any idea about that one ? https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/580/artifact/clientlogs/notes_app/syslog/*view*/
[11:41] <sil2100> But looking at the apparmor upload, it really shouldn't have any negative effect
[11:41] <ogra_> (once you are around)
[11:41] <pmcgowan> what was in the upstart changes
[11:41] <ogra_> upstart (1.13.1-0ubuntu2) utopic; urgency=medium
[11:41] <ogra_>   * Cherry-pick cgmanager text fix from upstream.
[11:41] <ogra_> nothing
[11:42] <ogra_> i mean ... well,if cgmanager would have issues our problems would be bigger (devices wouldnt finish booting)
[11:42] <pmcgowan> ok
[11:50] <olli> interesting
[11:50] <pmcgowan> mdeslaur, can you double check the apparmor changes for us
[11:50] <pmcgowan> or check that log above
[11:50] <mdeslaur> sure, one sec
[11:51] <pmcgowan> thanks
[11:51] <ogra_> well, i tested the apparmor changes for jamie ... but only on a running device ... not with AP tests
[11:51] <ogra_> (to verify the bug was gone)
[11:52] <ogra_> now someone explain to me why this is specific to only one of the test devices
[11:52] <pmcgowan> oh?
[11:52] <ogra_> i mean all app tests run that introspection stuff
[11:52] <pmcgowan> right
[11:52] <ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/mako/157:20140729.2:20140728.1/9355/
[11:52] <ogra_> all tests that ran on the first mako passed fine
[11:53] <ogra_> all that ran on the second one didnt
[11:53] <mdeslaur> ogra_: is there a special apparmor rule for the autopilot stuff?
[11:53]  * mdeslaur has no idea how this works
[11:53] <ogra_> mdeslaur, heh, no clue :)
[11:53] <davmor2> pmcgowan, ogra, sil2100: every apps is taking between 7-10 seconds to open I've opened them all now, worse ones seem to be "web apps, shorts, browser, calendar and Music app" everything else then opens around 7 seconds
[11:53] <sil2100> ogra_: psivaa said it was on 2 devices
[11:53] <pmcgowan> davmor2, whats top say
[11:53] <ogra_> sil2100, well, i'm only talking about the two we see on the dashboard yet
[11:53] <ogra_> once the third one shows up it will likkely get even worse :)
[11:54] <ogra_> davmor2, i cant confirm that on my flo
[11:58] <mdeslaur> ogra_: so, one of the autopilot and/or jenkins scripts is supposed to tell apparmor that this is running in test mode I believe, and that doesn't seem to be happening
[12:00] <ogra_> right, but apparmor was the only bit that got changed here
[12:00] <mdeslaur> ah, I think it's the autopilot-touch package that does it
[12:00]  * mdeslaur pokes more
[12:01]  * ogra_ still doesnt get why we have one device properly passing 
[12:03] <pmcgowan> every thing seems normal to me here
[12:03] <davmor2> pmcgowan: so cpu usage goes off the chart and then it slows right down again once the app is open, Exapmles, open music app 89-96% for qmlscene, upto 67.8% for unity8, mediascanner hit 10-20%, thumbnailer hits 27%
[12:04] <mdeslaur> ogra_: is there a way to see which packages are in the image?
[12:04] <ogra_> mdeslaur, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/utopic-preinstalled-touch-armhf.manifest
[12:04] <pmcgowan> davmor2, that may be expected
[12:05] <ogra_> mdeslaur, and changes are at http://people.canonical.com/~ogra/touch-image-stats/ ... you want to look at 155-157
[12:05] <pmcgowan> startup times seem normally slow to me, not worse
[12:05] <davmor2> pmcgowan: nothing stays high though and I don't seen anything unexpected in the top 10 list
[12:05] <pmcgowan> right
[12:05] <ogra_> dropping letter starts in under 4sec for me here
[12:06] <pmcgowan> ogra_, I assume we got new sdk libs to fix the original issue?
[12:06] <ogra_> filemanager between 4 and 5
[12:06] <ogra_> pmcgowan, which original issue ?
[12:06] <pmcgowan> well I dont know, why dd we get a new sdk libs ;)
[12:07] <ogra_> pmcgowan, because the seeds were updated for udisks2 ... no change in the libs, its is just rebuilt alongside
[12:07] <pmcgowan> ogra_, cool thats what I meant
[12:07] <ogra_> (happends when you rebuild meta to add something to -touch)
[12:09] <pmcgowan> ogra_, so what about the fact tests ran fine in some cases, thats a race, or some diff in the environments
[12:10] <ogra_> rather the latter
[12:11] <ogra_> we got a new initrd in 154 .. i wonder if the kernel partition possibly didnt get updated properly on some devices
[12:11] <mdeslaur> ogra_: what is "phablet-config"?
[12:12] <ogra_> mdeslaur, a tool to adjust certain bits on an image (skip the welvcome wizard ... skip the intro tutorial, make sure the screen stays unlocked)
[12:12] <ogra_> comes from phablet-tools
[12:12] <mdeslaur> ogra_: ok, that's what adds the autopilot rules to apparmor...can we tell if it ran or not?
[12:13] <ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/583/consoleFull has the full console output of the server that ran the test on the phone
[12:14] <ogra_> mdeslaur, which phablet-config command  would do that ?
[12:14]  * ogra_ sees "+ phablet-config autopilot --dbus-probe enable"
[12:19] <pmcgowan> ogra_, did the dashboard results change? I see 69 fails now
[12:19] <ogra_> pmcgowan, yes, as psivaa re-runs tests and they pass it gets updated
[12:20] <pmcgowan> sun spots
[12:20] <ogra_> UITK tests completely failed though
[12:21] <psivaa> ogra_: yeam UITK, was in an infinite look of dragging a coordinate. so it would have hung forever. i had to abort it and rerunning again
[12:25] <psivaa> ogra_: also, we've seen the devices wait here forever in a couple of different devices:
[12:25] <psivaa> 014/07/29 08:22:26 Rebooting into recovery to flash
[12:25] <psivaa> + adb wait-for-device
[12:25] <psivaa> ogra_: in fact 3 devices
[12:25] <mdeslaur> ogra_: where does click_image_tests come from?
[12:27] <davmor2> sil2100: so on the whole I'm happy but those test results look awful
[12:27] <davmor2> lunch brb
[12:32] <ogra_> mdeslaur, looks like from the test server, no idea
[12:32] <ogra_> mdeslaur, for that side better ask psivaa or plars
[12:33] <ogra_> well, click_image_tests seems to be a commmand of jenkins.sh
[12:36] <psivaa> mdeslaur: ogra_: click image tests is to run this script basically to check if the downloaded click packages match that in the archive:
[12:36] <psivaa> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/tests/click_image_tests/check_preinstalled_list/check_preinstalled_list.py
[12:41] <ogra_> sil2100, so looking at flo we seem to have a few unity8 crashers we didnt have before
[12:42] <ogra_> mako has one in sudoku-app
[12:42] <ogra_> and webbrowser seems to crash too during its test
[12:45]  * jdstrand is here
[12:47] <pmcgowan> jdstrand, many dashboard tests were failing with an apparmor denial on introspection
[12:47] <jdstrand> what is the denial
[12:47] <jdstrand> ?
[12:48] <pmcgowan> http://ci.ubuntu.com/smokeng/utopic/touch/mako/157:20140729.2:20140728.1/9355/notes_app/1448978/
[12:48] <pmcgowan> s an example
[12:49] <jdstrand> did the test tool change?
[12:49] <pmcgowan> jdstrand, mdeslaur was checking that things got set up properly
[12:49] <pmcgowan> I dont know, I am told not
[12:49] <mdeslaur> a test was added
[12:49] <ogra_> jdstrand, seemingly nothing relevant changed ... as usual :P
[12:49] <jdstrand> right. looking at the denial, it seems like aa-clickhook didn't get run to add the autopilot rule
[12:50] <mdeslaur> and that test makes adb-shell 'aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules' get run
[12:50] <jdstrand> the apparmor upload should not have caused this
[12:50] <ogra_> yeah, very unlikely
[12:50] <mdeslaur> nah, it's not caused by the apparmor upload
[12:51] <mdeslaur> jdstrand: I was comparing https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/583/consoleFull with https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/572/consoleFull
[12:51] <mdeslaur> but didn't see anything relevant beside the fact that there's a new test that makes aa-clickhook get called earlier
[12:52] <jdstrand> interesting
[12:53] <jdstrand> is the click getting installed after the aa-clickhook call?
[12:53] <mdeslaur> but I couldn't find where it was called in 572, or what calls it
[12:53] <jdstrand> this seems like a test tool issue
[13:01] <jdstrand> 572 doesn't have aa-clickhook at all, but 583 does
[13:01] <jdstrand> something is different with the test runner. whoever made that change needs to look at this
[13:02] <jdstrand> pmcgowan: ^
[13:02] <jdstrand> pmcgowan: is 583 the first to fail?
[13:02] <pmcgowan> jdstrand, who owns that?
[13:02] <pmcgowan> jdstrand, the last two builds couldnt be tested, so yes, 157 is first since 154
[13:05] <jdstrand> let me diff the consoleText between the two
[13:07] <jdstrand> mdeslaur: how did you pick 572?
[13:08] <mdeslaur> jdstrand: it looked like the previous one that passed
[13:08] <jdstrand> 572 is 300K and 583 is almost 10M
[13:08]  * jdstrand keeps looking
[13:08] <pmcgowan> do you know which build corresponds to 572?
[13:09] <mdeslaur> (I looked here: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/)
[13:10] <mdeslaur> jdstrand: perhaps 582 would be sufficient, since the aa failures aren't in that one
[13:10] <jdstrand> how do I map http://ci.ubuntu.com/smokeng/utopic/touch/mako/154:20140728:20140725.1/9323/ to a consoleFull?
[13:11] <jdstrand> nm
[13:11] <jdstrand> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/568/consoleFull
[13:16] <jdstrand> 582 was started by hand
[13:16] <jdstrand> 568 has: Started by build flow utopic-touch-mako-smoke-master#164
[13:16] <jdstrand> 582 has: Started by user Parameswaran Sivatharman
[13:17] <jdstrand> well, it looks like it was started by hand
[13:17] <pmcgowan> psivaa, ^^
[13:17] <pmcgowan> jdstrand, you think thats relevant?
[13:17] <sil2100> Sorry, just back from lunch
[13:17] <jdstrand> 568s log is 1.5M, 582 is almost 10
[13:18] <jdstrand> I'm trying to compare apples to apples in my consoleText diff
[13:18] <psivaa> jdstrand: curious how it'd impact
[13:18] <jdstrand> pmcgowan: is http://ci.ubuntu.com/smokeng/utopic/touch/mako/157:20140729.2:20140728.1/9355/ what people are worried about?
[13:19] <psivaa> the -master job purely does the trigger which i did manually
[13:19] <pmcgowan> jdstrand, yes
[13:19] <jdstrand> psivaa: I don't know. did a new infrastructure, tool, runner, something get pushed out recently?
[13:20] <psivaa> jdstrand: not that i know of. probably plars knows?
[13:21] <jdstrand> (fyi, I referenced 582, but I actually meant 583 the whole time, which corresponds with http://ci.ubuntu.com/smokeng/utopic/touch/mako/157:20140729.2:20140728.1/9355/)
[13:23] <psivaa> jdstrand: the above link contains results from 579 to 584 jenkins jobs.
[13:23] <balloons> fginther, any luck with https://code.launchpad.net/~fginther/ubuntu-test-cases/add-reminders/+merge/226281?
[13:24] <psivaa> jdstrand: you'd need to click each app results and follow the links to see the actual jenkins job corresponding to a particular app test
[13:26] <fginther> balloons, yes. I was able to get 14 passing autopilot tests
[13:27] <balloons> fginther, awesome :-) So it's ready for the dash then?
[13:28] <fginther> balloons, yes, the tests should be ready with your MP (I even tested with a .click based on your MP). I need to do a little more cleanup of my branch and get it reviewed
[13:28] <fginther> hopefully will have that ready by EOD
[13:29] <pmcgowan> psivaa, who else can assist in debugging this?
[13:30] <psivaa> pmcgowan: what information do you want to know specifically
[13:31] <plars> psivaa: what's the issue?
[13:32] <psivaa> plars: jdstrand was asking 'did a new infrastructure, tool, runner, something get pushed out recently?'
[13:32] <plars> psivaa: but what's the problem you are seeing?
[13:32] <psivaa> plars: look at the dashboard
[13:33] <plars> psivaa: we made a change to the channel being tested, from utopic-proposed to devel-proposed, which is an alias. That happened last Friday
[13:33] <plars> psivaa: I looked last night and 155/156 were clearly broken
[13:33] <pmcgowan> yes those builds were doa
[13:34] <pmcgowan> but 157 is "good" but not passing
[13:34] <plars> psivaa: 157 seems to have had a device die during uitk tests, and lots of failures on notes and gallery which appear to be new
[13:35] <psivaa> plars: right, thats the issue. i aborted the uitk one first time since it had an infinitely repetitive step
[13:35] <pmcgowan> psivaa, have we rerun the notes or gallery tests? is that a kosher part of the process?
[13:37] <davmor2> plars: 155 was a broken image didn't boot as such
[13:37] <psivaa> pmcgowan: yes, the results showing in the dashboard for gallery and notes are from the second run. the first run also had the same filures
[13:37] <pmcgowan> interesting
[13:38] <psivaa> pmcgowan: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/580/#showFailuresLink is the first set
[13:38] <psivaa> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/583/#showFailuresLink is the second set
[13:38] <plars> pmcgowan: absolutely, but we should keep an eye on it even if it starts to pass again. It might be good for someone from QA with deeper autopilot knowledge to take a look and see what autopilot thinks went wrong there.
[13:38] <plars> psivaa: ah, so it already failed twice?
[13:38] <psivaa> plars: yes
[13:39] <plars> :(
[13:39] <plars> probably a legitimate failure then
[13:39] <plars> let me see if I can reproduce locally
[13:39] <psivaa> first one on mako-14 and the second one on mako-06
[13:40] <plars> psivaa: oh, btw, did you see that I added those 3 extra instrumented makos last night? :)
[13:40] <ogra_> plars, we have two devices out of three misbehave in 157
[13:40] <plars> ogra_: I saw one of them during the uitk tests, but I haven't had time to look seriously at the other results yet. Where was the other?
[13:41] <ogra_> and the two that fail have weird AA denials
[13:41] <plars> I assume it was before one of the reruns that psivaa did already?
[13:41] <plars> ogra_: hmm, did something change with aa that we need to account for in the device provisioning?
[13:42] <psivaa> plars: yes, i've had a few reruns. and the issue appeared afterwords too.
[13:42] <jdstrand> plars: no
[13:42] <ogra_> plars, right and the dashboard only showed the successfull one for quite a while ... i think mako-06 is definitely borked
[13:42] <psivaa> plars: the instrumented ones are now then 12,13,14 & 15?
 we got a new initrd in 154 .. i wonder if the kernel partition possibly didnt get updated properly on some devices
[13:42] <ogra_> oh, right
[13:42] <jdstrand> plars: the autopilot apparmor rules are either not being applied or being unapplied
[13:42] <ogra_> but all devices get installed with --bootstrap
[13:42] <plars> ogra_: mako-06 has been problematic, I'll pull it for now so we don't get reruns on it
[13:43] <ogra_> theoretically they *should* get updated
[13:43] <plars> I've not seen it fail like that before
[13:43] <ogra_> yeah
[13:43] <plars> jdstrand: any idea how on earth that could happen? Could a bad device really have such an effect?
[13:43] <jdstrand> plars: there was an apparmor update, but it had no code changes and was extremely minimal
[13:43] <plars> I'd expect it to just die/crash rather than strange things like that
[13:44] <jdstrand> plars: well, I am comparing the test output from 568 and 583-- 568 is 1.5M and 583 is nearly 10M
[13:44] <jdstrand> plars: (consoleText)
[13:45] <plars> jdstrand: well I think psivaa said one of them was caught in a loop and he killed the job after a while
[13:45] <jdstrand> that is why I asked about test infrastructure
[13:45] <plars> jdstrand: only change on our side happened over the weekend, and it was the announcement I made to the ML. We added a new channel, and changed one of the channels to point at the devel-proposed alias rather than the utopic-proposed channel
[13:45] <plars> (which is the same image)
[13:46] <jdstrand> I need to be able to compare 568 with something that is a comparable but failing run if I am going to be able to help diagnose
[13:46] <plars> there's still some reporting stuff we need to clean up there, but that's trivial. Runs have happened successfully since those changes, and nothing clearly would have had an impact on this
[13:46] <psivaa> jdstrand: if you see the console in 583, we see those quite a lot of errors/ failures. that could add to the log size?
[13:47] <jdstrand> I don't know-- I got dragged in to this cause there were apparmor denials. there are apparmor denials because the autopilot apparmor rules aren't being applied correctly
[13:47] <psivaa> jdstrand: and 568 has only 2 failiures and that too is with image 154. not sure if you could compare those two tbh :)
[13:47] <bfiller> sil2100: can I have a silo for line 33 please?
[13:47] <jdstrand> that is the extent of what I can say about this atm (sorry I'm not more familiar with the test infrastructure)
[13:48] <bfiller> sil2100: I mean line 32 :)
[13:48] <sil2100> bfiller: sadly, we're critically low on silos right now, we need to have 1 free one in case of a blocker fix ;)
[13:48] <pmcgowan> sil2100, we can give up 18 for now
[13:49] <bfiller> it's fine, I can wait until one frees up
[13:49] <jdstrand> psivaa: if I had two test runs that were more alike, I might be able to help more
[13:50] <psivaa> jdstrand: more alike but one with the latest image?
[13:51] <psivaa> if that's the case, not sure how we match that
[13:51] <psivaa> plars: ^ any idea?
[13:51] <jdstrand> psivaa: I was told that 583 had some sort of looping issue with it. 568 did not. that seems to indicate that there is something wrong with 583 results and the looping issue should be fixed first
[13:52] <jdstrand> psivaa: once that is fixed, we should have results that we can compare
[13:53] <plars> psivaa: I'm trying gallery_app by itself locally right now
[13:53] <psivaa> jdstrand: 583 did not have the looping issue
[13:53] <jdstrand> psivaa: ok. why is its consoleText almost 10M and 568s is 1.5M?
[13:54] <jdstrand> I need to understand that change
[13:54] <jdstrand> (if I am supposed to help)
[13:54] <psivaa> jdstrand: that's because the number of failures is higher in that
[13:55] <jdstrand> I'll keep looking at it then. but it is clear that the autopilot apparmor rules are not being applied or are being unapplied at some point
[13:56] <jdstrand> you are *sure* nothing changed in the tools to change the ordering of when clicks are installed, etc?
[13:57] <psivaa> jdstrand: we dint deliberately change that. let me double check if the are installed in the same order with 568
[13:57] <jdstrand> psivaa: are these things using the new click autopkgtest support?
[13:59] <psivaa> jdstrand: i dont know what 'the new click autopkgtest support' means.. sorry. plars do you know?
[13:59]  * jdstrand wonders if this is related to the discussion in bug #1337253
[14:00] <plars> psivaa: I think that's the stuff fginther was working on so that reminders could work, and no it's not landed yet. I was going to try to take a look soon, but the mp is on hold
[14:00] <sil2100> pmcgowan: ok, let's do that then, let me free up silo 18
[14:10] <psivaa> jdstrand: i just diff'ed the initial setup bits of the phones on 583 and 568. dont see any difference
[14:11] <jdstrand> psivaa: I see a difference in the output: http://paste.ubuntu.com/7895341/
[14:12] <jdstrand> psivaa: '<' is 568 and '>' is 583
[14:12] <jdstrand> psivaa: seems the provisioning code changed?
[14:13]  * jdstrand checks when 'reprovisioning device with' string happens
[14:13] <psivaa> jdstrand: that's the part of the stuff used to see if the device already has that image. i dont think it's relevant here
[14:13] <psivaa> right, reprovisioning happens when a job is rerun
[14:13] <jdstrand> that is all before aa-clickhook
[14:13]  * jdstrand keeps looking
[14:15] <psivaa> jdstrand: the bits after '+ log 'FLASHING DEVICE'
[14:15] <psivaa> ' id not that different
[14:15] <psivaa> *is not that different
[14:17] <popey> cprov: can someone help me with http://s-jenkins.ubuntu-ci:8080/job/weather-app-click/lastBuild/console ?
[14:17] <popey> weather app is repeatedly failing to build
[14:18] <popey> balloons: can you pelase push the core apps clicks to the store?
[14:18] <balloons> popey, all of them?
[14:18] <cprov> popey: in a minute and can gather fginther too.
[14:19] <popey> yup, although skip weather for now as it's failing to build
[14:19] <popey> thanks
[14:21] <fginther> cprov, popey looking
[14:21] <popey> ta
[14:25] <pmcgowan> plars, any luck?
[14:25] <jdstrand> psivaa: fyi, it would be nice if the 'Search for [<list of clicks>]' was sorted
[14:26] <fginther> popey, cprov, I found the problem, applied a quick fix and rebuilt the job. I'll also start work on a more permanent fix. There is difference in the jenkins user account on the failing machine that wasn't taken into account in the job
[14:26] <jdstrand> psivaa: pull: /var/crash/.lock -> /var/lib/jenkins/slaves/mako-NN/workspace/utopic-touch-mako-smoke-daily/clientlogs/click_image_tests/.lock is missing in 583. what is that about?
[14:27] <jdstrand> oh I see
[14:27] <jdstrand> hrmm
[14:27] <jdstrand> that is after the tests are run
[14:27] <psivaa> yes, during results archiving
[14:28] <jdstrand> psivaa: the only thing I can think of is the provisioning is different
[14:29] <psivaa> jdstrand: curious as to how?
[14:29] <plars> pmcgowan: psivaa: the gallery_app run locally just finished (needed to provision)
[14:29] <plars> 45 passes, 0 failures
[14:29] <psivaa> grrrrr
[14:29] <pmcgowan> yeah of course
[14:29] <jdstrand> psivaa: I know that there were changes made to precompile apparmor policy. aa-clickhook should be getting run way after that, so I'm not sure it is relevant
[14:29] <plars> it could be something odd caused by something before it
[14:29] <sil2100> :|
[14:29] <plars> but it's nothing in the scripts, I went through the same provisioning process locally that we do in the lab
[14:29] <plars> pmcgowan: I'm still digging
[14:29] <jdstrand> ok, so plars just provisioned the same way psivaa did, presumably
[14:30] <plars> I'm also trying notes_app right now, so at least we'll have results on those two
[14:30] <plars> jdstrand: exactly
[14:34] <fginther> popey, http://s-jenkins.ubuntu-ci:8080/job/weather-app-click/236/ passed
[14:36] <jdstrand> this should be the differences between 568 and 583 before aa-clickhook is run: http://paste.ubuntu.com/7895519/
[14:39] <jdstrand> plars: do you know if the code in comment #8 of bug #1337253 is being used now?
[14:40] <thostr_> sil2100: can I get a silo for line 33?
[14:41] <plars> jdstrand: probably not, we don't use autopkgtest, but let me look into it
[14:41] <jdstrand> I don't see any adt strings in the log
[14:41] <jdstrand> plars: ^
[14:42] <sil2100> thostr_: sadly, we're currently low on silos, with only one silo free right now... we hope to have more free if we resolve the traincon situation
[14:42] <jdstrand> plars: could be there isn't enough information to know why the autopilot rules aren't in place
[14:43] <thostr_> sil2100: ci sheet says we have two silos :)
[14:43] <sil2100> thostr_: bah, it's not updated yet ;p
[14:43] <sil2100> thostr_: in reality it should be 1
[14:43] <thostr_> sil2100: ack
[14:44]  * ogra_ considers if getting a vendor tray and sell silos on teh grey market  is a good business model :) 
[14:45] <sil2100> ;p
[14:46] <rsalveti> let me validate the emulator now
[14:47] <sil2100> I guess that if we at least confirm that both notes and gallery pass when ran locally and davmor2 gives a final +1 on dogfooding, let's maybe consider promoting the image anyway
[14:47] <sil2100> (if emulator boots as well)
[14:48] <ogra_> sil2100, well, UITK doesnt run either
[14:48] <rsalveti> emulator first boot doesn't get us to unity8
[14:48] <rsalveti> =\
[14:48] <plars> jdstrand: it does look like we do "aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules" This is also done by phablet-config autopilot
[14:48] <sil2100> Aw come on
[14:48] <ogra_> we are missing about 300 tests
[14:48] <plars> jdstrand: It could be that it's run more than once though, would that cause any problem?
[14:49] <plars> ogra_, sil2100: please standby, I'm rerunning a lot of stuff right now both locally and in the lab
[14:49] <ogra_> yeah
[14:49] <ogra_> just telling sil2100 where we stand
[14:49] <sil2100> Ok
[14:49] <ogra_> didnt mean to complain or moan :)
[14:49] <sil2100> ogra_: ah, right, I didn't notice that it only had 5 tests ran ;p
[14:49] <ogra_> I#m doing that enough in other channels
[14:49] <sil2100> But it was yellow!
[14:50] <sil2100> 80%!
[14:50] <ogra_> shipit !
[14:50] <plars> ogra_: I didn't take it that way, I just want to make sure you know I'm aware and working on it. :) It's my focus right now
[14:50] <ogra_> :)
[14:50] <ogra_> thanks
[14:50] <jdstrand> plars: if it run more than once with the proper --include: no, it shouldn't matter. (though, if you think it is run multiple times at the same time, there could be a problem)
[14:50] <plars> jdstrand: it wouldn't happen in parallel or anything, no
[14:51] <rsalveti> sil2100: ogra_: I get the wizard at least on the emulator, but not unity8 =\
[14:51] <rsalveti> not even after a reboot
[14:51] <plars> jdstrand: the only parallelization is across devices
[14:51] <jdstrand> plars: if aa-clickhook is run without the --include, then that would undo the rule. aa-clickhook is run on click install, so if a click gets installed later, that could undo the changes
[14:51] <sil2100> rsalveti: hmm... then maybe the UITK -gles bits weren't enough?
[14:51] <ogra_> rsalveti, bah
[14:52] <rsalveti> yeah, not sure, still investigating
[14:52] <sil2100> Thanks
[14:52]  * sil2100 is sad
[14:52] <jdstrand> plars: put more simply-- aa-clickhook must always be run after click packages are installed (unless you are going to modify your code to do what newer autopkgtest is doing)
[14:53] <jdstrand> plars: aa-clickhook -f --include=... that is
[14:56] <rsalveti> ogra_: sil2100: worked fine after destroying and creating it again O_o
[14:56] <rsalveti> not a single crash this time
[14:56] <ogra_> what did you do the first time, upgrade from an older one ?
[14:56] <rsalveti> no, clean image
[14:56] <rsalveti> same one
[14:56] <ogra_> weird
[14:56] <rsalveti> but I had a bunch of things crashing after the wizard crashed
[14:57] <sil2100> uh
[14:57] <rsalveti> swipe is working, can open apps
[14:57] <rsalveti> seems ok
[14:57] <pmcgowan> bzoltan had validated it prior to the image build fwiw
[14:57] <rsalveti> let me try to recreate the broken image
[14:58] <rsalveti> right
[14:58] <rsalveti> I think bad things happen when the wizard crashes
[14:58] <rsalveti> will test it more
[14:59] <davmor2> sil2100: oh yeah what it is with the wizard always crashing?  I'm assuming it is safe to ignore and it's just because it got closed
[15:05] <brendand> sil2100, eventful start to the week, huh?
[15:08] <sil2100> brendand: yeah... hey! You're not on holidays? ;)
[15:08] <brendand> sil2100, i am
[15:09] <brendand> sil2100, on holidays until tomorrow
[15:09] <sil2100> davmor2: well, not sure about that, but with the TRAINCON-0 overextending so much, I don't feel like blocking on smaller things ;)
[15:09] <brendand> sil2100, what happened to the dashboard :/
[15:09] <sil2100> brendand: then don't look at our image situation! It will only stress you out ;)
[15:09] <brendand> sil2100, what did you DO!
[15:10] <sil2100> I don't knooow!
[15:10] <sil2100> It was popey !
[15:10] <sil2100> #blamepopey
[15:10] <davmor2> brendand: blame popey tm
[15:11] <popey> \o/
[15:17] <brendand> sil2100, but seriously - is something fundamental causing all those failures, or do all of those applications have different issues?
[15:18] <ogra_> something fundamental
[15:18] <ogra_> it mnifests as apparmor denial of autopilot introspection
[15:19] <ogra_> but there were no changes in either ... which makes tracking it super hard
[15:19] <ogra_> s/tracking/tracing/
[15:27] <plars> ogra_: sil2100: psivaa: brendand: ok, we have fewer failures on this rerun of gallery/notes, uitk tests in progress now
[15:28] <ogra_> cool ?
[15:28]  * ogra_ wonders what to say about "fewer failures" ... means there are still some i guess
[15:30] <sil2100> 4 for notes and 1 for gallery, hmmm
[15:30] <psivaa> plars: could be weird issues in the devices then?
[15:31] <ogra_> out of the blue ?
[15:31] <psivaa> i still see ' 173.094185] type=1400 audit(1406646860.290:123): apparmor="DENIED" operation="mkdir"' message in notes app failed ones
[15:31] <ogra_> i wonder if we can somehow find out if kernel and initrd are up to date in the boot partition
[15:31] <plars> psivaa: well, we're still getting that kind of stuff, yeah
[15:32] <plars> psivaa: before that, we ran phablet-config autopilot --dbus-probe enable
[15:32] <plars> which in turn, runs 'aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules'
[15:33] <plars> it also ran before the gallery_app test
[15:33] <ogra_> plars, can you check if all devices run "3.4.0-5-mako #32-Ubuntu" ? (uname -a should suffice)
[15:34] <ogra_> that should be the latest kernel
[15:34] <plars> ogra_: the one that ran this test is for sure
[15:34] <ogra_> ok
[15:34] <plars> jdstrand: does http://paste.ubuntu.com/7895931/ provide anything useful to you?
[15:37] <ogra_> jdstrand, oh, one thing i noticed, we dont have /lib/modules filled anymore ... shouldnt there be some firewalling ?
[15:37] <jdstrand> ogra_: the ufw tests should fail if there is an issue
[15:37] <jdstrand> ogra_: I'm guessing they are compiled in if they aren't failing?
[15:39] <jdstrand> plars: that looks all normal. what is happening is that /var/lib/apparmor/profiles/click_com.ubuntu.notes_notes_1.4.275 doesn't have the autopilot rules in it in 583
[15:40]  * jdstrand is assuming
[15:40] <ogra_> jdstrand, hmm, i thought they were supposed to be modules
[15:40] <ogra_> rsalveti, do you know ? seems /lib/modules is empty
[15:40] <plars> jdstrand: what about 585?
[15:40] <rsalveti> it should be a link afaik
[15:41] <plars> jdstrand: from that device, I don't see anything under /var/lib/apparmor/profiles/ - should I?
[15:42] <rsalveti> ogra_: /lib/modules/3.4.0-5-mako for mako at least
[15:42] <ogra_> with content ?
[15:42] <plars> jdstrand: oh wait, sorry, wrong console
[15:42] <plars> I do have stuff there
[15:42] <plars> phew
[15:42] <rsalveti> ogra_: mako, yes
[15:42] <ogra_> ok
[15:42] <ogra_> (i only have aan old image around here)
[15:43] <rsalveti> well, should always be the case
[15:43] <rsalveti> actually, this is not a link
[15:43] <rsalveti> it's bind-mounted
[15:43] <ogra_> well, i expected that lsmod shows some modules loaded
[15:43] <plars> jdstrand: http://paste.ubuntu.com/7895991/ is what I have in it after run 585
[15:43] <ogra_> yeah, i remember the code
[15:44] <rsalveti> ogra_: right, we might not necessarily be using any module
[15:44] <rsalveti> but that's sort of expected
[15:44] <ogra_> well, i was expecting some UFW lockdown
[15:46] <rsalveti> ogra_: probably nobody requiring them
[15:46] <rsalveti> was able to load modules here just fine
[15:46] <rsalveti> modprobe lttng-tracer
[15:46] <rsalveti> got a bunch of modules after that
[15:46] <ogra_> ah, yeah, works here too
[15:52] <pete-woods> fginther: hi, could you direct me to any documentation / explain how I to integrate click building a LP package with jenkins?
[15:53] <fginther> pete-woods, one moment please
[15:53] <jdstrand> plars: yep, it has the correct line: #include "/usr/share/autopilot-touch/apparmor/click.rules"
[15:53] <jdstrand> plars: did that run pass or fail?
[15:54] <plars> jdstrand: it didn't fail completely, but it had some aa related failures on notes app
[15:54] <plars> jdstrand: http://q-jenkins.ubuntu-ci:8080/job/utopic-touch-mako-smoke-daily/585/consoleFull
[15:56] <plars> ogra_, sil2100, psivaa: ok, we have passing uitk tests
[15:56] <sil2100> \o/
[15:56] <ogra_> yay
[15:56] <ogra_> at the third attempt though
[15:56]  * ogra_ hopes that persists :)
[15:56] <plars> http://ci.ubuntu.com/smokeng/utopic/touch/mako/157:20140729.2:20140728.1/9355/ looks much improved now, and I've disabled a couple of devices to see if they are causing problems
[15:57] <bzoltan1> sil2100: rsalveti: We need to update the QtCreator package (not the plugins I am releasing often, but the big one) from the packaging trunk -> https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtcreator  Mirv is not around, so I will need a hand to push it.
[15:57] <sil2100> plars, jdstrand: ok, since I got a bit out-of-date on the state, but do we have any clues on what's going on the dashboard side with the apparmor denials during ap tests?
[15:57] <plars> and jdstrand and I still need to work through what's going on with this aa-clickhook stuff
[15:57] <plars> sil2100: not yet, we're working on that now
[15:57] <bzoltan1> sil2100: rsalveti: I do not remember if the QtC package is on the CI Train or not
[15:58]  * ogra_ thinks this is just fallout of something else we havent identified yet 
[15:58] <sil2100> bzoltan1: you want to do it through the train, yes?
[15:58] <sil2100> bzoltan1: let's check the version then ;)
[15:58] <bzoltan1> sil2100: sure, that is the real thing, right?
[15:59] <bzoltan1> sil2100:  the trunk is up to date and we have bumped the version too
[15:59] <plars> one thing interesting... I can reproduce the messages like Jul 29 15:44:28 ubuntu-phablet kernel: [  289.352388] type=1400 audit(1406648668.834:84): apparmor="DENIED" operation="mkdir" profile="com.ubuntu.notes_notes_1.4.275" name="/home/phablet/.local/share/notes-app/" pid=5394 comm="qmlscene" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
[15:59] <plars> at home
[15:59] <plars> but I don't see the tests fail when it happens
[15:59] <sil2100> bzoltan1: ok, so it seems Timo didn't use the train for it it seems, I'm double checking one thing though
[16:00] <sil2100> I think he was releasing directly to the archive
[16:01] <jdstrand> plars: that is a different issue
[16:02] <bzoltan1> sil2100:  not impossible
[16:02] <jdstrand> plars: in that case, it seems like the applicationName in the notes-app qml is wrong. /home/phablet/.local/share/notes-app/ is wrong. it should be /home/phablet/.local/share/com.ubuntu.notes
[16:02] <rsalveti> bzoltan1: is mirv on vacation again?
[16:02] <bzoltan1> sil2100: I do not think that our CI train can merge to that project
[16:02] <jdstrand> plars: if it isn't the QML, it is something else in the app
[16:02] <bzoltan1> rsalveti:  yes
[16:03] <sil2100> rsalveti: yes, one more week
[16:03] <rsalveti> lol, wonder how many weeks he got
[16:03] <rsalveti> maybe he's special because he's finnish
[16:03] <rsalveti> summer and so on
[16:04] <rsalveti> bzoltan1: please create the mr and ping with with the address
[16:04] <rsalveti> I can take a look
[16:04] <psivaa> plars: wow, it's a great news. hope this stays as it is :)
[16:05] <bzoltan1> rsalveti:  Is it possible to land a totally empty MR? I mean even without touching the changelog.
[16:05] <plars> psivaa: there's still more to sort out, but we have better results.. still not what they should be though
[16:05] <rsalveti> sil2100: ogra_: so, I tried the emulator a bunch more times, and it's getting in a broken state from time to time
[16:05] <bzoltan1> rsalveti: in Finland everybody has about 25 days holiday, but Finns  like to to take them in big blocks :)
[16:06] <rsalveti> still to be investigated, but it's better than the last promoted one
[16:06] <ogra_> rsalveti, promotable with a note in the landing mail  ?
[16:06] <rsalveti> so I'd say this shouldn't be blocking trainco anymore
[16:06] <ogra_> ah, you were faster
[16:06] <ogra_> yeah
[16:06] <pmcgowan> +1
[16:06] <ogra_> we now just need the smoke tests to work
[16:07] <jdstrand> plars: in other words-- that is a bona-fide bug with notes-app
[16:08] <jdstrand> psivaa: I would be curious what the results would be if you did a test run now in the same manner you did before
[16:09] <jdstrand> plars: oh, you said you disabled a device-- is it possible that the device had problems with either the filesystem or the hardware such that it couldn't write out files? think is that maybe the files didn't get updated even though aa-clickhook --include was run
[16:10] <plars> jdstrand: that wasn't on this device
[16:10] <jdstrand> s/think is/thinking/
[16:10] <psivaa> jdstrand: i guess plars ran the same way as i did, except on the devices that failed me :)
[16:10] <plars> jdstrand: if that's the case, then the problem is on a lot of devices
[16:10] <jdstrand> plars: I know. this one passed. the other didn't. didn't you disable the device that didn't pass?
[16:10] <popey> balloons: any problem uploading the clicks?
[16:10] <plars> jdstrand: this one didn't pass completely though
[16:10] <plars> jdstrand: we still got 5 notes failures which we didn't expect to see
[16:11] <plars> jdstrand: and a whole lot of these apparmor denied messages
[16:11] <plars> jdstrand: I also see that at home
[16:11] <jdstrand> plars: right, but the reason I am involved is cause of the autopilot apparmor rules. that wasn't an issue on this run (at least not for notes-app)
[16:11] <plars> jdstrand: except it passes
[16:11] <jdstrand> plars: you are talking about the mkdir denial?
[16:11] <plars> jdstrand: on 585?
[16:11] <plars> jdstrand: yes
[16:11] <jdstrand> plars: right, I addressed that. the mkdir denial is a bug in notes-app
[16:12] <fginther> pete-woods, sorry about that, was in the middle of something else. Generally, we just create the jenkins jobs as needed per project (we don't have a lot of these yet). What package is this for?
[16:12] <plars> ok
[16:12] <plars> jdstrand: didn't understand that, thanks
[16:12] <jdstrand> plars: it was only the autopilot apparmor dbus denials had to do with aa-clickhook
[16:14] <ogra_> [16:14] <plars> \o/
[16:14] <pmcgowan> nice!
[16:14] <cjwatson> bzoltan1: empty MR> yes, although you have to use "force rebuild" in the build job parameters
[16:15] <pmcgowan> olli, jdstrand^^
[16:15] <jdstrand> nice!
[16:15] <pmcgowan> thanks plars, psivaa
[16:15] <jdstrand> plars: so, I was just asking if there was a hardware issue with the device that ran 583.
[16:15] <cjwatson> oh, brilliant
[16:17] <tvoss> hah, we are moving again?
[16:17] <jdstrand> plars: if you think that was a possible cause. if you rule that out-- there is something that is undoing the aa-clickhook changes. would probably need some instrumenting in the test infrastructure to figure it out
[16:17] <plars> jdstrand: I don't see anywhere that it could be undoing the aa-clickhook changes, but I think you were suggesting earlier that they looked like they were reverted?
[16:18] <kgunn> sil2100: is there a way to check on ubuntu-system-settings in silo6....i think i saw some other silos y'day....but now gone? (landed?)
[16:18] <kgunn> just need to check to see if we need to rebuild?
[16:18] <jdstrand> plars: if you are going to instrument it, I would suggest grepping for the '#include' line I mentioned earlier after aa-clickhook, and then grepping for it again right before the autopilot tests are run
[16:18] <sil2100> kgunn: after the meeting I'll try to check that :)
[16:18] <kgunn> sil2100: ta, it was the only other thing that i was worried/keeping an eye on
[16:19] <kgunn> tvoss: its happening...train chugging away from station
[16:19] <pmcgowan> kgunn, you ever landing that silo?
[16:19] <pmcgowan> ;)
[16:19] <jdstrand> plars: actually, could jest do 'grep "# injected via click hook" <path to profile>' || failtest
[16:19] <kgunn> pmcgowan: don't jinx it
[16:19] <jdstrand> just*
[16:20] <jdstrand> plars: ie, if we check that the autopilot rules are correctly added, we can fail the whole thing if they are not
[16:20] <tvoss> kgunn, gotta say that in German: so schön, dass Emma wieder fit ist :)
[16:20] <tvoss> ogra_, ^
[16:20] <ogra_> :D
[16:21] <jdstrand> plars: but the check needs to be done right before the tests are run, and ideally, additionally after aa-clickhook --include is run
[16:22] <plars> jdstrand: I'll try to take a look at that on some manual ones at least - did you have a link for somewhere you saw the aa stuff getting reverted though?
[16:22] <jdstrand> plars: for i in /var/lib/apparmor/profiles/click_* ; do grep -q "# injected via click hook" $i || failtest '$i' does not have autopilot rules ; done
[16:22] <jdstrand> plars: nope. I couldn't find it in the diff
[16:23] <jdstrand> plars: something akin to that ^ may at least save time for next time
[16:23] <sil2100> kgunn: give me a minute and I'll check that for you
[16:23]  * sil2100 has firefox problems
[16:23] <jdstrand> and may provide clues for next time
[16:28] <olli> sil2100, cjwatson, pmcgowan, ogra_, jdstrand, rsalveti, plars, psivaa-bbl, everyone that I forgot... THX!
[16:35] <sil2100> kgunn: ok, just checked and it seems that no new ubuntu-system-settings was released, so the version in silo 006 seems good!
[16:37] <kgunn> sil2100: woohoo!
[16:37] <kgunn> sil2100: its all good to go then
[16:38] <robru> sil2100, hey hey hey what's the word?
[16:39] <sil2100> robru: hey! So!
[16:39] <sil2100> robru: we promoted o/
[16:39] <sil2100> robru: not a perfect image, but promoted
[16:39] <robru> sil2100, great!
[16:39] <sil2100> robru: anyway, could you publish 006 once you have some time?
[16:39] <ToyKeeper> Did kgunn's silo land too?
[16:39] <kgunn> ToyKeeper: not yet, but its 1st in line
[16:39] <robru> sil2100, of course!
[16:40] <robru> like, right now
[16:40] <sil2100> robru: if you can, kick a new image once 006 is in the archive, since this will be a good image for a second promotion ;)
[16:40] <robru> oh, 6 is building
[16:40] <kgunn> @ good image for a second promotion, yes it will my friends....yes it will
[16:40] <kgunn> robru: ah! what?
[16:40] <kgunn> lemme check
[16:41] <sil2100> robru: since silo 006 seems like the golden bullet here, fixing at least two of our issues ;)
[16:41] <kgunn> arrg...yeah, an update sanity build robru
[16:41] <kgunn> once its done, its good to go
[16:41] <kgunn> robru: just making all the gles twins happy
[16:44] <kgunn> now its ready
[16:45] <kgunn> robru don't quit now
[16:46] <kgunn> ToyKeeper: davmor2 ^ anyone want to show some qtcomp love ?
[16:46] <sil2100> ;)
[16:47] <sil2100> robru's in a hotel right now
[16:47] <sil2100> Anyway, kgunn are you triple sure that I can press 'publish' on 006?
[16:47] <sil2100> If yes, I can press it!
[16:48] <sil2100> Oh, and there's robru back
[16:48] <robru> weird, stupid hotel wifi is crap
[16:48] <robru> sil2100, kgunn: i guess i missed some messages from you guys
[16:48] <robru> just wondering about gles in silo 6
[16:50]  * olli holds his breath
[16:51] <ToyKeeper> kgunn: If so, it'll be a bit...  I need to relocate before I can start anything.
[16:52] <sil2100> kgunn: ^ :) ?
[16:54] <davmor2> kgunn: I spent spent Monday testing it.  It was fine unless it has been massively updated since then?
[16:55] <davmor2> I can give it a blitz testing now though
[17:02] <bzoltan1> cjwatson: rsalveti: I have added this to the line 40 -> https://code.launchpad.net/~bzoltan/kubuntu-packaging/enable_ubuntu_devices/+merge/228725 The best would be to get a silo for it and I will add the rest of the plugins one by one.
[17:04] <robru> sil2100, kgunn: so nobody answered my question about gles in silo 6. is it tested?
[17:04] <sil2100> kgunn: ^ ?
[17:05] <robru> kgunn, sil2100: oh sorry, i just noticed it's a no-change rebuild, nevermind.
[17:05] <robru> kgunn, sil2100: ok, publishing silo 6 then!
[17:08] <Saviq> mterry, https://ci-train.ubuntu.com/job/landing-006-2-publish/36/
[17:08] <Saviq> robru, mterry will have a look at ↑
[17:08] <robru> Saviq, you can summon him just like that, can you?
[17:09] <kgunn> robru: sil2100 thanks (sorry, snuck to the kitchen for a moment)
[17:09] <Saviq> robru, he's sitting opposite, so yes
[17:10]  * tvoss thinks we should have fancy videos of packages landing in the archive
[17:10] <robru> mterry, well, it's a big one, good luck!
[17:15] <robru> sil2100, how was your first day with the new spreadsheet? really nice, huh? ;-)
[17:15] <sil2100> robru: not bad! Although I didn't have too many occasions to use it!
[17:15] <sil2100> Traincon you know
[17:15] <robru> sil2100, hehe, time will come ;-)
[17:16] <kgunn> mterry: btw, langasek had already package reviewed qtmir
[17:16] <olli> sil2100, is there a way for me to see the current queue of silos, ideally in the order you guys will process them?
[17:16] <kgunn> in case that matters
[17:16] <mterry> kgunn, right
[17:17] <robru> olli, not really. just the pending tab of the spreadsheet, but they're not really assigned in the order requested, more like "assigned in the order that people ping about them on IRC"
[17:17] <mterry> robru, I've already looked at most of this changes during MP time actually.  I've just gone through them and I don't see anything awful.  ACK
[17:17] <robru> mterry, thanks buddy!
[17:17] <olli> robru, thx
[17:18] <robru> olli, you're welcome! Is there one you want assigned soon?
[17:19] <olli> robru, next pick would simply be a line that's entirely green?
[17:20] <robru> olli, err, nope. more like, green-green-red.
[17:20] <robru> (right third one is testing pass state, taht can only get green after the silo is assigned)
[17:20] <olli> gotcha
[17:21] <olli> so there is a good lineup... let me check if I have an opinion
[17:22] <robru> olli, https://docs.google.com/a/canonical.com/spreadsheet/lv?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&type=view&gid=0&f=true&colid0=2&filterstr0&colid1=35&filterstr1=Yes&sortcolid=-1&sortasc=true&rowsperpage=250 try this on for size. this is a special "filtered list" view on the spreadsheet, it hides rows that are already assigned, and hides rows that are set as ready:no, which means those are the potential candidates for assignment.
[17:23] <robru> unfortunately I can't actually process the assignments from that view, otherwise it might actually be useful ;-) but if you just wanna look, it's an interesting way to slice the data.
[17:24] <sil2100> Man, my head hurts
[17:25] <olli> robru, there is a whole bunch
[17:26] <olli> if I was talking with my Unity/Mir head on I'd give preference to things related there
[17:26] <olli> head/hat
[17:26] <robru> olli, yep. many of them are months old as well. since there is only 1 silo available, I have to be very careful who I give it to!
[17:26] <olli> putting my Rick hat on, I'd say go for bugfixes
[17:27] <robru> olli, oh, we just promoted an image, doesn't that mean it's time for Feature Bonanza?
[17:27] <robru> ;-)
[17:27] <sil2100> o/
[17:27] <robru> sil2100, goodnight!
[17:27] <cwayne_> hihi, now that we're out of traincon0, can we get silo 008 landed without qa validation? or is it still needed?
[17:27] <olli> robru, when are you planning to promote again
[17:27] <olli> heh
[17:27] <robru> cwayne_, yeah probably
[17:28] <robru> olli, well i think the plan is to land silo 6, build an image, consider that one for promotion as well, and then after that, open it up for any & all landings.
[17:28] <olli> robru, I don't think I have more to add
[17:29] <robru> olli, no worries. is rick off or something? I didn't understand why you're wearing his hat ;-)
[17:29] <olli> robru, once open for any & all landings... when are you cutting an image again?
[17:29] <olli> robru, yeah, get to be rick this week, wasn't sure if you asked me for input in that role
[17:30] <olli> hence the hats ;)
[17:30] <robru> olli, well cron kicks an image daily, but sometimes we manually kick 1 or 2 extra depending on how many landings there are. so today I think I'm just kicking the one.
[17:30] <olli> ok, wfm
[17:30] <rsalveti> tvoss: you don't usually set the silo as 'passed' before the MRs are approved
[17:30] <rsalveti> pass here means ready to land
[17:30] <rsalveti> which is not the case as the mrs are not yet approved
[17:31] <robru> olli, thanks
[17:31] <rsalveti> gezzz, seems we're landing qtcompositor?
[17:32] <bzoltan> rsalveti: is that MR and the landing line 40 good?
[17:32] <robru> rsalveti, qtcompositor is happening! it was ready since yesterday. any problems, blame kgunn! ;-)
[17:32] <rsalveti> bzoltan: I didn't get why the blank mr, do you just want to land the latest in the packaging branch?
[17:32] <bzoltan> rsalveti:  yes
[17:33] <rsalveti> lol, you guys are fast
[17:33] <rsalveti> just out of trainco 0
[17:33] <rsalveti> nice
[17:33] <robru> rsalveti, well this qtcompositor stuff is supposed to fix one of the blocker bugs, so we're doing it.
[17:33] <rsalveti> bzoltan: should be enough, will take a look later today
[17:33] <bzoltan> rsalveti:  thanks
[17:33] <rsalveti> robru: new features, hopefully without new bugs :-)
[17:36] <robru> rsalveti, bugs? never!
[17:36] <robru> infinity, cjwatson: anybody around to NEW qtmir and qtmir-gles? I need to get those in so I can build & image before I can release a bunch of other silos.
[17:41] <cjwatson> slangasek: ^- I gather you'd pre-reviewed those, so can you do the honours?
[17:43] <robru> cjwatson, slangasek: thanks guys
[17:43] <slangasek> yep
[17:44] <slangasek> oh, which honors am I doing?
[17:44] <cjwatson> ah, Steve had beaten me to it anyway
[17:44] <slangasek> it's not in NEW
[17:44] <slangasek> no, somebody else
[17:44] <cjwatson> somebody else did; it did hit NEW for ~20 minutes
[17:45]  * slangasek nods
[18:06] <rsalveti> robru: mind reconfiguring silo 1?
[18:07] <slangasek> 161! we go through a lot of numbers
[18:07] <robru> rsalveti, done: https://ci-train.ubuntu.com/job/prepare-silo/1185/console
[18:07] <robru> slangasek, what?
[18:07] <rsalveti> crap
[18:08] <rsalveti> thanks :-)
[18:08] <slangasek> robru: oh, just idle comments on the mailing list discussion :)
[18:08] <slangasek> robru: I'm not sure how Saviq went from 157 to 161, but sil2100 clarified that 158 is next :)
[18:09] <rsalveti> x86 is 3 ids ahead
[18:09] <robru> slangasek, apparently the i386 and arm image numbers are out of sync
[18:09] <robru> rsalveti, lol, took me a while to notice what you did with the topic there
[18:09] <rsalveti> yeah, mouse was in the wrong place :-)
[18:10] <robru> rsalveti, what IRC client you using? mine doesn't let me live-edit topics like that. have to copy & paste into the message area, kind of a hassle
[18:10] <rsalveti> old xchat
[18:10] <rsalveti> for some reason I have enough permission to change the topic
[18:11] <robru> rsalveti, anybody can change the topic in this channel, it's unrestricted
[18:11] <rsalveti> oh, that's why then
[18:11] <rsalveti> :-)
[18:14] <rsalveti> fixed, rebuilding
[18:14]  * slangasek eagerly updates to 157
[18:16] <Saviq> slangasek, oops ;)
[18:16] <Saviq> slangasek, emulator images apparently ;)
[18:17] <Saviq> didn't know they have different numbers to the phones
[18:17] <mhr3> robru, anything blocking 008?
[18:17] <robru> mhr3, yep, waiting for 6 to finish landing, then I'm going to kick an image. give it a couple hours
[18:17] <mhr3> alright
[18:18] <robru> barry, system-image progressbar problem went away by itself, not sure what ever caused it!
[18:37] <popey> robru: any plans to trigger a new image soon?
[18:37] <robru> popey, yep, as soon as silo 6 finishes landing, which should be soonish
[18:37] <popey> can you hang fire, I'm approving core apps clicks right now
[18:39] <robru> popey, oh ok, sure, just let me know
[18:39] <popey> ta
[18:40] <robru> popey, how long do you think you need? (just curious, no rush)
[18:40] <popey> ~30 m
[18:40] <robru> popey, perfect, I'll take lunch ;-)
[18:40] <robru> brb
[18:52] <popey> robru: all done, all new clicks in the next image
[19:01] <Saviq> now migrate already!
[19:01] <Saviq> should we worry about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings or will this get sorted out by itself?
[19:02] <tvoss> cjwatson, still around?
[19:04] <Saviq> ah fook oh noes
[19:04] <Saviq> robru, kgunn, we've a problem...
[19:05] <Saviq> ubuntu-system-settings is all arch (arm64, ppc etc. as well), but qtmir is only armhf/i386/amd64
[19:06] <kgunn> Saviq: ug...
[19:06]  * olli is watching live while in a HO with kgunn
[19:06] <Saviq> so u-s-s from the silo is blocked in proposed because qtmir is not available in all the arches u-s-s is available in
[19:06] <kgunn> Saviq: so we gotta build qtmir for all archs ?
[19:06] <robru> popey, thanks
[19:06] <Saviq> kgunn, that's probably not possible
[19:07] <Saviq> because we don't have mir for all those arches
[19:07] <robru> Saviq, ugh, how did this happen?
[19:07] <Saviq> ;( help
[19:07] <Saviq> robru, usual, there's no hardware using arm64/powerpc/ppc64el phone
[19:08] <robru> Saviq, you need to add a build-dep on qtmir so that it knows not to build on those arches
[19:08] <Saviq> robru, and u-s-s didn't have a dependency like that before
[19:08] <Saviq> robru, it doesn't
[19:08] <Saviq> robru, but u-s-s was on those arches before
[19:08] <robru> Saviq, ok then we need somebody like infinity or cjwatson to manually override that. it's out of my hands
[19:09] <Saviq> robru, yeah I thought so :|
[19:09] <kgunn> slangasek could you possibly help ^ ?
[19:11] <Saviq> TBH not even sure how it could be available before when it used unity-mir... that's only armhf/i386/amd64... probably no explicit dep
[19:11] <Saviq> yeah, it only got away with it because no one tried it on the other arches
[19:31] <kgunn> robru: whom might we plea to for some help ?
[19:32] <robru> kgunn, I'd go with cjwatson, infinity, stgraber, or slangasek but nobody seems to be responding to pings at the moment.
[19:33] <kgunn> robru: ok, will sit tight...
[19:33] <robru> kgunn, yeah it's all we can do
[19:33] <robru> kgunn, care to speculate on what potential consequences might arise from an image build that has all of silo 6 except system settings?
[19:34] <slangasek> Saviq, kgunn, robru: you don't get manual overrides for such things; you update the uninstallable package to not be built on the arch where it's uninstallable and we remove the binaries from the archive
[19:34] <kgunn> robru: yeah, i don't think it'll boot actually....infinite spinning logo would be the result i think
[19:35] <robru> kgunn, cool
[19:35] <slangasek> so someone please upload ubuntu-system-settings to limit its Arch list or make it FTBFS on !i386 !x86_64 !armhf
[19:36] <robru> slangasek, so what, like add a build-dep on mir?
[19:37] <slangasek> robru: probably just change the Architecture: any to Architecture: i386 amd64 armhf on the binary packages
[19:37] <robru> slangasek, isn't hard-coding arches technical debt? I've been told not to do that
[19:37] <slangasek> but if you prefer to build-dep on mir instead, that's ok
[19:37] <slangasek> robru: yeah, for this reason a build-dep on an arch-specific mir package is fine
[19:37] <robru> slangasek, ok, will do
[19:38] <robru> slangasek, will need you to delete those binaries in a minute
[19:38] <slangasek> ack
[19:41] <robru> kgunn, slangasek, https://code.launchpad.net/~robru/ubuntu-system-settings/build-dep-mir/+merge/228755 k, will build this in the silo if it looks good to you.
[19:41] <kgunn> robru: thanks looking
[19:41] <robru> whoops, looks like I proposed to the wrong place
[19:43] <robru> kgunn, slangasek: sorry try https://code.launchpad.net/~robru/ubuntu-system-settings/build-dep-mir/+merge/228756
[19:44] <kgunn> robru: got it, so that'll make it just ftbfs
[19:44] <kgunn> for those archs
[19:44] <robru> kgunn, yep, it won't be able to build without that on arches that don't have it
[19:45] <kgunn> robru: crap...need an approver
[19:45] <kgunn> bfiller: do you have capability? to top approve
[19:45] <kgunn> https://code.launchpad.net/~robru/ubuntu-system-settings/build-dep-mir/+merge/228756
[19:46] <bfiller> kgunn: looks like I don't on that MR
[19:46] <bfiller> kgunn: kenvandine might ^^^^^
[19:46] <kgunn> rsalveti: ^
[19:47] <kgunn> just an mp to cast off the need for ppc/arm64
[19:47] <kgunn> in the case of qtmir
[19:48] <kgunn> charles: you might be able to help....just need a top approver
[19:48] <kgunn> https://code.launchpad.net/~robru/ubuntu-system-settings/build-dep-mir/+merge/228756
[19:51]  * kenvandine looks
[19:51]  * kgunn hugs kenvandine
[19:53] <kenvandine> kgunn, done
[19:53] <kgunn> kenvandine: thanks, bullet dodged
[19:57] <charles> kgunn, kenvandine, thanks
[19:59] <robru> gosh that status is misleading ;-)
[20:00] <robru> slangasek, I guess this is what success looks like? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/6222567 can you delete those binaries now?
[20:04] <slangasek> robru: absolutely :)
[20:04] <robru> slangasek, thanks!
[20:11] <alecu> so, is the train already moving? Who do we bribe around here for silos?
[20:11] <alecu> :-)
[20:13] <kgunn> thanks slangasek
[20:13] <kgunn> takin' a break bbiab
[20:28] <cjwatson> slangasek: um, ubuntu-system-settings has rdepends on those arches; I'm not sure you're improving things by just pushing the uninstallability up a level
[20:28] <cjwatson> slangasek: and in particular it leaks into the whole online-accounts stack which is a real pain to arch-limit (BTDT)
[20:29] <slangasek> ah
[20:29] <slangasek> cjwatson: so from the discussion above, the packages are de facto not usable on those architectures because of a (logical but previously undeclared) dependency on mir
[20:30] <cjwatson> they've been usable enough to satisfy build-deps
[20:30] <cjwatson> I understand the wider point, but I've analysed this stack before and it's a nightmare to disentangle
[20:31] <cjwatson> so I think we need to figure something out even if it's not in u-s-s itself
[20:32] <cjwatson> the deps are: indicator-bluetooth; ubuntu-system-settings-online-accounts <- (account-plugin-{lots}, friends-app, reminders-app, etc.)
[20:32] <cjwatson> the main difficulty is where it globs into account-plugin-* and requires making a bunch of things explicitly Architecture: amd64 armhf i386 to avoid building uninstallable things
[20:35] <robru> alecu, no silos to be had just yet
[20:35] <robru> cjwatson, uh, I *just* hit publish on u-s-s with a new qtmir build-dep
[20:36] <cjwatson> ubuntu-system-settings-online-accounts seems pretty tied to ubuntu-system-settings, and the account-plugin-* packages seem pretty tied to it
[20:36] <cjwatson> robru: sorry to come into this late, it was dinnertime
[20:36] <cjwatson> (and I'm about to be called away again)
[20:36] <robru> cjwatson, thanks for looking at it... soo... do I need to rebuild it again or is this gonna work*?
[20:37] <robru> * for values of 'work' that include 'unblock it from proposed'
[20:37] <cjwatson> robru: depends whether slangasek has already removed binaries; if he has then he's created uninstallables, and I would not do that
[20:37] <slangasek> I haven't yet
[20:38] <alecu> robru: not even with some hefty bribe? ;-)
[20:38] <slangasek> cjwatson: how do you want to handle?
[20:38] <alecu> robru: no problem, I'll ask again in some hours.
[20:38] <cjwatson> I get that it's not usable, but it apparently worked well enough to not have to tear UOA apart.  can we make the dependency conditional?
[20:38] <robru> alecu, you can't bribe me to give you something that doesn't exist ;-)
[20:38] <robru> alecu, but something should free up soon hopefully...
[20:38] <alecu> great
[20:39] <robru> cjwatson, I have no clue about this component. I'm just doing what people tell me to do with it
[20:39] <cjwatson> (maybe it mostly just needed the library to work, and then to be able to depend on ubuntu-system-settings although nothing ends up being used in the build chain)
[20:39] <cjwatson> robru: I'm mostly talking to slangasek
[20:39] <robru> cjwatson, ok
[20:41]  * robru secretly hopes that the thing he just publishes unblocks u-s-s from proposed so he can kick an image and then land the 4 other silos that have been waiting all day
[20:42] <cjwatson> I doubt it
[20:44] <slangasek> cjwatson: so I'm coming around to the conclusion that forcing u-s-s in might be a lesser evil
[20:45] <slangasek> to unblock, and then we can unpick the dependencies without Landing Team pressure
[20:45] <cjwatson> my inclination would be http://paste.ubuntu.com/7898248/ on top of use-qtComp
[20:45] <cjwatson> that's possible, but please check how many uninstallables it yields first
[20:45] <slangasek> that's for u-s-s?
[20:45] <cjwatson> yeah
[20:45] <cjwatson> dropping the build-dep-mir branch
[20:46]  * slangasek nods
[20:46] <cjwatson> all the options here are suboptimal in one way or another; that one more or less restores the status quo on the secondary arches
[20:48] <robru> cjwatson, so should I apply that diff and rebuild and reupload or can you just upload that for me since you have the diff there already
[20:48] <robru> ?
[20:48] <cjwatson> robru: I have a five-year-old more or less begging for my attention
[20:49] <cjwatson> so I kind of don't want to supervise right now
[20:49] <robru> cjwatson, ok I'll do it then, sign off!
[20:49] <cjwatson> ok :)
[20:52] <robru> slangasek, so if I apply that ^ is it gonna unblock without needing you to delete packages?
[20:53] <slangasek> robru: yes
[20:53] <robru> slangasek, ok, it's building now
[20:53] <cjwatson> robru: oh, just to make it clear, that doesn't conflict with your build-dep-mir branch directly, but you will need to drop that change in order for this to be useful
[20:53] <slangasek> robru: ok, perfect :)
[20:53] <slangasek> right, what cjwatson said
[20:53] <robru> cjwatson, yep, done
[20:54] <cjwatson> right, LGTM
[21:05] <popey> fginther: http://paste.ubuntu.com/7898371/
[21:05] <popey> payui fails the click-reviewer-tools
[21:05] <popey> jdstrand: ^
[21:05] <popey>       "text": "id 'payui_payui' != 'com.canonical.payui_payui'"
[21:08] <jdstrand> popey: yeah, so, I think we need tedg
[21:09] <popey> paging Mr Gould, paging Mr Gould. Mr Gould to the white courtesy phone...
[21:09] <jdstrand> tedg: looking at other online accounts application ids, my understanding is it should be <click pkgname>_<appname>
[21:09] <alecu> jdstrand, popey: tedg is on vacations this week
[21:09] <popey> erk
[21:09] <alecu> jdstrand: popey: can I help instead?
[21:09] <jdstrand> ah, well, whoever uploaded this then
[21:10] <popey> fginther: did
[21:10] <alecu> gatox asked for this to be uploaded, but seems to be gone now.
[21:10] <jdstrand> popey: the "unconfined" template for this is 'ok' (previously discussed)
[21:10] <popey> sure
[21:10] <popey> this was new though, hence me rejecting it
[21:10] <jdstrand> yes
[21:11] <jdstrand> I think you are right
[21:11] <jdstrand> I think that is a legitimate error in the app
[21:11] <jdstrand> aiui
[21:11] <jdstrand> we might want mardy's input too though
[21:11] <alecu> jdstrand: popey: pay-ui just started using libonlineaccounts-client. Is that error due to this?
[21:12] <jdstrand> alecu: it is related to its use of online accounts, yes. it isn't declaring its application id correctly
[21:12] <jdstrand> = click-check-online-accounts =
[21:12] <jdstrand> {
[21:12] <jdstrand>   "error": {
[21:12] <jdstrand>     "online_accounts_payui_account-application_id": {
[21:12] <jdstrand>       "text": "id 'payui_payui' != 'com.canonical.payui_payui'"
[21:12] <jdstrand>     }
[21:12] <jdstrand>   },
[21:13] <jdstrand> alecu: ^
[21:13] <jdstrand> alecu: I think it is just a simple string change in the xml
[21:13] <alecu> ok, I'll propose a branch for that
[21:13] <jdstrand> == online account-application: com.canonical.payui.application ==
[21:13] <jdstrand> <?xml version="1.0" encoding="UTF-8" ?>
[21:13] <jdstrand> <application id="payui_payui">
[21:13] <jdstrand> alecu: ^
[21:14] <jdstrand> change that to 'id="com.canonical.payui_payui"' and it should be fine to upload. granted, I don't know if something else needs to change internally
[21:15] <alecu> jdstrand: I'll test that change on my phone, and will ask for it to be reuploaded
[21:16] <jdstrand> alecu: awesome, thanks! :)
[21:36] <alecu> yes!
[21:39] <Saviq> robru, thank you for getting silo 6 sorted out
[21:39]  * Saviq wasn't sure what was the right solution
[21:39] <robru> Saviq, me either but I got told ;-)
[21:40] <Saviq> robru, yeah, lesson learned!
[21:40] <robru> Saviq, you're welcome! I'm super stoke to get that published and an image kicked
[21:46] <Saviq> robru, ↑
[21:46] <robru> yep ;-)
[21:51] <gatox> jdstrand ping
[21:54] <jdstrand> gatox: hey
[21:59] <jdstrand> gatox: so, I am heading out. all my comments on the payui application id are in scrollback and alecu is handling it
[21:59] <gatox> jdstrand, i'm trying to propose a branch for payui fixing the problems in the xml...but when trying to do it as it is suggested... the ubuntu sdk fails to build it if i declare the project as com.canonical.payui.... and if i just put the whole names without using cmake var to build the tihngs it fails to launch online accounts
[21:59] <jdstrand> gatox: I do read backscroll though, so feel free to ping me
[21:59] <jdstrand> ah
[22:00] <jdstrand> gatox: I think we need bzoltan and mardy to comment
[22:01] <jdstrand> gatox: I wrote the tests based on what I observed other apps did (eg, reminders). I don't know what the sdk is doing, though istr mardy and the security talking about how these would be namespaced
[22:01] <jdstrand> gatox: unfortunately, they are both eod right now
[22:01] <jdstrand> s/security/security team/
[22:01] <gatox> jdstrand, so.... is not going to be posible to land this?
[22:01] <gatox> today
[22:02] <jdstrand> I think it is in error. I just don't know how to tell you to fix it :\
[22:03] <gatox> jdstrand, because the way it is right now.... was working in the phone..... trying to make the changes as it was suggested brakes the build with the sdk..... or breaks the launching of online accounts
[22:10] <Saviq> robru, it looks like there's some action from archive admins needed now (removing the old binaries?) http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
[22:10] <robru> Saviq, no, that page is stale (note it says v...29 and not v...29.1)
[22:11] <Saviq> robru, ah, not ran yet, than, tx
[22:18] <jdstrand> gatox: it may work but it is breaking namespacing rules
[22:18] <gatox> jdstrand, i think i found the solution
[22:19] <jdstrand> ok, cool
[22:20] <gatox> jdstrand, yes.... just tested it.... proposing the branch
[22:23] <jdstrand> gatox: nice!
[22:25] <Chipaca> could I have silo 9 landed please?
[22:25] <gatox> fginther, hi.... sorry to bother you again... if you are still around, i just sent you an email with a new click version
[22:26] <fginther> gatox, got it
[22:26] <gatox> fginther, thanks..... and sorry for the trouble
[22:26] <fginther> gatox, uploaded (and no worries)
[22:27] <gatox> fginther, thanks!
[22:32] <popey> gatox: fginther ERROR: Could not load 'payui.json'. Is it properly formatted?
[22:33] <gatox> popey, :s checking
[22:33] <popey> http://paste.ubuntu.com/7898990/
[22:33] <popey> missing a line-feed?
[22:33] <gatox> popey, how can i run those checks locally?
[22:34] <popey> lp:click-reviewers-tools
[22:35] <popey> bin/click-run-checks foo.click
[22:36] <popey> http://paste.ubuntu.com/7899020/ is an example good one gatox
[22:37] <popey> http://paste.ubuntu.com/7899029/ is the one from the terminal app
[22:37] <popey> (also unconfined)
[22:37] <popey> gatox: also failed in other ways, ERROR: Could not find 'payui.desktop'
[22:37] <gatox> popey, yes.... i found that issue
[22:38] <popey> i need to EOD now...
[22:39] <popey> will check for new payui in the store in the morning
[22:40] <gatox> popey, i'm about to send the click
[22:40] <gatox> popey, after running the tools
[22:41] <popey> ok
[22:41] <popey> will hang around 10 mins
[22:44] <fginther> gatox, I'm here as well
[22:44] <gatox> fginther, popey thx both.... i just sent the new click to francis.... as far as i can see the only error is about unconfined that it says it needs manual check
[22:45] <popey> thats fine
[22:45] <popey> we have already discussed and accepted that
[22:45] <fginther> gatox, popey it is uploaded
[22:45] <popey> got it
[22:46] <popey> approved it gatox fginther, thanks
[22:46] <popey> should be in the next image
[22:46] <gatox> popey, fginther great! thanks!
[23:00] <rsalveti> awesome
[23:32] <cjwatson> ubuntu-system-settings from silo 6 is in utopic according to rmadison - kicking an image build
[23:32] <cjwatson> (someone tell robru if he shows up again)
[23:37] <Saviq> Laney, FWIW, the wizard wouldn't work on other arches before anyway (since it needed libunity-mir1, which was only available for the usual arches as well)
[23:37] <Saviq> Laney, only difference is now it doesn't get built instead of just failing when you tried it
[23:39] <imgbot> [23:41] <cjwatson> Saviq: we had to start building it again
[23:41] <cjwatson> Saviq: the fallout is too complicated on secondary arches