Released about week ago.
if you want to follow work on hal in gentoo, you'd better use the gentopia overlay. Release candidate was tracked there already and several gentoo developers are subscribed to hal mailing list. Thanks for understanding.
And just were is that overlay, cause at http://overlays.gentoo.org/proj/gentopia/browser/overlay there's no hal ebuild.
Created attachment 153293 [details, diff] patch to fix configure.in problems Never mind, I found it, it's one of the git overlays now, maybe some links should be updated. BTW, I'm attaching a patch, that I sent to hal bugzilla. One of its lines is (already known) libtool 2 g++ fix. The rest are fixes to configure options to match their descriptions.
And of the lesser issues: omap should be use_with, not use_enable doxygen-docs are now gtk-doc (change dependencies too); in fact it has been this way since 0.5.8
And a minor note: hal-0.5.11 was released as tar.bz2 too.
Hey, the ebuild you've dropped into the tree doesn't address any of the problems listed here, it even doesn't apply the patch for libtool problem.
And BTW, what happens, if you already have a correct fdi file in /etc/ ? Does it get overwritten ?
(In reply to comment #6) > Hey, the ebuild you've dropped into the tree doesn't address any of the > problems listed here, it even doesn't apply the patch for libtool problem. > hal-0.5.11 fails to build with libtool 2.2
0.5.11 is now in tree. for libtool bug, please search bugzilla for other complaints please fill another bug.
> (In reply to comment #6) > > Hey, the ebuild you've dropped into the tree doesn't address any of the > > problems listed here, it even doesn't apply the patch for libtool problem. > > > > hal-0.5.11 fails to build with libtool 2.2 > No, it doesn't, at least not with the patch that was applied to hal-0.5.10, and should still be applied to 0.5.11. That means that the ebuild that got added to portage tree at Tue May 20 04:21:15 2008 UTC is broken. Also it does not address neither of the problems I pointed out in this bug (gtk-doc vs doxygen, invalid configure options, possible tar.bz2 usage)
(In reply to comment #10) > > (In reply to comment #6) > > > Hey, the ebuild you've dropped into the tree doesn't address any of the > > > problems listed here, it even doesn't apply the patch for libtool problem. > > > > > > > hal-0.5.11 fails to build with libtool 2.2 > > > No, it doesn't, at least not with the patch that was applied to hal-0.5.10, > and should still be applied to 0.5.11. > That means that the ebuild that got added to portage tree at Tue May 20 > 04:21:15 2008 UTC is broken. > Also it does not address neither of the problems I pointed out in this bug > (gtk-doc vs doxygen, invalid configure options, possible tar.bz2 usage) > Sorry, I really wanted to say "hal-0.5.11 fails to build w/ libtool 2.2 as it is now in portage, please add the libtool patch back"
This version indirectly adds an X dependency via dev-python/pyxf86config. Obviously, this doesn't fly with headless servers and environments that are prevented from having X for whatever reason. I've masked it locally, but can we drop that dependency?
Additional pyxf86config does not build if xorg-server was built with minimal USE flag enabled, there is no -lxf86config then: i686-pc-linux-gnu-gcc -shared .libs/pyxf86conf.o .libs/xf86config_ext.o /usr/lib/libgmodule-2.0.so -L/usr/lib -ldl /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -lxf86config -march=k8 -Wl,--export-dynamic -Wl,-soname -Wl,ixf86configmodule.so -o .libs/ixf86configmodule.so /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lxf86config collect2: ld returned 1 exit status Should this become a report against pyxf86config merely?
Created attachment 153945 [details, diff] make X dependency conditional I'm not a gentoo dev, but would think pyxf86conf would need its own bug if it's not compiling in an environment that it is expected to. It is my _opinion_ that my headless/hardened servers have no need for an X environment, however minimal. I have provided my users sys-aps/pmount to be able to mount removable media, which depends on hal. After thinking about it further, it may be optimal to add X to IUSE and make this a conditional dependency. The attached patch to the ebuild does so just fine, compiles, and runs.
X was changed to a conditional dependency in -r1. Closing this again.
doxygen dependency is still not fixed omap is still not fully fixed (lines 172 and 181)
And that doxygen problem is in all ebuilds except 0.5.7.1-r5.
(In reply to comment #17) > And that doxygen problem is in all ebuilds except 0.5.7.1-r5. > Have you already opened different bug reports for each problem? This way is much easier to handle by maintainers... Thanks
