news aggregator

Martin Pitt: deb, click, schroot, LXC, QEMU, phone, cloud: One autopkgtest to Rule Them All!

Planet Ubuntu - Tue, 2014-07-01 15:15

We currently use completely different methods and tools of building test beds and running tests for Debian vs. Click packages, for normal uploads vs. CI airline landings vs. upstream project merge proposal testing, and keep lots of knowledge about Click package test metadata external and not easily accessible/discoverable.

Today I released autopkgtest 3.0 (and 3.0.1 with a few minor updates) which is a major milestone in unifying how we run package tests both locally and in production CI. The goals of this are:

  • Keep all test metadata, such as test dependencies, commands to run the test etc., in the project/package source itself instead of external. We have had that for a long time for Debian packages with DEP-8 and debian/tests/control, but not yet for Ubuntu’s Click packages.
  • Use the same tools for Debian and Click packages to simplify what developers have to know about and to reduce the amount of test infrastructure code to maintain.
  • Use the exact same testbeds and test runners in production CI than what developers use locally, so that you can reproduce and investigate failures.
  • Re-use the existing autopkgtest capabilities for using various kinds of testbeds, and conversely, making all new testbed types immediately available to all package formats.
  • Stop putting tests into the Ubuntu archive as packages (such as mediaplayer-app-autopilot). This just adds packaging and archive space overhead and also makes updating tests a lot harder and taking longer than it should.

So, let’s dive into the new features!

New runner: adt-virt-ssh

We want to run tests on real hardware such as a laptop of a particular brand with a particular graphics card, or an Ubuntu phone. We also want to restructure our current CI machinery to run tests on a real OpenStack cloud and gradually get rid of our hand-maintained QA lab with its test machines. While these use cases seem rather different, they both have in common that there is an already existing machine which is pretty much only accessible with ssh. Once you have an ssh connection, they look pretty much the same, you just need different initial setup (like fiddling with adb, calling nova boot, etc.) to prepare them.

So the new adt-virt-ssh runner factorizes all the common bits such as communicating with adt-run, auto-detecting sudo availability, doing SSH connection sharing etc., and delegates the target specific bits to a “setup script”. E. g. we could specify --setup-script ssh-setup-nova or --setup-script ssh-setup-adb which would then get called with open at the appropriate time by adt-run; it calls the nova commands to create a VM, or run a few adb commands to install/start ssh and install the public key. Then autopkgtest does its thing, and eventually calls the script with cleanup again. The actual protocol is a bit more involved (see manpage), but that’s the general idea.

autopkgtest now ships readymade scripts for these two use cases. So you could e. g. run the libpng tests in a temporary cloud VM:

# if you don't have one, create it with "nova keypair-create" $ nova keypair-list [...] | pitti | 9f:31:cf:78:50:4f:42:04:7a:87:d7:2a:75:5e:46:56 | # find a suitable image $ nova image-list [...] | ca2e362c-62c9-4c0d-82a6-5d6a37fcb251 | Ubuntu Server 14.04 LTS (amd64 20140607.1) - Partner Image | ACTIVE | $ nova flavor-list [...] | 100 | standard.xsmall | 1024 | 10 | 10 | | 1 | 1.0 | N/A | # now run the tests: please be patient, this takes a few mins! $ adt-run libpng --setup-commands="apt-get update" --- ssh -s /usr/share/autopkgtest/ssh-setup/nova -- \ -f standard.xsmall -i ca2e362c-62c9-4c0d-82a6-5d6a37fcb251 -k pitti [...] adt-run [16:23:16]: test build: - - - - - - - - - - results - - - - - - - - - - build PASS adt-run: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ tests done.

Please see man adt-virt-ssh for details how to use it and how to write setup scripts. There is also a commented /usr/share/autopkgtest/ssh-setup/SKELETON template for writing your own for your use cases. You can also not use any setup script and just specify user and host name as options, but please remember that the ssh runner cannot clean up after itself, so never use this on important machines which you can’t reset/reinstall!

Test dependency installation without apt/root

Ubuntu phones with system images have a read-only file system where you can’t install test dependencies with apt. A similar case is using the “null” runner without root. When apt-get install is not available, autopkgtest now has a reduced fallback mode: it downloads the required test dependencies, unpacks them into a temporary directory, and runs the tests with $PATH, $PYTHONPATH, $GI_TYPELIB_PATH, etc. pointing to the unpacked temp dir. Of course this only works for packages which are relocatable in that way, i. e. libraries, Python modules, or command line tools; it will totally fail for things which look for config files, plugins etc. in hardcoded directory paths. But it’s good enough for the purposes of Click package testing such as installing autopilot, libautopilot-qt etc.

Click package support

autopkgtest now recognizes click source directories and *.click package arguments, and introduces a new test metadata specification syntax in a click package manifest. This is similar in spirit and capabilities to DEP-8 debian/tests/control, except that it’s using JSON:

"x-test": { "unit": "tests/unittests", "smoke": { "path": "tests/smoketest", "depends": ["shunit2", "moreutils"], "restrictions": ["allow-stderr"] }, "another": { "command": "echo hello > /tmp/world.txt" } }

For convenience, there is also some magic to make running autopilot tests particularly simple. E. g. our existing click packages usually specify something like

"x-test": { "autopilot": "ubuntu_calculator_app" }

which is enough to “do what I mean”, i. e. implicitly add the autopilot test depends and run autopilot with the specified test module name. You can specify your own dependencies and/or commands, and restrictions etc., of course.

So with this, and the previous support for non-apt test dependencies and the ssh runner, we can put all this together to run the tests for e. g. the Ubuntu calculator app on the phone:

$ bzr branch lp:ubuntu-calculator-app # built straight from that branch; TODO: where is the official" download URL? $ wget http://people.canonical.com/~pitti/tmp/com.ubuntu.calculator_1.3.283_all.click $ adt-run ubuntu-calculator-app/ com.ubuntu.calculator_1.3.283_all.click --- \ ssh -s /usr/share/autopkgtest/ssh-setup/adb [..] Traceback (most recent call last): File "/tmp/adt-run.KfY5bG/tree/tests/autopilot/ubuntu_calculator_app/tests/test_simple_page.py", line 93, in test_divide_with_infinity_length_result_number self._assert_result("0.33333333") File "/tmp/adt-run.KfY5bG/tree/tests/autopilot/ubuntu_calculator_app/tests/test_simple_page.py", line 63, in _assert_result self.main_view.get_result, Eventually(Equals(expected_result))) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 406, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: After 10.0 seconds test failed: '0.33333333' != '0.3' Ran 33 tests in 295.586s FAILED (failures=1)

Note that the current adb ssh setup script deals with some things like applying the autopilot click AppArmor hooks and disabling screen dimming, but it does not do the first-time setup (connecting to network, doing the gesture intro) and unlocking the screen. These are still on the TODO list, but I need to find out how to do these properly. Help appreciated!

Click app tests in schroot/containers

But, that’s not the only thing you can do! autopkgtest has all these other runners, so why not try and run them in a schroot or container? To emulate the environment of an Ubuntu Touch session I wrote a --setup-commands script:

adt-run --setup-commands /usr/share/autopkgtest/setup-commands/ubuntu-touch-session \ ubuntu-calculator-app/ com.ubuntu.calculator_1.3.283_all.click --- schroot utopic

This will actually work in the sense of running (and succeeding) the autopilot tests, but it will fail due to a lot of libust[11345/11358]: Error: Error opening shm /lttng-ust-wait... warnings on stderr. I don’t know what these mean, just that I also see them on the phone itself occasionally.

I also wrote another setup-commands script which emulates “read-only apt”, so that you can test the “unpack only” fallback. So you could prepare a container with click and the App framework preinstalled (so that it doesn’t always take ages to install them), starting from a standard adt-build-lxc container:

$ sudo lxc-clone -o adt-utopic -n click $ sudo lxc-start -n click # run "sudo apt-get install click ubuntu-sdk-libs ubuntu-app-launch-tools" there # then "sudo powerdown" # current apparmor profile doesn't allow remounting something read-only $ echo "lxc.aa_profile = unconfined" | sudo tee -a /var/lib/lxc/click/config

Now that container has enough stuff preinstalled to be reasonably fast to set up, and the remaining test dependencies (mostly autopilot) work fine with the unpack/$*_PATH fallback:

$ adt-run --setup-commands /usr/share/autopkgtest/setup-commands/ubuntu-touch-session \ --setup-commands /usr/share/autopkgtest/setup-commands/ro-apt \ ubuntu-calculator-app/ com.ubuntu.calculator_1.3.283_all.click \ --- lxc -es click

This will successfully run all the tests, and provided you have apt-cacher-ng installed, it only takes a few seconds to set up. This might be a nice thing to do on merge proposals, if you don’t have an actual phone at hand, or don’t want to clutter it up.

autopkgtest 3.0.1 will be available in Utopic tomorrow (through autosyncs). If you can’t wait to try it out, download it from my people.c.c page ☺.

Feedback appreciated!

José Antonio Rey: FOSSETCON in Florida – Coming Next September!

Planet Ubuntu - Tue, 2014-07-01 04:20

Next September, from the 11th to the 13th, FOSSETCON will be held in the Rosen Plaza, in Orlando, Florida.

FOSSETCON stands for Free and Open Source Software Expo and Technology Conference. Organized by the awesome Bryan Smith, it will have a variety of workshops, talks, certifications, and a HUGE Expo Hall, where even the Ubuntu community will be featured! If you want your company to be featured during the conference, this is the perfect place to apply to be a sponsor. On the other hand, if you want to see many awesome things with regards to the Free and Open Source world and it’s close to you, then it’s the right place for you! Plus, attendees get a special discount in their tickets for Universal Studios parks, and more deals coming ;)

If you are planning to be around make sure to visit the Ubuntu booth, there’s still plenty of time to plan your trip!


Ubuntu App Developer Blog: Core Apps Hack Days Starts Now

Planet Ubuntu - Mon, 2014-06-30 14:45

As previously blogged we’re inviting the community to hack on Core Apps and Community Apps this week.

All the details are in the post above, but here’s the executive summary:-

  • Hack days run from 30th June till 4th July
  • We’re hacking on the Core Apps Music, Calendar, Calendar, Clock, Weather & Calculator
  • In addition we’re also hacking on community apps including Beru Ebook Reader, OSM Touch mapping software, and Trojita email client
  • Join us in the #ubuntu-app-devel IRC channel on freenode, and on the ubuntu-phone mailing list to get started
  • Get all the details from the hack days wiki page

As always we welcome new contributions during the Hack Days, but also beyond that.

Lubuntu Blog: LXQt now has “full” Qt5 support

Planet Ubuntu - Mon, 2014-06-30 11:17
Repost from LXDE Blog: After the first official public release 0.7, the LXQt team is working on making it better. Our recent focus is fixing existing bugs and migrating from Qt4 to Qt5, which is required if we want to support Wayland. Now we had something to show. The latest source code in our git repository can be compiled with Qt5 (by just passing -DUSE_QT5=ON flag to cmake). Building with

Riccardo Padovani: How to know proprieties and values of an object in QML

Planet Ubuntu - Mon, 2014-06-30 07:00

Hi all,
few days ago, working on an app for Ubuntu for Phones I needed to know all proprieties and values of an object during the execution of the app.
It’s a very easy thing to do, but a bit boring to write the code to debug every time, so I wrote a little function to do this, with formattation of the output.

Hope it will be useful to someone :-)

So, to call the function we only need to write debug (objectId, 0) whenever we need to debug an object.
0 is because it’s a recursive function, and it indicates the level of formattation

function debug(id, level) { function debug(id, level) { var level_string = '';   // If isn't a first level function, add some formattation for (var i = 0; i < level; i++) { if (i+1 === level) { level_string += '|--------'; } else { level_string += ' '; } }   if (level === 0) { level_string = 'property '; } else { level_string += '> '; }   // For every value in the object for (var value in id) {   // We need to don't take care of these elements because the output is too long. I mean, do you want to print all children of the parent? :-) // If you are interesting in the output of anchors, set a maximum to leveles of recursion if (value != 'parent' && value != 'anchors' && value != 'data' && value != 'resources' && value != 'children') { // Functions haven't children and aren't property if (typeof(id[value]) === 'function') { if (level === 0) { console.log('function ' + value + '()'); } else { console.log(level_string + 'function ' + value + '()'); } } // Objects have children else if (typeof(id[value]) === 'object') { console.log(level_string + value + ' [object]'); debug(id[value], level+1); } // Of all others things we print value and type :-) else { console.log(level_string + value + ': ' + id[value] + ' [' + typeof(id[value]) + ']'); } } } }

Ciao,
R.

This work is licensed under Creative Commons Attribution 3.0 Unported

Pages

Subscribe to Free Software Magazine aggregator