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...
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)
Well, my take on this is since HAL is not needed by TDE any more in R14 (which by the way will have its first RC tagged in a matter of days), trying to maintain HAL is a waste of developer effort.
That being said, I realise there are platforms that still depend on HAL such as BSD. I would be willing to put up a GIT repository for HAL if you are willing to maintain it.
Tim
On 01/16/2014 02:53 AM, Timothy Pearson wrote:
Well, my take on this is since HAL is not needed by TDE any more in R14 (which by the way will have its first RC tagged in a matter of days), trying to maintain HAL is a waste of developer effort.
That being said, I realise there are platforms that still depend on HAL such as BSD. I would be willing to put up a GIT repository for HAL if you are willing to maintain it.
Tim
<smacks self> Well, you make a fair offer. The only trepidation I have is that I may end up in over my head. I will need help for the larger community to know what patches can be applied safely without causing problems for distros other than Arch. I am fairly certain that the current patchset I have is the latest generic set:
cd $srcdir patch -Np1 -d ${srcdir} < hal.patch
cd "${srcdir}/${pkgname}-${pkgver}" patch -Np1 -i "${srcdir}/hal-libudev-events.patch" patch -Np1 -i "${srcdir}/hal-glib-2.3-compile-fix.patch" patch -Np1 -i "${srcdir}/udev-update.patch" patch -Np1 -i "${srcdir}/badvok-compile-fix.patch"
The two other fixes should be generic as well and backwards compatible to earlier versions of automake:
# fix trialing space sed -i 's/failed; [] /failed; \/' policy/Makefile.am
# fix subdir-objects mess in automake 1.14 sed -i 's/AM_INIT_AUTOMAKE[(][gnu 1.9][)]/AM_INIT_AUTOMAKE([subdir-objects])/' configure.in
I don't plan on needing hal, but I do not mind helping maintain it for those that will be using it. Let's get some feedback from Slavek, and the rest of the packagers and see if hal will be needed for the next year. If it is, then bring it in-house, I'll get all the patches and fixes applied and we can go from there. Thankfully the source is only a couple of megabytes.
All, what is the consensus? Will you need hal and if so, would you help update it if Tim set it up here?
-
David C. Rankin -
Timothy Pearson