[09:25] <rsalveti> didrocks: sergiusens: so, I just noticed a qtubuntu mr got merged automatically after approved
[09:25] <rsalveti> thought it'd be on hold for the landing slot stuff
[09:25] <rsalveti> https://code.launchpad.net/~ricmm/qtubuntu/build-multiple-binary-fix/+merge/203975
[09:25] <rsalveti> should we release it via the old method?
[09:26] <didrocks> rsalveti: let me check if it's in CI Train
[09:26] <didrocks> (it's still possible to release trunk with an empty MP at worse)
[09:27] <didrocks> rsalveti: there is no lander for qtubuntu
[09:27] <didrocks> I wonder what sergiusens is doing!
[09:27] <didrocks> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1
[09:28] <didrocks> sergiusens: putting that on your shoulders for citrain?
[09:32] <didrocks> plars: psivaa: joining us?
[09:32] <plars> didrocks: we're in a meeting at the moment
[09:32] <plars> didrocks: sorry
[09:32] <didrocks> ah
[09:32] <popey> outrage!
[09:32] <didrocks> plars: joining afterwards?
[09:32] <popey> I was early and everything
[09:32] <didrocks> :p
[09:32] <didrocks> poor popey and Mirv ;)
[09:33] <plars> didrocks: the results I looked at on mako seemed pretty random over the past 2 builds - same number of failures but different tests that failed, so nothing that's a clear regression
[09:33] <Mirv> :(
[09:33] <plars> didrocks: I believe psivaa said maguro was the same
[09:33] <Mirv> now I have to spend quality time with popey!
[09:33] <ogra_> the whoopsie-upload crash is new though
[09:33] <didrocks> plars: hum, ok, we'll do without you
[09:33] <ogra_> (in install-and-boot)
[09:33] <didrocks> thanks
[09:33] <sergiusens> didrocks, I didn't do anything
[09:33] <didrocks> popey: Mirv: joining your party
[09:33] <didrocks> sergiusens: that's the issue! :)
[09:34] <didrocks> you slacked over and didn't assign to you qtubuntu :p
[09:34] <popey> typical fin, mirv is on mute
[09:34] <didrocks> sergiusens: more seriously, are you going to take care of qtubuntu as a lander?
[09:34] <Mirv> silence is golden
[09:34] <sergiusens> didrocks, yes
[09:35] <sergiusens> didrocks, yeah, I had to discuss that one; it's an edge case
[09:35] <sergiusens> didrocks, but seems it falls into our team
[09:35] <rsalveti> yeah, it was in a gray area
[09:41] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/156:20140131:20140115.1/6364/security/
[09:41] <ogra_> Mirv, ^^
[10:08] <Mirv> hmm, I wonder why my screen stays black after flashing even after two reboots. unity8 seems to be running. and yes libunity-mir is installed
[10:14] <Mirv> um, I guess I need to total-destruction-flash
[10:16] <sil2100> hm, here it works fine, just flashed it clean
[10:52] <Mirv> sil2100: ok I've working device, but I still don't have explanation on where were the test tools that contain eg. that run_test.sh?
[10:53] <cjwatson> any reason I can't upload livecd-rootfs?  we have an urgent ppc64el deadline which is going to require a change there
[10:53] <cjwatson>   [ Chris Wayne ]
[10:53] <cjwatson>   * Add hostname and machine-info to the writable paths, so that hostnamectl
[10:53] <Mirv> not eg at https://wiki.ubuntu.com/Touch/Testing
[10:53] <cjwatson>     can change them to create a sane default bluetooth device name.
[10:53] <cjwatson> is the other change
[10:54] <ogra_> popey, could you reproduce the UI hang you had during the meeting ?
[10:54] <cyphermox> eh, why is that in livecd-rootfs?
[10:55] <cjwatson> dunno
[10:55] <cjwatson> don't have time to look
[10:55] <cyphermox> I would have thought lxc-android-config :/
[10:55] <cyphermox> cjwatson: if it's the change I think, it's pretty harmless
[10:55] <ogra_> cyphermox, thats the weird way ...
[10:55] <cjwatson> http://paste.ubuntu.com/6848788/ is the full patch
[10:55] <cjwatson> which makes sense to me I think
[10:55] <cyphermox> right
[10:55] <cyphermox> safe
[10:55] <cjwatson> good
[10:55] <ogra_> we have two variants of writable files ... one requires the file to be touched and to pre-exist in the image
[10:57] <ogra_> cyphermox, there is a second half that i'm not actually happy with that does the boot time bits for setting the hostname
[10:57] <ogra_> (for lxc-android-config
[10:57] <ogra_> )
[10:57] <cyphermox> ogra_: why are you not happy with it?
[10:57] <ogra_> cyphermox, because it runs at every boot
[10:57] <cyphermox> only if the value isn't set, otherwise it's a no-op
[10:57] <ogra_> while it should be a one time/ first boot thing
[10:58] <cyphermox> (not that it's much better to even start it at all)
[10:58] <Mirv> sil2100: ok found btw finally
[10:58] <ogra_> i would pretty much like us to have some way of running things at first boot once
[10:58] <Mirv> didrocks: sil2100: on another note, qmlscene maguro crash might be fixed by https://code.launchpad.net/~ricmm/unity-mir/catch-starting-failure/+merge/203920
[10:59] <didrocks> Mirv: yeah, we still need to have more infos from the toolkit/qt side on why the app failed to start though :)
[10:59] <sil2100> Mirv: yes, we know ;)
[10:59] <ogra_> while it might not add much, the processing happens in a "script" block in the upstart job ... that means a shell is fired up just for checking the file and killing the job again
[10:59] <cyphermox> ogra_: well, right now it's half-way there, it actually does anything only on first boot
[11:00] <Mirv> aha :)
[11:00] <cyphermox> right
[11:00] <sil2100> Mirv: oh, sorry, missed your prev message!
[11:00] <cyphermox> I know it's not ideal, but there doesn't seem to be an alternative yet
[11:00] <cjwatson> oh, that livecd-rootfs change was already uploaded but not committed
[11:00] <cjwatson> god's sake people
[11:00] <cyphermox> ugh
[11:01]  * ogra_ checks 
[11:01] <ogra_> phew, wasnt me
[11:01] <cjwatson> so never mind, not for this channel
[11:02] <ogra_> cyphermox, i'll land the lxc-android-config bit today ... but we really need to find some better way for that first-boot-run-once stuff
[11:03] <popey> ogra_: no
[11:03] <popey> ogra_: i think it was some odd quirk that happend when i took a screenshot
[11:04] <ogra_> ah, k
[11:04] <ogra_> we just sasw a hang on the new N7 with the latest zip and were wondering if the two were related
[11:04] <popey> ogra_: I've now taken 80 screenshots
[11:04] <popey> and it's not hung yet
[11:04] <ogra_> (but we use cdimage images so its not very likely)
[11:06] <Mirv> sil2100: ok still not everything, missing "qrt_tests"?
[11:09] <Mirv> aha, setup.sh..
[11:20] <Mirv> didrocks: sil2100: I'm getting a pass on 156 of click-apparmor
[11:22] <sil2100> Mirv: did you try many retries?
[11:22] <Mirv> sil2100: 5 so far
[11:22] <sil2100> Mirv: I'm trying to retrace the unity8 crash but I seem to be getting a strange python error while trying to fetch more information from the coredump and crash file
[11:25] <Mirv> sil2100: didrocks: ok on 7th try I got one upstart failure, but under different subtest than in the logs. so seems flaky.
[11:25] <didrocks> Mirv: hum, interesting
[11:28] <sil2100> Did anyone get an error like this before when trying to apport-cli a crash: struct.error: unpack requires a bytes object of length 4
[11:28] <sil2100> (python error)
[11:34] <sil2100> Mirv, didrocks: so, the unity8 crash on the install-and-boot has a damaged (not completely downloaded) CoreDump, so we can't really retrace it properly
[12:25] <sil2100> Mirv: did you try pinging someone that could help us out with these?
[12:26] <sil2100> Mirv: with the failing security tests
[12:29] <Mirv> sil2100: no I didn't. I'm not sure if it should upstart devs or apparmor?
[12:31] <sil2100> Mirv: that's a valid question...
[12:31] <sil2100> Mirv: you could start off with Jamie I guess?
[12:51] <Mirv> jdstrand: ^ can you think of something why click-apparmor test has become flaky? https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/console
[12:51] <Mirv> jdstrand: I could reproduce it on my mako ca. 1/5 or 1/10, although the exact test case might vary
[13:01] <Mirv> sil2100: argh, sorry, I'm running out of time now on all fronts and I'm into hangout now
[13:03] <sil2100> Mirv: ok, I'll try to poke this as well
[13:18] <jdstrand> Mirv: re click-apparmor> I don't know why it has become flaky, no. there is a sleep in there though to wait on upstart starting an app-- it is 15 seconds though. if it is failing, I would think it has something to do with app startup
[13:20] <jdstrand> Mirv: did you say it always failed or intermittently failed?
[13:20]  * jdstrand assumes 1/5 and 1/10 means intermittently
[13:21] <sil2100> jdstrand: yes, it seemingly failed every 5 or 10 times
[13:22] <jdstrand> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/artifact/clientlogs/application-click-com.example.lp1245677_lp1245677_0.1.log/*view*/ shows: ** (process:14151): WARNING **: Unable to exec: Permission denied
[13:22] <Mirv> jdstrand: the delays seem quite near 15 seconds though every time
[13:22] <Mirv> sil2100: thanks
[13:23] <Mirv> (the delay that I see the line about upstart launch in the test)
[13:23] <sil2100> Mirv: did you try downgrading any of the listed risky packages?
[13:23] <Mirv> ah, except that if there's no output whatsoever and it's always the same sleep
[13:23] <jdstrand> there is a TODO to remove the sleep because I don't know how else to know when upstart has *actually* started the thing. it will return 'started' immediately iirc, but then may not immediately do its thing
[13:25] <jdstrand> Mirv: you said different tests within click-apparmor would fail?
[13:28] <Mirv> (sorry still in hangout)
[13:29] <Mirv> jdstrand: yeah for example I had it in com.example.am-i-confined_am-i-confined_0.1.desktop, during the checking application upstart job, while that ^ log shows it under different one.
[13:30] <jdstrand> Mirv: but is it always com.example.am-i-confined_am-i-confined_0.1.desktop?
[13:30] <Mirv> I mean here it was https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/console com.example.lp1245677_lp1245677_0.1.desktop
[13:31] <Mirv> while I had it during checking application upstart job of another one
[13:32] <jdstrand> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/console and http://ci.ubuntu.com/smokeng/trusty/touch/mako/156:20140131:20140115.1/6364/security/719045/ failed in the same place on the same test
[13:33] <jdstrand> (the 2nd was the original you pointed me to
[13:33] <jdstrand> )
[13:33] <sil2100> I think it's the same test-run even
[13:34] <jdstrand> can you point me to different runs with the failure?
[13:34] <Mirv> sil2100: I downgraded upstart packages to the previous one. no failure yet, but it's hard to be conclusive
[13:34] <Mirv> jdstrand: http://pastebin.ubuntu.com/6849408/
[13:36] <jdstrand> is http://ci.ubuntu.com/smokeng/trusty/touch/mako/156:20140131:20140115.1/6364/ the first time is started failing?
[13:36] <Mirv> jdstrand: looks like, on http://ci.ubuntu.com/smokeng/trusty/touch/mako/156:20140131:20140115.1/6364/security/ you can see "Result History" for previous 5
[13:36] <Mirv> and click for more. so yes.
[13:37] <jdstrand> ok
[13:37] <sil2100> jdstrand: yes, we were suspecting that some of the last uploads we made to the image caused it to start happening
[13:38] <jdstrand> fwiw, I hate this test because of the sleep, but it could be showing a problem somewhere else-- 15 seconds is a *long* time to wait to see if an app started
[13:40] <tedg> Wow, I'm getting even faster at scaring didrocks away.
[13:40] <jdstrand> upstart-app-launch has quite a few changes that could conceivably affect this test...
[13:58] <sil2100> Mirv: ok, so it seems no failures with upstart bits reverted, right?
[14:03] <jdstrand> by upstart bits, do you mean upstart-app-launch?
[14:04] <sil2100> jdstrand: yes, I guess that's what you upgraded Mirv ?
[14:04] <sil2100> s/upgraded/downgraded
[14:04] <ogra_> sidegraded :P
[14:15] <jdstrand> hmm, but the error is when using aa-exec click
[14:19] <jdstrand> right, so upstart-app-launch isn't being used by click-apparmor
[14:19] <jdstrand> it is calling the upstart job directly with start, so upstart-app-launch should be off the table
[14:20]  * tedg should have a stable connection now
[14:21] <jdstrand> oh, what a second
[14:21] <jdstrand> wait*
[14:21] <jdstrand> durr, start application
[14:22] <jdstrand> so upstart-app-launch could be on the table, but it shouldn't be for that one test cause it is happening when using aa-exec
[14:23] <jdstrand> meh, let me actually read this thing (apparently I was too clever when I wrote this test script :)
[14:24] <jdstrand> sorry-- I confused myself-- ignore everything I said in the last 5 minutes
[14:25] <sil2100> hmm
[14:25] <jdstrand> start application APP_ID="..." >/dev/null && sleep 15 && [ -f "$test_path" ] *is* what's failing
[14:25] <sil2100> Ok ;) So indeed upstart-app-launch might be related
[14:26] <tedg> jdstrand, Could that be because we change it to a task so that'd get delayed?
[14:26] <tedg> jdstrand, What is "test_path" ?
[14:26] <jdstrand> that was what I was thinking
[14:27] <jdstrand> tedg: $HOME/.local/share/$pkgname/pass
[14:27] <jdstrand> tedg: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/artifact/clientlogs/application-click-com.example.lp1245677_lp1245677_0.1.log/*view*/
[14:27] <tedg> Hmm, seems that shouldn't be an issue.  Really, it should be more reliable now with that task marking.
[14:28] <jdstrand> tedg: that ^ is what's weird. it should look like: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/artifact/clientlogs/application-click-com.example.am-i-confined_am-i-confined_0.1.log/*view*/
[14:28] <jdstrand> tedg: so the binary isn't even getting run for some reason-- but it will most of the time
[14:28] <tedg> jdstrand, Well the call to exec is failing.
[14:29] <jdstrand> yes
[14:29] <jdstrand> but why only occasionally?
[14:29] <tedg> I'm pretty sure that calling a syscall isn't my fault :-)
[14:29] <tedg> Can we turn on debugging to see what teh exec line is?
[14:29] <tedg> Perhaps it's not getting set correctly?
[14:30] <jdstrand> how do you do that?
[14:30] <jdstrand> note, I cannot reproduce locally
[14:30] <jdstrand> Mirv seems to be able to
[14:30] <tedg> You need to set G_MESSAGE_DEBUG=all
[14:30] <tedg> I put it in an Upstart job that is start on starting dbus
[14:31] <tedg> So it's always on for my system.
[14:31] <tedg> http://paste.ubuntu.com/6849653/
[14:33] <jdstrand> tedg: so what does kenvandine's patch do?
[14:33] <tedg> jdstrand, The triplet API one?
[14:33] <jdstrand> "Added upstart_app_launch_triplet_to_app_id to construct an appid from pkg, app, version triplet. If a specific version isn't provided, click is used to determine the version from the manifest."
[14:34] <tedg> jdstrand, It's just putting some common code that used to be in URL dispatcher in libUAL so he can use it in content hub.
[14:34] <tedg> jdstrand, It's not used in the upstart jobs directly.
[14:34] <jdstrand> my thinking was if Mirv is mostly hitting one path, but occasionally hitting the other
[14:34] <jdstrand> hmm
[14:34] <tedg> There was an issue where exec wasn't getting set correctly, but that was an issue with not flushing the dbus connection.
[14:35] <tedg> It looks like that patch is in trunk.
[14:35] <jdstrand> tedg: so, I guess you'd want to see the exec line for both the failing and passing case, correct?
[14:35] <tedg> jdstrand, Well, more the failing :-)
[14:35] <tedg> I think it'll be obvious if it's broken.
[14:35] <sil2100> I'm not sure if Mirv is around anymore...
[14:35] <jdstrand> right, so, I can't seem to help with that
[14:35] <jdstrand> Mirv: can you get what tedg needs?
[14:36] <sil2100> jdstrand: did you try re-running it multiple times on the latest image on a mako?
[14:36] <sil2100> jdstrand: I might try achieving the same here, but I'll have to prepare my device
[14:36] <jdstrand> I can't on mako (it is my dogfood device, I'm an avenger, etc, etc). I am running it in a loop on grouper. it has gone 30 times or more
[14:37] <sil2100> jdstrand: let me try giving it a shot then
[14:38] <sil2100> Might take some moments
[14:38] <jdstrand> sil2100: thanks-- might set up the upstart job like tedg suggested
[14:38] <tedg> It makes you appreciate logrotate ;-)
[14:56] <bfiller> sil2100: how do I know when it's ok to press the "Merge and Clean" button on Landing-002 silo?
[14:57] <bfiller> sil2100: I think the packages are published
[14:58] <seb128> bfiller, when the packages are in the release pocket, if you press too soon the jenkins job is going to fail and you are good to retry later
[14:58] <seb128> e.g no issue trying
[14:58] <bfiller> seb128: how do I know when they hit the release pocket?
[14:59] <seb128> bfiller, you look on https://launchpad.net/distros/ubuntu/+source/<source>
[14:59] <bfiller> seb128: ok thanks
[14:59] <seb128> yw
[14:59] <ogra_> or use rmadison :)
[14:59] <seb128> or if you have bugs linked in the changelog, that's when the bugs get autoclosed by launchpad
[14:59] <seb128> that generates emails
[15:00] <bfiller> I've seen those, cool
[15:03] <sil2100> jdstrand: ok, checking first if I can reproduce the failure at al
[15:03] <sil2100> bfiller: as seb128 said ;)
[15:18] <jdstrand> cool
[15:27] <cjwatson> seb128: you must use rmadison not lp
[15:27] <cjwatson> lp will tell you it's in release when it's finished processing accepted, which is before it hits disk
[15:27] <cjwatson> rmadison updates almost as soon as possible after it hits disk in a way that you can see from jenkins builds etc.
[15:28] <cjwatson> so it's far more accurate for this and doesn't have false positives
[15:44] <sil2100> jdstrand: damn, I'm running and running and I cannot get things failing ;/
[15:49] <jdstrand> sil2100: sounds like we need Mirv :\
[15:56] <sil2100> uh!
[15:56] <sil2100> Wait! Finally!
[15:57] <sil2100> Ok, but without the debugging - but since I made it once, I'll repro it again
[16:04] <balloons> sergiusens, a few questions about click-buddy if you have a moment
[16:08] <sil2100> jdstrand, tedg: when G_MESSAGE_DEBUG=all is set, does it output the logs somewhere?
[16:09] <tedg> sil2100, In the application log.
[16:10] <tedg> sil2100, They should be in ~/.cache/upstart/application*
[16:12] <sil2100> tedg: let me pastebin this
[16:14] <sil2100> tedg, jdstrand: not sure if this helps, but here are the logs: http://paste.ubuntu.com/6850111/
[16:14] <sil2100> tedg, jdstrand: this time it failed on com.example.am-i-confined_am-i-confined_0.1
[16:17] <tedg> Hmm, doesn't seem to have the debug messages.
[16:19] <tedg> sil2100, Can you pastebin ~/.cache/upstart/application.log as well?
[16:20] <tedg> sil2100, Perhaps you could just run "APP_ID=onethatsfailing /usr/lib/*/upstart-app-launch/click-exec" in a loop.
[16:20] <sil2100> tedg: one moment
[16:21] <tedg> See if it ever prints a different APP_EXEC line
[16:22] <sil2100> tedg: this one is poorer than I thought: paste.ubuntu.com/6850144/
[16:22] <sil2100> http://application log.
[16:22] <sil2100> geh
[16:22] <sil2100> Wrong paste
[16:22] <sil2100> http://paste.ubuntu.com/6850144/
[16:24] <tedg> Hmm, don't see any debug messages there either.
[16:25] <tedg> sil2100, Did you add the upstart job or just set it on the command line?
[16:25] <tedg> initctl get-env G_MESSAGES_DEBUG
[16:27] <sil2100> Ah, I see I made a typo
[16:28] <tedg> Oh, good.  I was getting confused :-)
[16:28] <sil2100> G_MESSAGES_DEBUG was missing a 'S'
[16:36] <sil2100> FInally it crashed
[16:37] <seb128> cjwatson, thanks, the launchpad summary/bug emails are usually good enough and less slow to load (though that might not be true anymore since it changed server)
[16:37] <sil2100> tedg: log coming right up
[16:38] <sil2100> tedg, jdstrand: http://paste.ubuntu.com/6850227/
[16:42] <tedg> jdstrand, That looks right to me...
[16:42] <tedg> jdstrand, Not sure that you need the "./" but, that should work.
[16:43] <tedg> sil2100, Is there a DENY in the syslog?
[16:45] <sil2100> tedg: hm, doesn't seem like it
[16:45] <cjwatson> seb128: rmadison is way faster now than it used to be, indeed - it doesn't usually annoy me any more
[16:45] <seb128> cjwatson, good to know, I should change my habits then ;-)
[16:46] <cjwatson> occasionally takes a little while to recache but nothing like the minutes that it sometimes was
[16:46]  * cjwatson nukes raring from its config which can't hurt
[16:50] <bfiller> sil2100: can you publish lines 34 and 35 in CI Train. testing complete
[16:51] <sil2100> bfiller: will do publishing bits in a moment, still counting on finding the badguy for the security test failures
[16:51] <sil2100> tedg and jdstrand are helping me
[16:51] <tedg> sil2100, I don't know what else to suggest.  Not sure how we could have a permission error there.
[16:52] <tedg> We should probably print the executable name on error.
[16:52] <tedg> But I don't think that's this problem.
[16:56] <jdstrand> that is totally odd
[16:56] <jdstrand> the previous run used the same APP_EXEC
[16:56] <jdstrand> and it succeeded
[16:57] <jdstrand> tedg: what is (process:3330) in '** (process:3330): WARNING **: Unable to exec: Permission denied'?
[16:58] <jdstrand> up above, I see 'libust[3330/3332]: Error:...'
[16:58] <tedg> jdstrand, That's the return from the call to exec
[16:58] <jdstrand> no, I mean, what process is that?
[16:58] <jdstrand> 3330
[16:59] <jdstrand> process 3330 is the one that isn't able to do the exec, aiui
[16:59] <jdstrand> so that is what we should be looking at
[16:59] <tedg> jdstrand, It's the one in the exec line of the job.  exec-line-exec
[17:00] <jdstrand> perhaps it is spitting out the wrong error. perhaps it is doing the right thing, but DAC is preventing it
[17:00] <sil2100> ogra_: could you ACK this packaging change? http://162.213.34.102/job/landing-009-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-shell_0.2.8+14.04.20140131.2-0ubuntu1.diff
[17:01] <sil2100> popey: I guess no meeting today! robru is away anyway
[17:01] <popey> ok
[17:01] <popey> sil2100: i tried flashing an old image on my phone
[17:02] <popey> didnt work well
[17:02] <popey> will try harder and let you know what i find
[17:02] <sil2100> popey: ok, thanks! I'll try that as well, maybe during the weekend even
[17:02] <tedg> jdstrand, It's just calling strerror on the return code from execvp
[17:03] <sil2100> Today sadly I was super busy with *everything*
[17:03] <popey> sil2100: http://popey.mooo.com/mirror is my archive
[17:03] <tedg> jdstrand, Not much processing in between.
[17:03] <jdstrand> ok, then that would suggest either MAC or DAC. MAC (apparmor) would show in the log, but it doesn't, so we should be looking at DAC
[17:04] <tedg> jdstrand, I need to run for a bit (reading at my son's school).  Drop me a mail if you need something.
[17:04]  * jdstrand notes that this is not a click-apparmor thing, but will try to help
[17:05] <sil2100> jdstrand, tedg: give me a sign if you find anything as well - I'll fill in a bug regarding this
[17:05] <jdstrand> sil2100: how are you running the click-apparmor test
[17:06] <sil2100> So, I'l logged into the device, I copied the qrt_tests directory with the tests to my main directory, as well as the run_test.sh script (from the branch) and run ../run_test.sh click-apparmor in the qrt_tests directory
[17:07] <jdstrand> sil2100: ok, so if I give you a patch to the click-apparmor test, you'd be able to apply it and we could get more debugging info?
[17:10] <sil2100> jdstrand: I think I could do that :)
[17:12] <sil2100> slangasek: http://162.213.34.102/job/landing-009-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-shell_0.2.8+14.04.20140131.2-0ubuntu1.diff <- pkg changes (only debian/ modifications and makefiles shown)
[17:13] <ogra_> sil2100, ack
[17:13] <slangasek> sil2100: so, where is libunity-scopes 0.2.8? The archive has 0.2.6
[17:14] <slangasek> sil2100: also, why is there a hard-coded dep on libunity-scopes0, instead of this being handled via shlibdeps?
[17:15] <sil2100> slangasek: libunity-scopes is part of the landing, so it's being published along with this package
[17:15] <ogra_> right
[17:16] <sil2100> slangasek: as for the second question - not sure, it seems to have been like that for a while, would have to check and ask for the rationale
[17:16] <ogra_> and we had bad issues with shlibdeps recently (because the code simply didnt do the right thing) in unity8
[17:16] <slangasek> ok, that's fine then; but the hardcoded lib dep looks wrong, I'm not ok to sign off on a version bump of it without knowing why it's there in the first place
[17:16] <slangasek> there needs to be an explicit rationale for such things
[17:20] <ogra_> slangasek, all these unity packages have the libs hardcoded that way, upstream is slowly moving over to shlibdeps (but the unity8 disaster this week showed that this doesnt always work OOTB)
[17:20] <slangasek> sil2100, ogra_: so no, it looks to me like the shlibs in libunity-scopes itself are wrong and need to be fixed, and the hard-coded dep in unity-scopes-shell dropped
[17:20] <slangasek> ogra_: "this is how it's done" is not an excuse for any core-dev signing off on such things that are explicitly contrary to Ubuntu best practices
[17:21] <ogra_> ok
[17:21] <sil2100> hmm...
[17:21]  * ogra_ would agree if just using shlibdeps would work, apparently it doesnt always though 
[17:22] <sil2100> Can I ask for the same for http://162.213.34.102/job/landing-005-2-publish/1/artifact/packaging_changes_gallery-app_0.0.67+14.04.20140131-0ubuntu1.diff then?
[17:22]  * ogra_ doesnt like that second one 
[17:23] <ogra_> that mmeans it will always pull autopilot in if you install gallery-app
[17:24] <sil2100> But that's for the autopilot package of gallery-app
[17:24] <sil2100> So gallery-app-autopilot
[17:24] <ogra_> oh, ok, just for the autopilot package of it ... then i'm fine
[17:25] <ogra_> (that info gets kind of swallowed in the diff)
[17:25] <ogra_> (it woud be nice if there waas a changelog entry for it the next time, but i wont block on it ...)
[17:26] <sil2100> ogra_: true...
[17:26] <ogra_> sil2100, since you published after my ACK (before slangasek NACKED), can you contact upstream to change to shlibdeps with the next upload ?
[17:27] <slangasek> ogra_: shlibdeps works *fine* if people aren't *failing to use them*
[17:27]  * sil2100 sighs
[17:27] <ogra_> slangasek, as long as the linking of the code is right, yes
[17:27] <sil2100> Maybe we can somehow back if off?
[17:28] <ogra_> slangasek, it obviously didnt work with unity8 on wed. so that libunity-mir1 vanished off the image
[17:28] <slangasek> ogra_: so, er, fix the code linkage, don't pile on kludges
[17:28] <ogra_> (which broke the world then)
[17:28] <sil2100> They were dlopen'ing libunity-mir1
[17:29] <slangasek> ok, that's a reason for not relying on shlibs
[17:29] <slangasek> but that's not the case here
[17:29] <sil2100> Let me check
[17:33] <sil2100> bfiller: I published 2 of your packages btw. - you can stay on a lookout for those being ready to clean up
[17:33] <bfiller> sil2100: thanks, will do
[17:37] <jdstrand> sil2100: ok, can you pull r2110 of QRT
[17:37] <jdstrand> sil2100: then instead of running '../run_test.sh click-apparmor', just run 'click-apparmor -d' directly
[17:39] <jdstrand> sil2100: do that in a loop until it fails. that should run 'click pkgdir' to get the symlink, run ls on it, then resolve it and run ls -ld on the dir, and ls -lR on the dir
[17:39] <jdstrand> sil2100: perhaps that will give us a clue as to what is happening
[17:42] <sil2100> jdstrand: I'll try, but I'll be sadly EOD'ing soon
[17:43] <jdstrand> ack
[17:49] <sil2100> jdstrand: runnin
[17:49] <sil2100> jdstrand: oh! Failures, a lot of them! On the first run
[17:50] <sil2100> Oh, wait, no
[17:52] <cjwatson> [6~
[17:52] <cjwatson> [6~
[17:52] <cjwatson> [6~
[17:52] <cjwatson> argh
[17:52] <cjwatson> need beer
[17:53] <ogra_> ++
[18:07] <sil2100> jdstrand: ok, I couldn't reproduce it yet
[18:07] <jdstrand> ok
[18:08] <sil2100> jdstrand: I'll keep trying when I'm at the hotel, but for now I guess I'll EOD to get something to eat
[18:08] <sil2100> jdstrand: thanks for all the help! :)
[18:08] <sil2100> jdstrand: it's a strange issue, but let's work on that again on Monday
[18:08] <jdstrand> sil2100: I feel like I didn't do much-- but hopefully the debugging will be enlightening
[18:08] <sil2100> Let's hope so
[18:09] <jdstrand> sil2100: have a nice weekend :)
[18:09] <sil2100> You too!
[18:31] <tedg> jdstrand, Anything exciting?
[18:32] <jdstrand> tedg: no. I updated the click-apparmor test to add a debug flag that would show the permissions of various files and directories. sil2100 tried it, but couldn't reproduce before he went eod
[18:33] <tedg> jdstrand, Interestingly the Jenkins run, in the app log, it says "pass" http://ci.ubuntu.com/smokeng/trusty/touch/mako/156:20140131:20140115.1/6364/security/719045/
[18:34] <jdstrand> where?
[18:34] <jdstrand> I see:
[18:34] <jdstrand> Click apparmor tests
[18:34] <jdstrand> Passed: 9/10
[18:34] <jdstrand> Failed: 1/10
[18:34] <jdstrand> ADB_RC=1
[18:35] <jdstrand> oh, in the app log
[18:35] <jdstrand> let me look at that
[18:35] <jdstrand> tedg: right, https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/artifact/clientlogs/application-click-com.example.am-i-confined_am-i-confined_0.1.log/*view*/ did pass, but https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-security/130/artifact/clientlogs/application-click-com.example.lp1245677_lp1245677_0.1.log/*view*/ did not
[18:36] <jdstrand> tedg: application-click-com.example.am-i-confined_am-i-confined_0.1.log vs application-click-com.example.lp1245677_lp1245677_0.1.log
[18:36] <tedg> Ah, I see
[18:38] <tedg> I proposed this merge, perhaps to get easier debug output next time.
[18:38] <tedg> https://code.launchpad.net/~ted/upstart-app-launch/print-exec-on-error/+merge/204285
[18:38] <tedg> Perhaps sil2100 can use that.
[18:41] <jdstrand> yeah
[18:42] <jdstrand> it sure is a weird issue
[18:42] <jdstrand> I let it run for an hour in a loop on grouper without any issues
[19:01] <ChrisTownsend> Hi, is anyone available to help with an issue I'm seeing on the Intel CI Autopilot machine?