Calvin - have you updated HAL to use eject from util-linux instead of the eject package?
14 Jan
2014
14 Jan
'14
3:04 p.m.
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.
14 Jan
14 Jan
3:06 p.m.
New subject: [trinity-devel] Calvin - have you updated HAL to use eject from util-linux instead of the eject package?
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(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)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
3:22 p.m.
New subject: [trinity-devel] Calvin - have you updated HAL to use eject from util-linux instead of the eject package?
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.
--
David C. Rankin, J.D.,P.E.
15 Jan
15 Jan
12:32 a.m.
New subject: [trinity-devel] Calvin - have you updated HAL to use eject from util-linux instead of the eject package?
On 01/14/2014 05:22 PM, David C. Rankin wrote:
On 01/14/2014 05:06 PM, Calvin Morrison wrote:
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])
--
David C. Rankin, J.D.,P.E.
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.
2:10 a.m.
New subject: [trinity-devel] Calvin - have you updated HAL to use eject from util-linux instead of the eject package?
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
--
David C. Rankin, J.D.,P.E.
3999
days inactive
4000
days old
4 comments
2 participants
participants (2)
-
Calvin Morrison -
David C. Rankin