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