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, J.D.,P.E.