All -> Calvin,
While I plan on building R14 without hal, taking a look at the package on AUR, hal still depends on eject. Eject now conflicts with util-linux, eject which means we need to remove eject as a dependency. Do you plan on updating, or should I just cannibalize it?
Those packages should be marked out of date. I wouldn't trust them. I'm not sure about specifics about the conflict
Calvin On Jan 14, 2014 6:05 PM, "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
All -> Calvin,
While I plan on building R14 without hal, taking a look at the package on AUR, hal still depends on eject. Eject now conflicts with util-linux, eject which means we need to remove eject as a dependency. Do you plan on updating, or should I just cannibalize it?
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 01/14/2014 05:06 PM, Calvin Morrison wrote:
Those packages should be marked out of date. I wouldn't trust them. I'm not sure about specifics about the conflict
I am re-writing the PKGBUILD, so I'm going to figure it out. I think the only dependencies that no longer exist are 'eject' and 'systemd-tools' and those seem to be provided now by 'util-linux' and 'systemd'. (god knows the source hasn't changed.....) I'll report back with success or failure.
On 01/14/2014 05:22 PM, David C. Rankin wrote:
On 01/14/2014 05:06 PM, Calvin Morrison wrote:
Those packages should be marked out of date. I wouldn't trust them. I'm not sure about specifics about the conflict
I am re-writing the PKGBUILD, so I'm going to figure it out. I think the only dependencies that no longer exist are 'eject' and 'systemd-tools' and those seem to be provided now by 'util-linux' and 'systemd'. (god knows the source hasn't changed.....) I'll report back with success or failure.
Grr, found that problem - yes there really is a trailing space in the hal source that kills the build. Fix with:
build() { 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" sed -i 's/failed; [] /failed; \/' policy/Makefile.am ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But then another FTBS:
hald/solaris/probing/Makefile.am:15: but option 'subdir-objects' is disabled hald/solaris/probing/Makefile.am:19: warning: source file '../../logger.c' is in a subdirectory, hald/solaris/probing/Makefile.am:19: but option 'subdir-objects' is disabled partutil/Makefile.am:7: warning: source file '../hald/logger.c' is in a subdirectory, partutil/Makefile.am:7: but option 'subdir-objects' is disabled ==> ERROR: A failure occurred in build(). Aborting...
Where line 7 is:
libpartutil_la_SOURCES = partutil.h partutil.c ../hald/logger.c
So this looks like a true 'subdir-objects' is disabled failure regarding logger.c. (why this one and not the 100 before?) dunno.. I'm going to try:
AM_INIT_AUTOMAKE([subdir-objects])
On 01/15/2014 02:32 AM, David C. Rankin wrote:
So this looks like a true 'subdir-objects' is disabled failure regarding logger.c. (why this one and not the 100 before?) dunno.. I'm going to try:
AM_INIT_AUTOMAKE([subdir-objects])
SOLVED - Automake is a mess and it will get worse! For hal on arch, you must update your build() to:
build() {
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"
# 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
libtoolize --force aclocal autoupdate # required to fix obsolete macros autoconf automake --add-missing --warnings=all
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --libexecdir=/usr/lib/hal --with-udev-prefix=/etc \ --enable-static=no --disable-acpi-ibm \ --disable-docbook-docs --disable-console-kit \ --disable-policy-kit --disable-acl-management \ --enable-umount-helper --disable-smbios \ --with-hal-user=hal --with-hal-group=hal \ --with-pid-file=/var/run/hald.pid \ --sbindir=/usr/bin --disable-gtk-doc make
}
But in the end:
hal-0.5.14-18-x86_64.pkg.tar.xz
complete with systemd hal.service file