[pacman-dev] [PATCH 1/7] remove trailing whitespace
Signed-off-by: Andrew Gregory <andrew.gregory.8@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
On 14/02/13 09:54, Andrew Gregory wrote:
Please don't touch the .m4 files as they are directly merged from upstream suppliers. This makes monitoring for changes more difficult. The same applies to md5.c. Allan
participants (2)
-
Allan McRae
-
Andrew Gregory