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?