- Pacman-dev - lists.archlinux.org

[pacman-dev] pmpkg_t->buildtype?
by Andrew Fyfe 12 Jul '07

12 Jul '07

Anybody know what pmpkg_t->buildtype is used for? Andrew

3 2

[pacman-dev] Can the update of a package induce the update of its depends?
by ngaba＠petra.hos.u-szeged.hu 11 Jul '07

11 Jul '07

Hi! When I was thinking on the symlink puzzle, I ran into the question above. Let me explain: Suppose, that an updated version of audacious moves from /usr to /opt; and user does a "pacman -S audacious". In this case the installed audacious-plugins will be broken, because it thinks that audacious is installed to /usr. The dir change of audacious wasn't planned so audacious-plugins simply depends on audacious (with no version number), so audacious-plugins won't be updated. To avoid this, the package maintainer can do some ugly tricks only (conflicts, install_script/warn etc.). So it would be useful, if the maintainer somehow could record to the repo that there was a big change between audacious 2.0-1 and 2.0-2; so if user updates from a <=2.0-1 version to a >=2.0-2 version this will induce the update of audacious' depends (we can assume, that the updated version of audacious-plugins works fine with the updated audacious.). Or we can define a special ("major") version number, whose change indicates a "recursive" update. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 4

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-290-gcb164c3
by Dan McGee 11 Jul '07

11 Jul '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via cb164c3130f15b22dbf16991c28ba609cd2f79de (commit) via 37736a56f9c5e4819a8f132a51bc0784c4b288ec (commit) via 39b654965580bfb7dc0ab72b8c901fbf7729a568 (commit) via 1646fcc5bdb71dc4d27204de88da952d95d5902c (commit) via 64e45a36f868ca0386393d6b6cf05ffff09b5439 (commit) via d12c4f4b29458ff04671bf7b9686735ad988c775 (commit) via ea1fef69add040b9e5b1de6e9238eda4576ccd3f (commit) from 9a9928f1b88f4fa08826aa83ff16e6ef38bd4e6c (commit) - Log ----------------------------------------------------------------- commit cb164c3130f15b22dbf16991c28ba609cd2f79de Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Thu Jun 21 12:46:37 2007 +0200 conflict.c: start cleaning conflict check functions The three chk_ functions overlap for packages both in targets and in the database. This caused the same conflict to be found in both direction (A conflicts with B, and B conflicts with A). This patch avoids this duplication. which shouldn't be needed, but other changes might be required for that to work correctly. This also has the unexpected side effect to hide the failure of sync022 pactest, for FS #7415. That's maybe not a good thing though.. Note from Dan: sync022 does succeed, but a sync023 pactest added to check regressions also seems to pass. This may be a valid fix to this 'problem' sync022 was meant to find. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 37736a56f9c5e4819a8f132a51bc0784c4b288ec Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jul 11 00:45:15 2007 -0400 Add new pactest that is backwards of sync022 sync022 was added here: 39b654965580bfb7dc0ab72b8c901fbf7729a568 This pactest reverses the installed package to see if it is correctly picked, in order to test some further changes to this depcheck code that currently makes sync022 fail. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 39b654965580bfb7dc0ab72b8c901fbf7729a568 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jul 11 00:31:27 2007 -0400 Update translation files on libalpm side after gettext change Because of this commit: ea1fef69add040b9e5b1de6e9238eda4576ccd3f we lost a lot of gettext-ized messages on the libalpm side. Remove them in order to clean out these files a bit. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 1646fcc5bdb71dc4d27204de88da952d95d5902c Author: Sergej Pupykin <ps(a)lx-ltd.ru> Date: Tue Jul 10 23:36:15 2007 -0400 Use mbstowcs instead of strlen where applicable Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 64e45a36f868ca0386393d6b6cf05ffff09b5439 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Jul 10 14:58:45 2007 -0400 Create the pacman DB and cachedir directories upon install Signed-off-by: Dan McGee <dan(a)archlinux.org> commit d12c4f4b29458ff04671bf7b9686735ad988c775 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Jul 10 14:31:39 2007 -0400 Fix issue with <dbpath>/db.lck being truncated snprintf takes a length including the '\0' character, this wasn't accounted for originally. Fix it. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit ea1fef69add040b9e5b1de6e9238eda4576ccd3f Author: Dan McGee <dan(a)archlinux.org> Date: Tue Jul 10 14:24:58 2007 -0400 Remove gettext calls from all PM_LOG_DEBUG messages There is no real reason to burden our translators with these messages, as anyone helping to debug these will probably want them in English. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: Makefile.am | 7 + lib/libalpm/add.c | 83 +- lib/libalpm/alpm.c | 3 +- lib/libalpm/be_files.c | 22 +- lib/libalpm/cache.c | 18 +- lib/libalpm/conflict.c | 41 +- lib/libalpm/db.c | 41 +- lib/libalpm/deps.c | 47 +- lib/libalpm/error.h | 2 +- lib/libalpm/handle.c | 9 +- lib/libalpm/md5driver.c | 2 +- lib/libalpm/package.c | 10 +- lib/libalpm/po/de.po | 1259 ++++---------------------- lib/libalpm/po/en_GB.po | 1252 ++++---------------------- lib/libalpm/po/es.po | 1267 ++++----------------------- lib/libalpm/po/fr.po | 1415 ++++-------------------------- lib/libalpm/po/hu.po | 1257 ++++---------------------- lib/libalpm/po/it.po | 1314 ++++------------------------ lib/libalpm/po/libalpm.pot | 1201 ++++---------------------- lib/libalpm/po/pl_PL.po | 1263 ++++----------------------- lib/libalpm/po/pt_BR.po | 1235 ++++---------------------- lib/libalpm/po/ru_RU.po | 1238 ++++---------------------- lib/libalpm/remove.c | 39 +- lib/libalpm/server.c | 19 +- lib/libalpm/sha1.c | 2 +- lib/libalpm/sync.c | 82 +- lib/libalpm/trans.c | 16 +- lib/libalpm/util.c | 2 +- lib/libalpm/versioncmp.c | 4 +- pactest/tests/sync022.py | 2 +- pactest/tests/{sync022.py => sync023.py} | 12 +- src/pacman/pacman.c | 44 +- src/pacman/util.c | 6 +- 33 files changed, 2076 insertions(+), 11138 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 9a9928f1b88f4fa08826aa83ff16e6ef38bd4e6c \ cb164c3130f15b22dbf16991c28ba609cd2f79de

1 0

[pacman-dev] installing a package as user (permission problems)
by Xavier 11 Jul '07

11 Jul '07

Should pacman allow installing a package as user ? It looks quite hard to check for all permissions before doing anything. And if permissions are checked on the fly, and at one point it fails, it looks hard to revert what has been done. For example, suppose an user wants to install foo-1 package, and has write access to everything but $dbpath/local/foo-1/ pacman will be able to install the package, extracting all files on filesystem, but it won't be able to add the package in the database. So the package will be installed, but not recorded in the db. A permission problem can also appear earlier, eg during the extraction of files. Maybe all files from the package can be extracted except one, which needs to be installed in a directory without write access. That looks quite complicated to handle. Oh, I just remembered Dan's permissions branch : http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=b06c89e3e5… "Remove geteuid calls and things related to uid checking in anticipation of reimplementing a more robust permissions checking system. This will allow libalpm to be used in situations where we do not always have root on a system (cygwin, dreamhost, etc.)." More robust permissions checking system, that would be cool. :) To Dan : what you had in mind would solve the problems above ?

2 1

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-283-g9a9928f
by Dan McGee 10 Jul '07

10 Jul '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 9a9928f1b88f4fa08826aa83ff16e6ef38bd4e6c (commit) via 142225fd7db358655cc35acb365a983624a3a5bd (commit) via 862ea627617bc20b5c9a18b191aa5d548043db6b (commit) via c4e712c0ef50a9bac5a7ff5075d48d0a41744493 (commit) via 573b80405c668b0ed3aa2b2d52998f102c01f56e (commit) via 5e68e9d4514b5e3e50b25e4242be0a4d27da4fdc (commit) via 7ec2e088ec4995e370d991507f7f22a5d3d9b27a (commit) via 57d77eab32c01cd7572a11f76480a3724d09c029 (commit) via 8f2575b26ee34caddcd03464a53dc88ac539c98c (commit) via 7d7457288734730dbb0cea3b1918c004f06db1a5 (commit) via 1480ac29e475e369fb781fe98ac5991e1a67e5e5 (commit) from 4906e15d0d31bf0442c25af44bcb637b87a7b027 (commit) - Log ----------------------------------------------------------------- commit 9a9928f1b88f4fa08826aa83ff16e6ef38bd4e6c Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Tue Jul 10 16:31:13 2007 +0100 Remove conflict message for no-existent files. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> commit 142225fd7db358655cc35acb365a983624a3a5bd Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Tue Jul 10 13:11:40 2007 +0100 FS#7271 - [patch] option for avoiding caching netfiles Change the behaviour of makepkg so no longer stores a copy of the source tarball in $srcdir, instead it downloads all sources to $SRCDEST then extracts them to $srcdir. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> commit 862ea627617bc20b5c9a18b191aa5d548043db6b Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Tue Jul 10 16:10:16 2007 +0200 add remove045 pactest. Another test a bit more complicated for -Rs, to prevent regression if removedeps is changed. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit c4e712c0ef50a9bac5a7ff5075d48d0a41744493 Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Tue Jul 10 16:08:04 2007 +0200 add remove044 pactest. This indicates a problem in the current removedeps function (no version checking) for which Nagy proposed a fix here : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008539.html But as he mentioned there, a better fix might be to use the checkdeps function in the removedeps one. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 573b80405c668b0ed3aa2b2d52998f102c01f56e Author: Dan McGee <dan(a)archlinux.org> Date: Tue Jul 10 10:31:03 2007 -0400 makepkg: when running as root, cut out some warnings When running as root, we don't care if fakeroot is installed, and the user certainly isn't "unprivileged". Cut out these warnings. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 5e68e9d4514b5e3e50b25e4242be0a4d27da4fdc Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Fri Jun 29 10:41:48 2007 +0100 Cleanup of pacman_deptest() Clean up some left over code from http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commitdiff;h=76… Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 7ec2e088ec4995e370d991507f7f22a5d3d9b27a Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Tue Jul 10 14:16:21 2007 +0100 scripts/makepkg.sh.in: Add CHOST to the list of variables exported. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> commit 57d77eab32c01cd7572a11f76480a3724d09c029 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sat Jul 7 17:11:18 2007 +0200 libalpm/trans.c : exit the forked process correctly in case of errors. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 8f2575b26ee34caddcd03464a53dc88ac539c98c Author: Dan McGee <dan(a)archlinux.org> Date: Mon Jul 9 16:40:50 2007 -0400 Add AC_SYS_LARGEFILE to configure.ac This defines _FILE_OFFSET_BITS == 64, which makes stat calls transparently use stat64, etc. This allows us to support large files, such as packages over 1 GB in size. libarchive was already correctly compiled with this macro. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 7d7457288734730dbb0cea3b1918c004f06db1a5 Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Mon Jul 2 18:28:39 2007 +0100 Change the exit code for pacman_deptest(). Changed the exit code for missing deps from 1 to 127 because 1 is used for other errors. makepkg breaks if pacman exits with 1 for any reason other than a missing dep. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> commit 1480ac29e475e369fb781fe98ac5991e1a67e5e5 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Jul 9 15:22:01 2007 -0400 Clean up the alpm handle Add some comments in handle.h, and remove the pmaccess_t part that we don't even use. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: configure.ac | 3 ++ lib/libalpm/alpm.h | 1 + lib/libalpm/conflict.c | 3 +- lib/libalpm/deps.c | 12 ++++++++ lib/libalpm/handle.c | 39 ++++++------------------- lib/libalpm/handle.h | 55 +++++++++++++++++------------------ lib/libalpm/log.c | 2 +- lib/libalpm/trans.c | 10 +----- pactest/tests/remove044.py | 16 ++++++++++ pactest/tests/remove045.py | 30 +++++++++++++++++++ scripts/makepkg.sh.in | 68 +++++++++++++++++++++++++++++++------------- src/pacman/deptest.c | 19 +++++------- 12 files changed, 158 insertions(+), 100 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 4906e15d0d31bf0442c25af44bcb637b87a7b027 \ 9a9928f1b88f4fa08826aa83ff16e6ef38bd4e6c

1 0

[pacman-dev] How to run the install scripts
by Siem Korteweg 10 Jul '07

10 Jul '07

Hi, hope this is the proper mailing-list to post this. I am new to ArchLinux and developing a package. I am having trouble to get the install scripts running, I tested the following (minimal) package: file x.install: echo "$0 with arguments: $*" >>/tmp/log # to be extended for pre- and post-install actions exit 0 file src/x #!/bin/sh echo "$0" exit 0 file x.build: pkgname=x pkgver=1.1.1 pkgrel=1 pkgdesc=('get the install scripts running') arch=('i686') install=x.install license=('GPL') build(){ mkdir -p ../pkg/opt/x/bin cp -x ../pkg/opt/x/bin chmod 700 ../pkg/opt/x/bin/x } building the package with the command: makepkg -p x.build The build succeeds and the resulting x-1.1.1-1.i686.pkg.tar.gz file contains all the right files and the .INSTALL file contains the code of the x.install file. Installing the package with: pacman -U x-1.1.1-1.i686.pkg.tar.gz succeeds also. The file /opt/x/bin/x is created. However, the file /tmp/log does not exist, while I expected it to contain several lines for at least pre-install and post-install. I did not change any of the pacman configuration files (on my base-install). Why does the install script not run? Thanks in advance for any clue. Siem Korteweg

3 4

[pacman-dev] CVS update of pacman-lib (configure.ac)
by Dan McGee 10 Jul '07

10 Jul '07

Date: Tuesday, July 10, 2007 @ 11:08:33 Author: dan Path: /home/cvs-pacman/pacman-lib Modified: configure.ac (1.42 -> 1.43) backport fix for FS 7578 --------------+ configure.ac | 3 +++ 1 file changed, 3 insertions(+) Index: pacman-lib/configure.ac diff -u pacman-lib/configure.ac:1.42 pacman-lib/configure.ac:1.43 --- pacman-lib/configure.ac:1.42 Sun Jun 17 20:15:36 2007 +++ pacman-lib/configure.ac Tue Jul 10 11:08:33 2007 @@ -148,6 +148,9 @@ AC_MSG_ERROR("libdownload is needed to compile pacman!"); fi +# Enable large file support if available +AC_SYS_LARGEFILE + dnl Set config location AC_MSG_CHECKING(for configuration file name) if test -n "$configfile"; then

1 0

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-272-g4906e15
by Dan McGee 09 Jul '07

09 Jul '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 4906e15d0d31bf0442c25af44bcb637b87a7b027 (commit) via a2186a43a895950cf97dcfcec4b18279f09f0801 (commit) from a501b72e40062c9e606a787657582d1859c35d35 (commit) - Log ----------------------------------------------------------------- commit 4906e15d0d31bf0442c25af44bcb637b87a7b027 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Jul 9 00:46:29 2007 -0400 Remove gettext from any alpm_logaction calls We shouldn't translate log messages to pacman.log so it is consistant and can be parsed by other tools. Remove all gettext _() around these strings. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit a2186a43a895950cf97dcfcec4b18279f09f0801 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jul 8 23:46:48 2007 -0400 Add top level hidden file code to package.c This was already taken care of in add.c by commit 2ae043866045bbeef129a4b503ee1f5486545821, but was missed in package.c. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: lib/libalpm/add.c | 38 +++++++++++++++++++++++--------------- lib/libalpm/package.c | 3 +++ lib/libalpm/sync.c | 4 ++-- lib/libalpm/trans.c | 2 +- src/pacman/callback.c | 6 +++--- src/pacman/sync.c | 4 ++-- 6 files changed, 34 insertions(+), 23 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ a501b72e40062c9e606a787657582d1859c35d35 \ 4906e15d0d31bf0442c25af44bcb637b87a7b027

1 0

[pacman-dev] little error when installing/upgrading the first package in a new database
by Xavier 09 Jul '07

09 Jul '07

There was an odd error when the first package installed in a database had a scriptlet : LANG=C sudo src/pacman/pacman --conf pacman.conf -Ud /var/cache/pacman/pkg/filesystem-0.8-3.pkg.tar.gz loading package data... done. (1/1) checking for file conflicts [####################################################################################################] 100% error: could not open file /home/xav/dev/pacman/foo/var/lib/pacman/local//filesystem-0.8-3/depends: No such file or directory----------------------------] 0% (1/1) installing filesystem [####################################################################################################] 100% This doesn't happen with package that doesn't have a scriptlet, and it doesn't happen either when there is at least one other package in the database. But it still happened after running the same pacman command several times (ie upgrading the single package in the database). I finally found why. in add.c, alpm_add_commit function : 366 _alpm_log(PM_LOG_DEBUG, _("removing old package first (%s-%s)"), oldpkg->name, oldpkg->version); That part will remove the filesystem package if it existed (in case of an upgrade), and will also remove the entry from the database (filesystem directory in $dbpath/local) 473 } else if(strcmp(entryname, ".INSTALL") == 0) { 474 /* the install script goes inside the db */ 475 snprintf(filename, PATH_MAX, "%s/%s-%s/install", db->path, 476 newpkg->name, newpkg->version); That extracts the scriptlet to $dbpath/local//filesystem-0.8-3/install . then later, we have this : 778 /* Update the requiredby field by scanning the whole database 779 * looking for packages depending on the package to add */ 780 _alpm_pkg_update_requiredby(newpkg); and later, this : 821 _alpm_log(PM_LOG_DEBUG, _("updating database")); 822 _alpm_log(PM_LOG_DEBUG, _("adding database entry '%s'"), newpkg->name); So when update_requiredby is called, the entry hasn't been totally written in the database, we only have the install file, but no depends or desc file. and some code from update_requiredby in package.c : 756 pmdb_t *localdb = alpm_option_get_localdb(); 757 for(i = _alpm_db_get_pkgcache(localdb); i; i = i->next) { ... 764 for(j = alpm_pkg_get_depends(cachepkg); j; j = j->next) { So _alpm_get_pkgcache will return the filesystem package, because the directory exists in $dbpath/local/ , but alpm_pkg_get_depends will try to read the depends file which doesn't exist yet, resulting in the error message. Finding this didn't take too long, but this error should then appear in every cases, as long as the package has a scriptlet. But it didn't, as soon as there were more than one package in the db, the error disappeared. That's because of the pkg cache. in package.c , _alpm_db_get_pkgcache function, we have : 106 if(!db->pkgcache) { 107 _alpm_db_load_pkgcache(db); 108 } so the package database is loaded again only if db->pkgcache is NULL. The first time we install filesystem, pkgcache will be NULL when that function is called, so it'll read the database, finding the partial filesystem entry. And when we upgrade filesystem, it removes the old filesystem package first and at this moment _alpm_db_remove_pkgfromcache function from cache.c will be called, doing this : 152 _alpm_log(PM_LOG_DEBUG, _("removing entry '%s' from '%s' cache"), 153 alpm_pkg_get_name(pkg), db->treename); 154 155 db->pkgcache = alpm_list_remove(db->pkgcache, pkg, _alpm_pkg_cmp, &vdata); which will result in a NULL db->pkgcache too. There is no differences between an uninitialized list and an empty list, unfortunately ... When there is another package in the database, pkgcache won't be NULL after the current package being upgraded is removed from pkgcache list. So the pkgcache won't be updated by reading the database again when update_requiredby is called, and so it won't fail on a broken partial filesystem entry, because it has been removed from pkgcache ealier. While that issue was totally harmless, and never happens, because there is always more than one package in the db, it was annoying to get it every time when debugging, without knowing where it came from. For fixing it, it shouldn't be too hard, but I'm not sure yet. Maybe we can delay the extraction of the scriptlet to $dbpath/ , and only installs it in the same time than the dabase entry is created. Or maybe we can just call requiredby after the database entry is fully created, I'm not sure.. Or maybe we can make the difference between an empty pkgcache and a not initialized one.

3 5

Re: [pacman-dev] FS#7525: Permissions of .pacnew files
by Andrew Fyfe 08 Jul '07

08 Jul '07

Move the discussion to the ML... Pacman wrote: > THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. > > The following task has a new comment added: > > FS#7525 - Permissions of .pacnew files > User who did this - Xavier (shining) > > ---------- > Well then, maybe we could read the whole archive a first time, for > determining how to handle backup files (on the fly md5 computation), > and we record this information somehow. > And then a second time, where we actually extract the files. > > Otherwise, the files in backup array are always small config files > afaik, but well, it could be indeed be safer > to avoid putting the whole file in memory. > > Oh well, finally, the current behavior is alright I guess, and this is > probably not the correct place for discussing about things anyway (silly > me). > So I think this bug could be closed now :) > ---------- I've been thinking of another solution, include some more information in .FILELIST eg: # directory name d usr d usr/bin # file name checksum f usr/bin/foo md5sum # link name target l usr/bin/bar foo This way we can get the md5sum from the file list rather than having to extract the file to get it's md5sum. Andrew

2 2