Slavek/Tim, All, I don't know what the lifetime plans for 3.5.13 are, but given upcoming automake 2.0 issues facing hal, if 3.5.13 will be around for more than a year or so, it would make sense to bring hal/hal-info in-house while the updates to the source tree are still manageable. (as done with Qt3) As of automake 1.14, hundreds of warnings are generated regarding 'subdir-objects' being disabled in automake and build fails due to obsolete macros. I have added the subdir-objects option to AM_INIT_AUTOMAKE in configure.in for Archlinux builds and added 'autoupdate' to correct the obsolete macro build failure. Hal then builds fine. Currently there are over 1M of patches applied to the hal 0.5.14 source. When 6 patch files encompassing over a megabyte of diffs are required, the chance for subsequent patches breaking prior patches poses a real problem. If 3.5.13 will be around for a while and still need hal/hal-info, it may make sense to bring hal in-house and clean it up/apply the current patch sets and make it available to those still working with 3.5.13. The last updates applied to the hal code date back to 2011 - centuries ago in Linux terms. Hal and hal-info presently exist in a git repository. That may make it easier to bring the code in-house for update. These are just thoughts I had after going though the process to update and build hal yesterday. Here are the locations of the two git repositories. Git repositories: git://anongit.freedesktop.org/hal git://anongit.freedesktop.org/hal-info It may not be worth the effort, but for those distros on automake 1.14 that will be moving to automake 2.0 when released, I doubt hal will build without some significant updates. If 3.5.13 will continue to need hal and will be around for a while, some planning and effort now (after R14 is out the door) may pay dividends in the future... Apparently automake 2.0 will force object files to be produced in the current directory deprecating the multiple subdirectory Makefile source references that hal currently uses. E.g. from partutil/Makefile.am: libpartutil_la_SOURCES = partutil.h partutil.c ../hald/logger.c ../hald/logger.c produces the subdir-objects warning that from my understanding will cause failure in automake 2.0. If the AM_INIT_AUTOMAKE([subdir-objects]) option will take care of this problem in 2.0, then it isn't that much of a problem, but if not, then a bit of work will be needed on hal. I am still not very clear on all the implications, but from working through the build on automake 1.14, this was the impression I got. Think about it, you all decide, I'm going to try R14 and nohal and see how it goes... -- David C. Rankin, J.D.,P.E.