Use the new toolkit unit test discover helper
Commit from Sugar Labs: Translation System by user cjl.: 398 of 398 messages translated (0 fuzzy).
Merge branch 'master' of github.com:sugarlabs/sugar
Commit from Sugar Labs: Translation System by user samybt.: 398 of 398 messages translated (0 fuzzy).
Bundle registry: Cleanup/clarify bundle installation

Management of bundle installs/upgrades was a mess, this attempts to
clean it up and sort it out.

It was not clear under which circumstances a bundle should be installed
via the bundle object vs via the bundle registry. The logical answer here
is that it should be done by the registry, so document why that is the case.

In bundleregistry, upgrade() seemed like it should be used for bundle
updates, but actually install() duplicated some of that logic in a slightly
different way. Touch up the upgrade logic in install(), remove upgrade(),
and add some documentation to make the situation clear.

The install() API differed between JournalEntryBundle, ActivityBundle and
ContentBundle. Eliminate the differences. JEB uid's are now stored at
initialization time, and the Bundle classes themselves choose the install
path (this does not vary when activities are installed this way).

The journal had two codepaths that dealt with activity installation/upgrade
(on arrival of the bundle in the datastore, and on resume)); unite them into
one and update for the above changes.
bundleregistry: Fix conflict between file monitoring and its own operations (#3707)

When an activity is installed via bundleregistry, it is effectively
registered twice: once by bundleregistry after installing it, and again
when the file operations monitor picked up the event.

This lead to error messages in the logs and occasional duplication
of activity icons in the home view.

Refactor the code slightly so that it is resilient and accepting that
some activities may try to be registered twice. To avoid the duplication
of icons, be more careful to only emit the bundle-added signal when we
really add the bundle.

Also clean up the installation of MIME types. The ActivityBundle class
does this, so there is no need for bundleregistry to do so.
Store content bundles in bundle registry

Previously, only activity bundles were maintained in the bundle registry.
Extend this to cover all kinds of "trackable" bundles, which in reality
just means the addition of content bundles.

This is needed in order to clean up the code and bundle API (as has happened
here) and to allow content bundle updates through the updater control
panel.
Move activity update code to jarabe.model

In preparation for implementing automatic/background activity updates,
move the code from an extension-specific model into jarabe.

The main update code is now in jarabe.model.update and the downloader
has been made generic and moved to jarabe.util.downloader. It now
downloads files into the temporary 'data' directory which is cleaned up
on every Sugar launch, avoiding leaving stale files around in failure
cases.
Push multiple PO files
Merge branch 'master' of github.com:sugarlabs/sugar
Push POT file
Revert "Push POT file"

This reverts commit 57de6045fdefa32f21c7857b2d57f43604774cd1.
Migrate sugar-install-bundle to sugar3 package.
Implement only the test target, not check

At the moment our tests requires to be run inside a clean
dbus/xvfb session, which is not always available where the
check target is used (for example in distcheck). Also when
running distcheck in buildbot we don't really want to run
tests again, since we just run them in the check step.

We might revisit this in the future but using a non standard
target is the easiest solution for now.
Use xz for distribution

It has better compression.
Release 0.99.0
Move activity update code to jarabe.model

In preparation for implementing automatic/background activity updates,
move the code from an extension-specific model into jarabe.

The main update code is now in jarabe.model.update and the downloader
has been made generic and moved to jarabe.util.downloader. It now
downloads files into the temporary 'data' directory which is cleaned up
on every Sugar launch, avoiding leaving stale files around in failure
cases.
Don't initialise GTK+/dbus thread support

These calls allow GTK+ and dbus to be used from other threads.
Sugar doesn't currently create any threads, so these calls aren't
needed.

This is useful for followup work where some main loop recursion
results in a function that is sometimes called with the GDK threads lock
held, and sometimes without it held. By disabling this threading support,
this lock (and the surrounding headache) goes away.

By not activating the threading lock, we should also have a minor
performance increase.

Threads can still be used if desired, but all GTK+ calls should be made
from the main thread. These functions have actually been deprecated
in GTK+ 3.6 as the developers have determined that "draw from one thread"
is the way to go.

The GLib.threads_init() call is still needed, as we do have users
that work with threads, so the GIL must be released accordingly. However it
can be removed once pygobject-3.10 is a requirement:
https://bugzilla.gnome.org/show_bug.cgi?id=686914
bundleregistry: Add asynchronous install capabilities

In preparation for automatic activity updates, add asynchronous install
capabilities to the bundleregistry.

The synchronous install implementation has been removed and is now a user
of the async API that waits for completion before returning.

In order to avoid painful corner cases, the bundleregistry maintains
a queue of bundles to install, and installs them one by one. Install is
done in another thread to not block the main one.

As the install thread requires brief access to the list of bundles in the
bundle registry, all accesses to bundleregistry._bundles are now serialized
with a lock.
updater: asynchronously update bundles

This means that we unblock the main thread, a crucial step
towards offering automatic background activity updates.