Most testing of the Application Manager is done by installing/updating/removing packages that are in a specially prepared test repository. There are also a number of standalone packages and a number of ".install" files.
The test repository is only available via HTTP:
The easiest way to configure the Application Manager for the test
repository is to use this .install file:
It will add many new catalogues, and then install the "testrepo-conf" package which performs additional actions to configure the system for testing.
After installing one this file, you need to restart the Application Manager, disable the two "New" distributions and execute "Tools > Refresh application list".
The test repository contains six distributions:
"Testrepo certified"
This distribution belongs to a domain that is certified. Installing packages from it should not show the big fat warning.
"Testrepo certified new"
This distribution has newer versions of the packages in "Testrepo certified".
"Testrepo trusted old"
This distribution belongs to a separate, but non-certified domain.
"Testrepo trusted new"
This distribution belongs to the same domain as "Testrepo trusted old". Thus, you should be able to update packages that you got from "Testrepo trusted old" with newer versions from this distribution.
"Testrepo trusted uri"
This distribution belongs to a separate, but non-certified domain. This domain is identified by the URI of the repository, not the signing key.
"Testrepo old"
This is a distribution that belongs to no specific domain. It contains the bulk of the test packages.
"Testrepo new"
This distribution contains newer versions of some of the packages in "Testrepo old".
"Testrepo demo"
This distribution is for use with some .install files.
You can switch between the "new" and "old" distributions by enabling one of them and disabling the other, obviously.
The packages and the distributions they are in:
certified 1 (cert), certified 2 (cert-new)
The only package in the cert distribution. Installing it
should not show the disclaimer dialog. You can also update it to
version 2 and it shows up in the update notifier menu as a
"Nokia" application.
trusted 1 (trusted-old), trusted 2 (trusted-new), trusted 2.alien (new)
A simple package to test updating with and without crossing domain boundaries.
package-A 1 (old), package-A 2 (new)
Standalone package that depends on nothing and conflicts with nothing. You can use it to test basic installation, upgrading and uninstallation.
To test upgrading, first install version 1 from old, then switch
to new. Package-A version 2 should be listed in the "Check for
updates" view.
package-B 1 (old), package-B 2 (new)
Conflicts with package-A 1 (but no other version of package-A). You can use it together with package-A to test the behavior when conflicts are present. It must not be possible to install package-A version 1 and package B at the same time. You can install package-A version 2 and package-B at the same time, however.
package-C 1 (old), package-C 2.cr (new)
Depends on package-B, any version. You can use it to test dependencies between packages, and indirect conflicts.
When package-A version 1 and package-B are not installed, installing package-C should automatically install package-B as well.
When package-A version 1 is installed (and consequently, package-B is not installed), installing package-C should not be possible, listing package-A as the reason.
The file for package-C version 2.cr is corrupted and can not be installed.
package-D 1 (old, new)
Depends on package missing, which is not in the repository.
package-E 1 (old) package-E 2 (new)
Package-e version one has no dependencies, but package 2 version
2 depends on missing, which is not in the repository.
package-1 0 (old, new)
A package with a real program in it. Installing it will pop up the "Select Location Dialog" to let the user choose a location in the menu.
package-2 0 (old, new)
A package with a real program in it and a 'checkrm` script. If you uninstall this package while the contained program is running, the uninstallation should be cancelled automatically.
borken 1 (old, new)
A broken packages whose maintainer scripts will always fail.
licensed 0 (old, new)
A package where the user needs to agree to a license before being allowed to use it.
big 0 (old)
A package that contains one big, useless file.
corrupted 1 (old, new)
A package whose archive file is corrupted.
sized-5k 1, sized-50k 1, sized-500k 1, sized-5m 1, sized-50m 1, sized-500m 1, sized-1500m 1, sized-3g 1 (old)
Packages that claim to have the indicated Installed-Size. They are actually empty and wont trigger any out of memory condition. You can use them to test the display of file sizes.
user1 1, user2 1, system 1 (old, new)
The user1 and user2 packages both depend on the system package. User1 and user2 are 'user' packages (shown in the UI), while system is a 'non-user' package (not shown in the UI).
user3 1, user4 1, oldsystem 1 (old)
user3 2, user4 1, newsystem 1 (new)
The user3 package depends on oldsystem in version 1, and on newsystem inversion 2. newsystem conflicts with and replaces oldsystem. user4 depends on oldsystem.
stuck 1 (old, new)
This package takes one minute in its postinst script.
notfound 1 (old, new)
This package is listed in the indices but the actual archive file has been deleted from the repository.
docs 1 (old, new)
This package contains files in /usr/share/{doc,man,info} and can
be used to test docpurge.
flag-all, flag-close-apps, flag-suggest-backup, flag-reboot, flag-system-update 1 (old), flag-system-update 2 (new)
These packages have the indicated Maemo-Flags set. For example, flag-reboot has the "reboot" flag set and the AM should reboot the device after installingh it.
Note that flag-system-update will not be shown by the AM unless it is already installed.
needs-50M, needs-500M, needs-5G, needs-50G (old)
These packages have the indicated size in their Maemo-Required-Free-Space field.
display-name (old)
This package has a pretty, localized name. (It is only translated to de_DE, tho.)
upgrade-description 1 (old), upgrade-description 2 (new)
This package uses the 'Maemo-Upgrade-Description' feature that allows a different description to be displayed when the user is considering the package for updating. The upgrade description is translated for de_DE.
application 1 (old), application 2 (new), application-two 1 (old), application-two 2 (new), library 1 (old), library 2 (new)
These are two 'application' packages that depend on a user-visible library. All three packages are available in two versions. You can use them for testing the "Update All" operation, for example.
test-operating-system 1 (old), test-operating-system 2 (new), test-kernel-image 1 (new)
The 'test-operating-system' package is a simple meta package as it would be used for Operating System updates. The 'test-kernel-image' flashes a new kernel and initfs and will be installed by the test-operating-system package version 2.
strict 1 (old, new)
This package depends on "package-a (= 1)".
lockdown 1 (old), lockdown 2 (new)
The lockdown package is a small package similar to the OS metapackage. It depends on exactly one version of the invisible "system" package. Version 1 of lockdown depends on version 1 of system, and lockdown 2 depends on system 2.
The server with the test repository also contains a number of .deb
files that can be used to test the "Install from file" feature. The
files can be found
here.
You can open them directly with the browser or copy them to your device and open them with the File manager or via "Package / Install from file".
These standalone .deb files are available:
incompatible-arch_1_powerpc.deb
This package is incompatible because it is for the "powerpc" architecture.
incompatible-current_1_all.deb
This package is incompatible because it depends on "maemo", which is a sign for packages that have been made for IT-2005.
This package is incompatible because it is not a user package.
This packages has no "Section:" field.
Test package A, version two, for powerpc.
The server with the test repository also contains .install files.
These files contain instructions for the Application Manager to add
repositories and/or install a package. The files can be found on
here.
You can open them directly with the browser or copy them to your device and open them with the File manager or via "Package / Install from file".
These .install files are available:
Installs the demo package from the demo distribution.
Same as demo.install, but uses the legacy syntax.
Adds the demo distribution to the list of configured sources.
Same as demo-catalogue.install, but uses the legacy syntax.
Installs the demo package from the demo distribution. However,
it doesn't declare itself to be compatible with maemo 3.0.
Contains a malformed "deb" line and should be refused by the Application Manager with an error message.
Installs the demo package from the demo distribution and also
configures the old distribution.
Installs or enables the official "Extras" repository on maemo.org.
The Application Manager can use repositories that are accessible in the local filesystem, such as on a memory card.
To test this, you can untar the
cardrepos.tar.gz
archive to your memory card or to your internal flash and then open
the card-old.install and/or card-new.install files.
The archive contains two repositories, cardrepo-old and
cardrepo-new. These packages are available:
card-1 1 (old), card-1 2 (new)
A package without dependencies.
card-2 1 (old), card-2 2 (new)
card-system 1 (old, new)
The card-2 package depends on card-system.
card-3 1 (old), card-3 2 (new)
The card-3 package depends on card-2.
Some test cases below ask you to break a package in a specific way in order to test whether the Application Manager can fix them again.
These broken packages normally result from interrupted installations, such as when the device reboots in the middle of an operation or when you take out the MMC at the wrong time.
For testing the behavior of the Application Manager, it is sufficient to trick dpkg into thinking that the package is in a intermediate state. It is not necessary to actually interrupt the installation.
A simple way to modify the state of a package is to edit
/var/lib/dpkg/status. However that file is too big for the nimble
busybox vi. Therefore, the following method is recommended.
dpkg
--status PACKAGE >status.broken (feel free to use a filename different
from status.broken, of course).
Status: line in it to read
Status: install reinstreq half-installed
/var/lib/dpkg/updates/0000
dpkg --configure -a in a terminal.
dpkg --status PACKAGE to verify the new status.
You can reuse the status.broken file when you run the test case again.
Here are some test cases you can do with the packages in the test repository.
old distribution.
new distribution.
old distribution.
old distribution.
old distribution.
old distribution.
new distribution.
old distribution.
cert distribution.
system is not installed by running dpkg --status system in a terminal, for example.
user1
user1 and system are being installed.
user1
user1 and system are being removed.
system is not installed by running dpkg --status system in a terminal, for example.
user1
user1 and system are being installed.
user2
system is not being installed
(since it is already installed).
user1
system is not being removed (since it is still
needed by user2).
user2
user2 and system are being removed.
demo distribution is not listed in the
Application Cataloque. If it is there, remove it; disabling is
not enough.
demo package is not installed.
demo.install with "Package / Install from file"
demo is getting
installed successfully
demo distribution is listed in the
Application Cataloque and enabled.
demo package is not installed.
demo.install with "Package / Install from file"
demo is getting installed successfully.
demo distribution is listed in the
Application Cataloque and enabled.
osso-xterm.install with "Package / Install from file"
demo distribution is not listed in the
Application Cataloque. If it is there, remove it; disabling is
not enough.
demo-cataloque.install with "Package / Install from file"
demo distribution is listed in the
Application Cataloque.
demo-cataloque.install with "Package / Install from file"
demo-old.install with "Package / Install from file"
extras.install with "Install from file"
new distribution.
new distribution.
package-a_2_powerpc.deb using "Install from file ..."
old distribution is configured.
old distribution is configured and that the
user1 package is not installed.
apt-get install system in a terminal.
system package as explained above in "How to break
packages to be half-installed".
user1 package.
system package has been
downloaded and installed as well.
old distribution
user3 package and verify that the oldsystem
package is installed with it.
user4 package is not installed.
new distribution
user3 package to version 2 and verify that the
oldsystem package is removed and the newsystem package is
installed.
old distribution
user3 package and verify that the oldsystem
package is installed with it.
user4 package.
new distribution
user3 package to version 2 and verify that
this fails with the explanation that user3 conflicts with
user4.
card-1, card-2, card-3 is
installed.
card-old.install
card-1 is installed, but neither of card-2,
card-3.
card-old.install
card-1 is not listed.
card-3, and hit OK.
card-2 and card-3 are installed.
card-1 version 1 is installed.
card-new.install
card-1 is listed.
card-1 and hit OK.
card-1 is updated to version 2.
trusted version 1 is installed.
trusted to version 2.
display-name.
upgrade-description version 1 is installed.
upgrade-description is listed in "Check for updates"
and that it's description says "This is the upgrade description".
upgrade-desctription to version 2.
trusted3.
Verify that it is listed in this file:
/var/lib/hildon-application-manager/domain.testrepo-uri
Verify that it is installable by apt-get, but don't install it:
# apt-get --simulate install flag-system-update
Verify that it is not offered for installation by the AM.
Install flag-system-update with apt-get:
# apt-get install flag-system-update
Enable the "Testrepo new" catalogue.
The following describes how to force the update-notifier into certain states in order to test individual features of it. At the end of this description there is a high-level testcase that brings it all together.
The update-notifier is a statusbar plugin that is loaded all the time but invisible most of the time.
When you have installed a new version of the update-notifier, you need to restart the hildon-desktop to load the new version. A reboot is one way to do that.
It's visibility status can be checked and controlled via the GConf key
/apps/hildon/update-notifier/state
The state is an integer: 0 - invisible, 1 - visible, 2 - blinking. For example, this will cause the icon to blink:
$ gconftool-2 -t int -s /apps/hildon/update-notifier/state 2
The update-notifier will periodically execute the apt-worker in the following way:
# /usr/libexec/apt-worker check-for-updates [proxy]
The interval between runs is determined by the
/apps/hildon/update-notifier/check-interval
GConf key, in minutes. Changing this key should take effect immediately; there is no need to restart hildon-desktop or to reboot. For example, this will set the checking interval to 1 minute:
$ gconftool-2 -t int -s /apps/hildon/update-notifier/check-interval 1
Setting the check-interval to zero means to use the default interval, which is 24 hours.
You can trigger the update-notifier to run apt-worker at any time with this command:
$ hildon-application-manager-util check-for-updates
When the Application Manager is open, the update-notifier plugin will not run apt-worker itself; it will pass on the check-for-updates requests to the Application Manager.
In general, the update-notifier should start blinking when there are updates available that the user has not yet seen. A update is 'available' when it would be listed in the "Check for updates" view (in blue-pill mode). A update has been 'seen', when the "Check for updates" view has actually been activated and the update has been shown in that view.
Thus, it is important to actually switch to the "Check for updates" view when the test cases tell you to do so, since that action will record which updates have been 'seen'.
new and cert-new distributions are
disabled.
new and cert-new distributions but do not refresh
the list of applications.
old and new distributions are both enabled.
Do this on the command line:
# apt-get remove test-kernel-image
Go to the "Check for Updates" view and verify that no "Service Pack" update is visible. (THIS IS IMPORTANT. You really need to open the Check for Updates view.)
Close AM and do this:
# apt-get install test-operating-system=1
Note the "=1" suffix. This makes sure that version 1 is installed.
Wait until the update notifier starts blinking. There should be a Operating System update available.
Do this in a shell
$ gconftool-2 -t int -s /apps/hildon/update-notifier/check_interval 1
$ echo "<config><notifier><uri>http://hildon-app-mgr.garage.maemo.org/info-\${HARDWARE}</uri></notifier></config>" | hildon-application-manager-config -v add -
After one minute, the icon should blink and advertise "Celestia". Note that the check_interval applies to both this "Ad-push" feature as well as the "Available update" notification.
The menu should mention RX-34, RX-44, or RX-48.
Do this
$ echo "<config><notifier><uri>http://hildon-app-mgr.garage.maemo.org/info2-\${HARDWARE}</uri></notifier></config>" | hildon-application-manager-config -v add -
(I.e., change "info" to "info2"). After one minute, the update-notifier should advertise "Hitchcock".
By changing back and forth between "info" and "info2" you can simulate a changing file on the server.
Some defaults of the Application manager can be determined by an external 'settings' package. Here is such a package that configures the system to access the test repository:
To install it, you first need to remove the hildon-application-manager-settings-standard package:
# dpkg --remove hildon-application-manager-settings-standard
# dpkg --install hildon-application-manager-settings-testrepo_5+1_all.deb
If you want to instantiate your own variant of hildon-application-manager-settings-template, you can use the following files to get you started:
Now you should see the testrepo related catalogues in the "Application Catalogues" dialog, and almost all test cases should run normally. The exceptions are related to the update notifier; see below for alternative test cases.
Verify that the "Testrepo default distribution" catalogue failed to refresh with the error message
http://hildon-app-mgr.garage.maemo.org/testrepo/dists/testdist/user/binary-armel/Packages.gz
404 Not found
The important part is the "testdist" string in the URL. This is the default distribution name.
Create a file named /var/tmp/info-RX-51 with this contents:
<info>
<title>Celestia</title>
<text>Explore the universe with your Internet tablet!</text>
<uri>http://maemo.org</uri>
</info>
Replace "RX-51" with the hardware identifier of your device.
Run this in a shell
$ gconftool-2 -t int -s /apps/hildon/update-notifier/check_interval 1
After a minute or so, you should get a notification about "Celestia".
Overwrite /var/tmp/info-RX-51 with this contents:
<info>
<title>Hitchcock</title>
<text>Because the future is the past.</text>
<uri>http://nokia.com</uri>
</info>
Again, after a minute or so, the text in the notification should have changed.