On Sun, Oct 5, 2008 at 2:23 PM, Roman Kyrylych wrote:

2008/10/3 :

...

Warning: Ensure your ABS tree is clean to prevent false positives.

========================== = x86_64 Integrity Check = ==========================

Performing integrity checks... ==> parsing pkgbuilds ==> checking dependencies ==> checking makedepends ==> checking archs ==> checking for circular dependencies ==> checking repo packages

Missing Dependencies ---------------------- libgdiplus --> 'libungif' klibc-module-init-tools --> '/lib/klibc-*.so' klibc-module-init-tools --> '.so' latex2html --> 'libungif' imlib --> 'libungif' v86d --> '/lib/klibc-*.so' v86d --> '.so' klibc-extras --> '/lib/klibc-*.so' klibc-extras --> '.so' klibc-udev --> '/lib/klibc-*.so' klibc-udev --> '.so' windowmaker --> 'libungif' klibc-kbd --> '/lib/klibc-*.so' klibc-kbd --> '.so'

I think there's a bug in the script ;-)

There is a bug indeed, the problem is that the current python script used a rather quite complicated method, it was trying to parse the PKGBUILD bash scripts itself, in a naive way, handling variables and stuff, but not everything and it broke in the klibc case. But even if it worked, it would still be wrong : it is simply impossible to check the klibc dependencies at the PKGBUILD level, because the dependency is computed at runtime. For the klibc package itself, it looks at the library just built (pkg/lib/klibc-*.so). For the other klibc-* packages, it looks at the library installed on the system (/lib/klibc-*.so). In short, you can check the klibc* dependencies at the package level, or at the sync databases level, examining the /var/lib/pacman/sync/ contents, or the *.db.tar.gz databases. But not at the PKGBUILD level. Anyway, because of the complex parsing and other reasons, I totally rewrote the check-archlinux script, and Aaron committed it one month ago : http://projects.archlinux.org/?p=dbscripts.git;a=commit;h=909b017c08109bda40... In particular, this new script includes a hack to skip the klibc-* dependency. However this hack was not fully working, so I posted a patch to improve it recently : http://www.archlinux.org/pipermail/arch-dev-public/2008-September/008310.htm... This patch was not pulled yet. Otherwise, Aaron told me that the problem in pushing all these dbscript changes live is that it will require him one day of availability, so that he can fix if anything goes wrong.