|Summary:||sys-apps/hal-0.5.11: version bump|
|Product:||Gentoo Linux||Reporter:||Rafał Mużyło <galtgendo>|
|Component:||New packages||Assignee:||Project Gentopia <gentopia>|
|Severity:||enhancement||CC:||ag, aoz.syn, eva, gurligebis, pacho, rhill, virdiq|
|Package list:||Runtime testing required:||---|
patch to fix configure.in problems
make X dependency conditional
Description Rafał Mużyło 2008-05-15 21:32:54 UTC
Released about week ago.
Comment 1 Gilles Dartiguelongue 2008-05-15 21:57:16 UTC
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.
Comment 2 Rafał Mużyło 2008-05-16 08:04:16 UTC
And just were is that overlay, cause at http://overlays.gentoo.org/proj/gentopia/browser/overlay there's no hal ebuild.
Comment 3 Rafał Mużyło 2008-05-16 08:26:22 UTC
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.
Comment 4 Rafał Mużyło 2008-05-16 08:38:16 UTC
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
Comment 5 Rafał Mużyło 2008-05-16 09:37:08 UTC
And a minor note: hal-0.5.11 was released as tar.bz2 too.
Comment 6 Rafał Mużyło 2008-05-20 13:03:22 UTC
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.
Comment 7 Rafał Mużyło 2008-05-20 13:08:53 UTC
And BTW, what happens, if you already have a correct fdi file in /etc/ ? Does it get overwritten ?
Comment 8 Alessandro Guido 2008-05-20 16:52:49 UTC
(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
Comment 9 Gilles Dartiguelongue 2008-05-20 17:20:58 UTC
0.5.11 is now in tree. for libtool bug, please search bugzilla for other complaints please fill another bug.
Comment 10 Rafał Mużyło 2008-05-20 17:30:23 UTC
> (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)
Comment 11 Alessandro Guido 2008-05-21 14:33:38 UTC
(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"
Comment 12 RB 2008-05-21 15:59:57 UTC
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?
Comment 13 konsti 2008-05-22 11:46:30 UTC
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?
Comment 14 RB 2008-05-22 14:22:58 UTC
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.
Comment 15 Saleem Abdulrasool (RETIRED) 2008-06-15 19:51:28 UTC
X was changed to a conditional dependency in -r1. Closing this again.
Comment 16 Rafał Mużyło 2008-06-15 20:58:45 UTC
doxygen dependency is still not fixed omap is still not fully fixed (lines 172 and 181)
Comment 17 Rafał Mużyło 2008-06-15 21:01:41 UTC
And that doxygen problem is in all ebuilds except 0.5.7.1-r5.