[04:13] <Philip> hey i need some help
[04:15] <Philip> i am using linux 14.04 LTS how can i give full permission to user like a root
[09:49] <rhuddie> pitti, good morning :)
[09:50] <rhuddie> pitti, could you have a look at this error log I am getting with adt-run? http://pastebin.ubuntu.com/9681217/
[09:51] <pitti> rhuddie: your test bed didn't run apt-get update recently
[09:51] <pitti> rhuddie: probably best to create a fresh one or dist-upgrade it
[09:52] <pitti> rhuddie: or, if there is no newer image, at least run "sudo apt-get update"
[09:52] <pitti> rhuddie: you could do something like
[09:52] <rhuddie> pitti, this is a read-only test-bed, does that make a difference?
[09:52] <pitti> --setup-commands "mount -o remount,rw /; apt-get update; mount -o remount,ro /"
[09:53] <pitti> rhuddie: yes, it's a bit awkward, but not much that we can do -- the old apt indexes that are on the r/o image just won't work as the old package versions are gone from archive.u.c.
[09:53] <rhuddie> pitti, thank you, let me give that a try
[09:53] <pitti> rhuddie: the above will temporarily make the image r/w, run apt-get update, and make it r/o again
[09:54] <rhuddie> pitti, yes, as you say I don't see much else we could do
[09:58] <rhuddie> pitti, that is working now, thank you :)
[09:58] <pitti> nice
[10:43] <rhuddie> pitti, I have now moved onto the next problem...
[10:45] <rhuddie> pitti, I am writing a test that uses imagemagick. However when I run the test with adt-run and install imagemagick the binaries get installed to: /tmp/adt-run.mVs3yf/deps/usr/lib/arm-linux-gnueabihf/ImageMagick-6.8.9/bin-Q16
[10:45] <rhuddie> and they are not found when I want to call them from my test
[10:46] <rhuddie> so, it seems I either need to add that directory to my path, or copy the binaries into another directory. But just wondering if you have any suggestion how to deal with this problem?
[10:47] <pitti> rhuddie: it seems imagemagick changed in a strange way; but those in lib/.../bin-Q16/ wouldn't be in the $PATH for a regular system eitehr
[10:47] <pitti> rhuddie: those are the files from the  imagemagick-6.q16 package; perhaps you want to use the ones from imagemagick, like usr/bin/mogrify-im6?
[10:48] <pitti> lrwxrwxrwx 1 root root 25 Nov 20 11:47 /usr/bin/mogrify -> /etc/alternatives/mogrify
[10:48] <pitti> lrwxrwxrwx 1 root root 20 Nov 20 11:47 /etc/alternatives/mogrify -> /usr/bin/mogrify-im6
[10:48] <pitti> rhuddie: alternatives obviously don't work with the "unpack into temp dir" approach, but the -im6 ones should be fine
[10:48] <rhuddie> pitti, I'll check out the -im6 ones
[10:48] <pitti> rhuddie: (note, I don't have the slightest idea about this odd layout/naming -- seems some transition is going on?)
[10:49] <pitti> " This version of imagemagick is compiled for quantum depth of 16 bits.
[10:49] <pitti> now, that doesn't tell me *anything*
[10:49] <rhuddie> pitti, yes, seems very strange :)
[10:50] <pitti> Perhaps with those you can better align the quantum field phases in the warp field coils
[11:53] <rhuddie> pitti, using convert-im6, I get the following error: convert-im6: error while loading shared libraries: libMagickCore-6.Q16.so.2: cannot open shared object file: No such file or directory
[11:54] <rhuddie> pitti, the file itself is located here: /tmp/adt-run.cdEia7/deps/usr/lib/arm-linux-gnueabihf/libMagickCore-6.Q16.so.2.0.0
[11:55] <pitti> rhuddie: that ought to work; can you please file a bug about  it?
[11:55] <rhuddie> pitti, sure
[11:55] <pitti> rhuddie: oh the fun of using deb packages on a platform that says "don't use deb packages" :)
[11:56] <rhuddie> pitti, :)
[14:21] <elopio> good morning.
[14:36] <elopio> rhuddie: trying your apt-get update branch. Thanks for that.
[14:36] <rhuddie> elopio, oh good, hopefully you should have no problems
[14:37] <elopio> rhuddie: I'll let you know.
[14:37] <elopio> rhuddie: I found that the test that gets stuck in rtm is the wizard one. During launch_unity.
[14:38] <elopio> now I'm not quite sure if it ever worked on rtm. I think I tried it, but last year is a blur :)
[14:38] <rhuddie> elopio, oh. that is strange, I don't think I'm doing anything special there
[14:39] <elopio> I will give it a try on vivid if this update works. Then more debugging.
[14:39] <rhuddie> elopio, I've also been looking querying the device's features
[14:40] <rhuddie> what I have is a set of features defined for a device and a platform version, e.g. mako and vivid
[14:41] <rhuddie> then I import them using importlib.import_module() which allows you to import a module using a variable name
[14:42] <rhuddie> so you can then combine the 2 values to work out if a specific feature should work on a device/platform combination
[14:42] <elopio> rhuddie: that sounds cool. I'm not sure how it looks like, but I'm sure it will be useful.
[14:43] <rhuddie> elopio, but I was thinking if we have a feature list defined for a device (even by codename) wouldn't that be a confidentiality problem?
[14:44] <elopio> rhuddie: the ubuntu_sanity_test project is private. I don't like it, and I don't know why thomi made it that way, but that's what we have now.
[14:44] <rhuddie> elopio, ok. well in this case I guess that would be useful :)
[14:46] <elopio> rhuddie: yes. Later I will try to make it public, so it's good that you bring that now. We can ask to the guys that work with the partners with a better view of what we will publish
[14:47] <elopio> rhuddie: the update branch installed all the debs, and the wizard test passed.
[14:47] <elopio> alesage: can you give the second review to that branch, please?
[14:48] <elopio> https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/apt-get-update/+merge/245632
[14:48] <rhuddie> elopio, super
[14:50] <elopio> rhuddie, alesage: for cases when a test goes crazy we need to set a timeout. We can do it per test, or per run, it's easy. The hard part is to find a suitable number of seconds.
[14:50] <elopio> should I set something like 5 minutes more than the average it currently takes, and we update it as we add more tests?
[14:52] <rhuddie> elopio, I've noticed that re-starting unity8 can sometimes take quite a long time, which makes it difficult to timeout each test
[14:53] <elopio> rhuddie: yes, per test doesn't sound so good, because we currently can't set a different timeout for each test.
[14:54] <rhuddie> elopio, can we run tests individually yet? If we could do that we would need a way to specify smaller timeouts
[14:55] <elopio> we run individually the external tests. We could extend that text file to include a column for timeout.
[14:55] <elopio> we currently run all the internal tests with one single autopilot command. We could also extend it to run them one by one, and maybe add a variable for the timeout.
[14:56] <elopio> that may turn a little messy. But it's doable.
[14:56] <rhuddie> elopio, so perhaps we should set a default value of say 2 minutes per test, and provide some method to over-ride it for longer tests?
[14:56] <elopio> a better solution could be to define a timeout variable in the base autopilot test case, and implement the code in autopilot that respects that timeout.
[14:59] <elopio> rhuddie: yes, that sounds nice. I will add cards for that, and as a quick-n-dirty solution for this week I'll set a timeout of maybe 10 minutes for the whole run.
[14:59] <rhuddie> elopio, I did a timeout on the video playback tests similar to that. It is pretty simple
[14:59] <elopio> rhuddie: can you show me the code?
[15:00] <rhuddie> for the online video you obviously don't know how long they are going to be so I set a 10 second playback timeout
[15:00] <rhuddie> let me find it
[15:01] <rhuddie> https://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/video-autopilot/view/head:/ubuntu_sanity_tests/tests/test_videos.py#L92
[15:02] <rhuddie> elopio, when the timer is fired, it just sets a flag to indicate it has timed out. The test then checks that value.
[15:09] <elopio> rhuddie: I think we can do something more general with fixtures now. See http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py#L129
[15:10] <elopio> I can do two quick things. Wrap launch_unity in that timeout fixture, which will solve our immediate problem, and is like what you are doing for the video tests.
[15:11] <elopio> or I could make a fixture that overwrites the test_timeout global value for the duration of the test. Then each test can define its timeout.
[15:11] <elopio> I'm not sure thomi and veebers are going to like that one.
[15:16] <rhuddie> elopio, yes, sounds like a good discussion
[16:44] <balloons> elopio, do you have the bug about needing to update the template for autopilot in the sdk
[16:45] <elopio> balloons: I'm not sure if there is one.
[16:45] <balloons> elopio, your old branch / mp then perhaps?
[16:46] <elopio> balloons: https://code.launchpad.net/~elopio/qtcreator-plugin-ubuntu/update_tabs_autopilot_template/+merge/225256
[16:46] <balloons> ty
[18:56] <elopio> balloons: can we now install click packages on desktop?
[18:58] <elopio> nevermind, I found it.
[18:58] <elopio> sudo click install --user
[18:59] <balloons> aye
[19:23] <elopio> balloons: how do we dbus-probe enable on the desktop?
[19:32] <balloons> elopio, lol.. we don't have aa rules so we shouldn't need it afaik
[19:33] <elopio> balloons: it's not finding the introspection things
[19:34] <balloons> elopio, on unity8?
[19:34] <elopio> balloons: yes
[19:39] <balloons> elopio, you could ask.. i'd be curious to know also
[19:39] <balloons> elopio, you could turn off apparmor i guess to confirm it's not blocking
[19:51] <balloons> hey Letozaf_
[19:51] <Letozaf_> balloons, hey, how are you ?
[19:53] <balloons> hanging in there. i have something for you to look at if you are able
[19:53] <Letozaf_> balloons, ok what?
[19:53]  * Letozaf_ is curious
[19:54] <balloons> Letozaf_, Roman needs help with this mp: https://code.launchpad.net/~mrqtros/ubuntu-rssreader-app/ubuntu-rssreader-app-new-devel-period/+merge/244656
[19:54] <balloons> good old rssreader
[19:54] <Letozaf_> balloons, oh, yes, good old rssreader
[19:54]  * Letozaf_ is looking a the mp
[19:55] <balloons> if you could help, it would be most excellent
[19:55] <balloons> did you have a good holiday?
[19:56] <balloons> i had too much fun, heh, and injured myself
[19:56] <Letozaf_> balloons, sure I will try to help, I had quite nice holidays slept a lot :-P
[19:57] <balloons> Letozaf_, feel free to ping or ask roman if you have questions. i'll be back in a bit
[19:57] <Letozaf_> balloons, yeah I read it on Google + are you alright now ?
[19:57] <balloons> no, quite injured still. hunt and peck to type
[19:57] <balloons> it's frustrating for me.. i'll have to learn humulity and patience
[19:57] <Letozaf_> balloons, :( sorry, hope you recover soon
[19:58] <balloons> me too :--)
[19:58] <balloons> glad to hear things went well for you.. i had a nice time besides the injury
[19:59] <Letozaf_> balloons, I am glad you enjoyed yourself, as I said I needed good sleeps and did so, so for me they were good holidays too, stayed with my family
[19:59] <Letozaf_> balloons, ok, so let me look at the mp
[20:00] <elopio> balloons: yes, I ran the dbus command on desktop and tests work.
[20:00] <elopio> I suppose we need to move that from phablet-tools to autopilot
[20:01] <doug5> balloons, mp for you
[20:12] <Letozaf_> ls -l
[20:12] <Letozaf_> ooops :-P wrong window :-P
[20:18] <Letozaf_> balloons, I had already fixed one of the problems during holidays: https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/fixed-tests-for-feed-checkbox
[20:19] <Letozaf_> balloons, this should fix the checkbox not being selected while adding a new feed in various tests
[20:20] <Letozaf_> balloons, and I had also fixed the edit topic test that was skipped: https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/fixed-test-edit-topic
[20:21] <Letozaf_> balloons, oh wait, the latter needs fixing... so if you could merge the first I will check what else is wrong
[20:24] <Letozaf_> elfy, knome, doug5 dkessel  hello everyone o/
[20:25] <elfy> hi Letozaf_ - happy new year to you :)
[20:25] <Letozaf_> elfy, happy new year to you too :-)
[20:25] <elfy> ty :)
[20:33] <knome> hello Letozaf_
[20:34] <Letozaf_> knome, hello happy new year :)
[20:34] <knome> you too
[20:34] <Letozaf_> knome, ty :)
[20:34] <doug5> Letozaf_, hellooo! :)
[20:37] <Letozaf_> doug5, hi, happy new year :)
[20:37] <doug5> Letozaf_, you too :)
[20:37] <Letozaf_> doug5, ty
[21:11] <elopio> alesage: hey, can you please update me on the status of the system settings introspection error?
[21:12] <alesage> elopio, hi, just finishing lunch
[21:12] <alesage> elopio, waiting on a Jenkins build
[21:13] <alesage> elopio, here is the latest https://code.launchpad.net/~allanlesage/ubuntu-system-settings/testing-ignore-me-many-prints-in-setup/+merge/245684
[21:14] <elopio> alesage: cool, thanks.
[21:15] <alesage> elopio, any strategic advice there?
[21:15] <elopio> alesage: are you able to reproduce the failure locally, on desktop or the phone?
[21:16] <alesage> elopio, no this failure occurs only on Jenkins
[21:18] <elopio> alesage: then I would start skipping test modules one by one, until it goes to green.
[21:19] <alesage> elopio yes it's a bit of a mess, as a couple of failures are in trunk now, not clear how they got in  https://code.launchpad.net/ubuntu-system-settings
[21:19] <elopio> make three runs, to make sure it's actually green and stable.
[21:19] <elopio> then two things can happen. If you add them one by one, and you spot the one that causes the error, that's the easy case. You can start skipping individual tests or statements.
[21:20] <elopio> the hard case is when you add them one by one and things go crazy. That probably means that the problem is with the order of the tests or something is leaving a dirty environment sometimes.
[21:20] <alesage> elopio, here's a failure that's more recent, wonder if this looks familiar https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/565/testReport/junit/ubuntu_system_settings.tests.test_about/AboutTestCase/test_settings_show_correct_version_of_the_os/
[21:21] <alesage> elopio, I'm pretty sure it's in the setUp for the sound settings, as a sound test always makes a failure but not always the same test (e.g. when they're re-ordered)
[21:21] <elopio> alesage: yes. That sounds like a problem with the autopilot cache. It might be using a generic custom proxy object instead of the one corresponding to that page.
[21:22] <elopio> actually, I'm almost sure it's that. There is a mess with the validate_dbus_object details, so if you ever select a PageComponent that has no custom proxy object, it will remain on the cache making the following tests fail.
[21:23] <alesage> elopio, ok hmm, that sounds difficult
[21:23] <alesage> elopio, is there a bug for that specific issue?
[21:24] <elopio> alesage: https://bugs.launchpad.net/autopilot/+bug/1350532
[21:25] <elopio> might not be exactly the same, as your test is not saying that there are two classes.
[21:25] <elopio> but it's definitely using PageComponent as the CPO, instead of the right class for that specific page.
[21:26] <elopio> alesage: it shouldn't be that hard. An error like that one can't be specific to jenkins. It will happen everywhere.
[21:26] <alesage> elopio, I see, so my short-term remedy might be to correct the test to the proper name
[21:26] <alesage> elopio, ack
[21:27] <elopio> alesage: put a breackpoint on the place where self.about_page gets instantiated. That will tell you why it's using PageComponent, instead of AboutPage or whatever it's named.
[21:27] <alesage> elopio, gotcha thx
[21:28] <elopio> alesage: if you are still stuck tomorrow, I will have time to try debugging it. Let me know how it goes.
[21:28] <alesage> elopio, k thx