Signed-off-by: Andrew Gregory <andrew.gregory.8(a)gmail.com>
---
lib/libalpm/md5.c | 2 +-
lib/libalpm/util.c | 6 ++---
m4/gpgme.m4 | 8 +++----
m4/libtool.m4 | 2 +-
m4/lt~obsolete.m4 | 2 +-
test/pacman/README | 70 +++++++++++++++++++++++++++---------------------------
6 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/lib/libalpm/md5.c b/lib/libalpm/md5.c
index 0d5ed9e..1230245 100644
--- a/lib/libalpm/md5.c
+++ b/lib/libalpm/md5.c
@@ -157,7 +157,7 @@ static void md5_process( md5_context *ctx, const unsigned char data[64] )
P( B, C, D, A, 12, 20, 0x8D2A4C8A );
#undef F
-
+
#define F(x,y,z) (x ^ y ^ z)
P( A, B, C, D, 5, 4, 0xFFFA3942 );
diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c
index f4c33a0..204e643 100644
--- a/lib/libalpm/util.c
+++ b/lib/libalpm/util.c
@@ -143,7 +143,7 @@ done:
/** Copies a file.
* @param src file path to copy from
* @param dest file path to copy to
- * @return 0 on success, 1 on error
+ * @return 0 on success, 1 on error
*/
int _alpm_copyfile(const char *src, const char *dest)
{
@@ -912,7 +912,7 @@ char SYMEXPORT *alpm_compute_sha256sum(const char *filename)
return hex_representation(output, 32);
}
-/** Calculates a file's MD5 or SHA2 digest and compares it to an expected value.
+/** Calculates a file's MD5 or SHA2 digest and compares it to an expected value.
* @param filepath path of the file to check
* @param expected hash value to compare against
* @param type digest type to use
@@ -950,7 +950,7 @@ int _alpm_test_checksum(const char *filepath, const char *expected,
* Does not handle sparse files on purpose for speed.
* @param a
* @param b
- * @return
+ * @return
*/
int _alpm_archive_fgets(struct archive *a, struct archive_read_buffer *b)
{
diff --git a/m4/gpgme.m4 b/m4/gpgme.m4
index 44bf43c..434bb95 100644
--- a/m4/gpgme.m4
+++ b/m4/gpgme.m4
@@ -57,7 +57,7 @@ AC_DEFUN([AM_PATH_GPGME],
sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
if test "$gpgme_version_major" -gt "$req_major"; then
ok=yes
- else
+ else
if test "$gpgme_version_major" -eq "$req_major"; then
if test "$gpgme_version_minor" -gt "$req_minor"; then
ok=yes
@@ -125,7 +125,7 @@ AC_DEFUN([AM_PATH_GPGME_PTH],
sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
if test "$gpgme_version_major" -gt "$req_major"; then
ok=yes
- else
+ else
if test "$gpgme_version_major" -eq "$req_major"; then
if test "$gpgme_version_minor" -gt "$req_minor"; then
ok=yes
@@ -195,7 +195,7 @@ AC_DEFUN([AM_PATH_GPGME_PTHREAD],
sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
if test "$gpgme_version_major" -gt "$req_major"; then
ok=yes
- else
+ else
if test "$gpgme_version_major" -eq "$req_major"; then
if test "$gpgme_version_minor" -gt "$req_minor"; then
ok=yes
@@ -264,7 +264,7 @@ AC_DEFUN([AM_PATH_GPGME_GLIB],
sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
if test "$gpgme_version_major" -gt "$req_major"; then
ok=yes
- else
+ else
if test "$gpgme_version_major" -eq "$req_major"; then
if test "$gpgme_version_minor" -gt "$req_minor"; then
ok=yes
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index d812584..ae27a7f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1152,7 +1152,7 @@ fi
# Invoke $ECHO with all args, space-separated.
func_echo_all ()
{
- $ECHO "$*"
+ $ECHO "$*"
}
case "$ECHO" in
diff --git a/m4/lt~obsolete.m4 b/m4/lt~obsolete.m4
index c573da9..ffeab56 100644
--- a/m4/lt~obsolete.m4
+++ b/m4/lt~obsolete.m4
@@ -25,7 +25,7 @@
# included after everything else. This provides aclocal with the
# AC_DEFUNs it wants, but when m4 processes it, it doesn't do anything
# because those macros already exist, or will be overwritten later.
-# We use AC_DEFUN over AU_DEFUN for compatibility with aclocal-1.6.
+# We use AC_DEFUN over AU_DEFUN for compatibility with aclocal-1.6.
#
# Anytime we withdraw an AC_DEFUN or AU_DEFUN, remember to add it here.
# Yes, that means every name once taken will need to remain here until
diff --git a/test/pacman/README b/test/pacman/README
index 958ff28..357ebbf 100644
--- a/test/pacman/README
+++ b/test/pacman/README
@@ -4,17 +4,17 @@ README
pactest is a test suite for the ArchLinux package manager: pacman.
It has a rather high level view of operations performed by pacman: it
-automatically creates a test environment based on a test case file
-description, the run pacman, and finally check the results of test according
+automatically creates a test environment based on a test case file
+description, the run pacman, and finally check the results of test according
to a set of rules defined in the test case.
-It is written in Python and makes available most of what can be found in
+It is written in Python and makes available most of what can be found in
pacman's code to create ArchLinux packages or read and write databases entries.
-Each test case is defined in a separate file that is sourced in order to set
+Each test case is defined in a separate file that is sourced in order to set
the environment.
-pactest creates the environment in the subdirectory "root" created in the
+pactest creates the environment in the subdirectory "root" created in the
current directory.
The following directory structure is used:
- var/lib/pacman: databases path (local and sync ones)
@@ -23,7 +23,7 @@ The following directory structure is used:
- var/log/pactest.log: log file
- var/pub: location for pseudo sync repositories
- tmp: hold all local package archives (to be used with pacman -U)
-
+
Note: the logfile is used to capture all pacman outputs.
Test case example:
@@ -41,7 +41,7 @@ Test case example:
for f in p.files:
self.addrule("FILE_EXIST=%s" % f)
-Basically, the above test case will try to install a package (dummy-1.0-3),
+Basically, the above test case will try to install a package (dummy-1.0-3),
including two files, from a local archive, by calling "pacman -U"
Upon completion, it checks that:
- pacman returned no error code,
@@ -80,13 +80,13 @@ The test environment is described by the following basic parameters:
description
-----------
-A short string describing the aim of the test case. It is displayed on the
+A short string describing the aim of the test case. It is displayed on the
standard output during test execution.
args
----
-A string of arguments that are passed to the pacman binary when the test is
+A string of arguments that are passed to the pacman binary when the test is
run.
Example:
@@ -115,39 +115,39 @@ Examples:
filesystem
----------
-A list of strings describing a set of files supposed to exist in the filesystem
+A list of strings describing a set of files supposed to exist in the filesystem
when the test case is run.
-Upon test startup, pactest will automatically populate the test environment
+Upon test startup, pactest will automatically populate the test environment
filesystem with this list of files.
Example:
self.filesystem = ["bin/dummy",
"etc/X11/xorg.conf.pacsave"]
-Note that all paths are relative ones, and thus file names should not start
+Note that all paths are relative ones, and thus file names should not start
with a "/".
Packages
========
-The test case file description shall define a number of packages that can be
-used to either populate a database, or to feed pacman with data needed during
+The test case file description shall define a number of packages that can be
+used to either populate a database, or to feed pacman with data needed during
its execution.
This can be achieved by creating pmpkg objects, with the following constructor:
pmpkg(name, version)
-Both "name" and "version" are strings. Also, note that if not provided, the
+Both "name" and "version" are strings. Also, note that if not provided, the
version defaults to "1.0-1".
Example:
pkg1 = pmpkg("dummy", "2.1-1")
pkg2 = pmpkg("foobar")
-All fields from a ArchLinux package can be set and modified directly with no
+All fields from a ArchLinux package can be set and modified directly with no
methods to access them.
-Note: some fields are automatically set by pactest and should preferably not
+Note: some fields are automatically set by pactest and should preferably not
be modified by hand (i.e. "md5sum", "size", or "csize").
Examples:
@@ -158,14 +158,14 @@ Examples:
Databases
=========
-The test environment provides a way to create and fill databases (local or
+The test environment provides a way to create and fill databases (local or
sync ones).
The following methods shall be used:
* addpkg2db(database, package)
-Notes: "database" is a string, and "package" shall be a previously created
+Notes: "database" is a string, and "package" shall be a previously created
pmpkg object.
Examples:
@@ -174,15 +174,15 @@ Examples:
self.addpkg2db("sync1", spkg12)
self.addpkg2db("sync2", spkg21)
-Note: there is no need to explicitly create a database. The "local" one
-already exists (even if empty), and sync databases are created on the fly when
+Note: there is no need to explicitly create a database. The "local" one
+already exists (even if empty), and sync databases are created on the fly when
a new database name is given.
* addpkg(package)
package is an existing pmpkg object.
-It creates a package archive based on the given object. The resulting archive
-is located in the temporary directory of the test environment, ready to be
+It creates a package archive based on the given object. The resulting archive
+is located in the temporary directory of the test environment, ready to be
supplied to pacman for test purposes.
@@ -194,7 +194,7 @@ name, with an additional line feed.
For instance, the content of a file "bin/dummy" created in the test environment
file system is: "bin/dummy\n".
-It is possible to create directories by appending a slash "/" to the name and
+It is possible to create directories by appending a slash "/" to the name and
to create symlinks by appending an arrow followed by a filename " -> target".
Note: only relative symlinks are supported.
@@ -206,11 +206,11 @@ Example:
"lib/libfoo.so.O",
"lib/libfoo.so -> ./libfoo.so.0"]
-In this example, "usr/local/" is a directory, and "libfoo.so" will be a
-symlink pointing at "libfoo.so.0". It is usually a good idea to also define
+In this example, "usr/local/" is a directory, and "libfoo.so" will be a
+symlink pointing at "libfoo.so.0". It is usually a good idea to also define
the target of the symlink!
-It can be interesting for some tests to create altered files. This can be
+It can be interesting for some tests to create altered files. This can be
done by appending one or more asterisks "*" to the file name.
Example:
@@ -224,13 +224,13 @@ Example:
self.args = "-U dummy-1.0-2.pkg.tar.gz"
-In this case, package "lpkg" will install a file "bin/dummy" with "bin/dummy\n"
-as its content. Upon package upgrade, newpkg will provide a file named
+In this case, package "lpkg" will install a file "bin/dummy" with "bin/dummy\n"
+as its content. Upon package upgrade, newpkg will provide a file named
"bin/dummy" with "bin/dummy*\n" as its content.
-This is useful to simulate that a file has been modified between two different
+This is useful to simulate that a file has been modified between two different
releases of a same package.
-The same also applies to files from the "filesystem" parameter of the test
+The same also applies to files from the "filesystem" parameter of the test
environment, and to the "backup" attribute of a package object.
@@ -250,10 +250,10 @@ Examples:
self.addrule("FILE_MODIFIED=bin/dummy")
self.addrule("PKG_DEPENDS=xorg|fontconfig")
-Note: an item can be divided into two arguments, as shown in the latter
+Note: an item can be divided into two arguments, as shown in the latter
example.
-All rules can be prepended with a bang "!" in order to tell pactest to expect
+All rules can be prepended with a bang "!" in order to tell pactest to expect
the exact opposite result.
Example:
@@ -271,12 +271,12 @@ Possible rules are:
For RETCODE, pactest will ensure the pacman return code is the value given.
For OUTPUT, pactest will grep pacman outputs for the given value.
-Note: PACMAN_OUTPUT should not be used. Pacman outputs are likely to change
+Note: PACMAN_OUTPUT should not be used. Pacman outputs are likely to change
from one release to another, so that it's reliability is quite low.
. PKG rules
-For each rule, pactest will read the entry "name" from the local database and
+For each rule, pactest will read the entry "name" from the local database and
challenge the requested data with it.
Possible rules are:
--
1.8.1.3