On Sat, 31 May 2008 17:44:59 +0200 Luc wrote: > Mark > > my coments are inline > > > Hi, > > > > Stefan has backported HAL to Solaris 10u5, which > > I think is awesome. > > > > I've attached some diffs to compile and package > > Stefan's port of HAL to Solaris 10u5. Currently > > there are some manual steps to compile it, so > > its not quite ready yet, the status is: > > > > (1) When packaging HAL, I do not know where to put: > > > > /usr/etc/dbus-1/hal.conf > > > > Should be /etc/dbus-1/hal.conf
Hello Luc, Thanks, I'll move it there. > > So I just placed it at the above location, no idea > > if that is correct or not. > > > > (2) The make goes into an infinite loop when it > > tries to build po. I worked around it by the > > follwing in configure.sh > > > > # make in po goes into an infinite loop on my box, disable > > # it for the moment to workaround this, since I do not know > > # why it is looping. Also that is the only reason I added > > # --disable-man-pages --disable-gtk-doc. > > $KBE_PREFIX/bin/sed -i -e "s/ po //" Makefile > > $KBE_PREFIX/bin/sed -i -e "s/ docprivileges//" Makefile > > > > Of course that has the dis-advantage of no man pages or > > documentation currently. > > > > (3) Currently it fails building FOSShal with FOSSdbus, > > as foss is missing dbus-glib-1, the error is: > > > > No package 'dbus-glib-1' found > > > > dbus-glib is in dude, but I do not put there pspc, because it doesn't > build on my machine I am wondering if someone else would like to do the tweaks necessary to build FOSShal with FOSSdbus on Solaris 10u4 or Solaris 10u5? I don't have the correct setup for it. I'm running Solaris 10u5 but I've hacked the machine a lot so it has lots of OpenSolaris stuff compiled from source code on it. Since hal and dbus are low level, removing SUNWdbus and SUNWhal would require removing lots of packages which I have built using them so far. And since I trashed gnome 2.6 it would not be a very good test. > pkgbuild: creating statemachine-server > pkgbuild: make[7]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/dbus/examples/statemachine' > pkgbuild: make[6]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/dbus/examples/statemachine' > pkgbuild: make[5]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/dbus/examples' > pkgbuild: make[4]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/dbus/examples' > pkgbuild: make[3]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/dbus' > pkgbuild: make[2]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/dbus' > pkgbuild: Making all in tools > pkgbuild: make[2]: Entering directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/tools' > pkgbuild: make[2]: *** No rule to make target > `system-dbus-introspect.xml', needed by `dbus-bus-introspect.xml'. > Stop. pkgbuild: make[2]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74/tools' > pkgbuild: make[1]: *** [all-recursive] Error 1 > pkgbuild: make[1]: Leaving directory > `/home/luc/packages/BUILD/FOSSdbus-glib-0.74/amd64/DBUS-GLIB/0.74' > pkgbuild: make: *** [all] Error 2 > > > > > > > I guess we could add dbus-glib-1 to foss for when stock > > Solaris 10u5 gnome 2.6 is used. I can not test it with > > Solaris 10u5 gnome 2.6 though, as I trashed gnome 2.6 > > from my machine. Also I am not sure which dbus-glib-1 > > to add. Well apart from the idea of bumping foss glib2 and > > dbus to the versions that JDS gnome 2.22, and adding > > the corresponding dbus-glib, the JDS gnome 2.22 versions are: > > > > glib2 2.16.3 > > dbus 1.2.1 > > dbus-glib 0.74 > > > > But I don't know if KDE cares about the versions of these > > gnome base libraries or not. > > > > (4) Currently I am building hal as SUNWhal using the > > following procedure: > > > > perl Respect.pl --with-all --without-upload --without-build hal.pspc > > cp -p FOSShal.spec SUNWhal.spec > > sed -i -e "s/FOSShal/SUNWhal/g" SUNWhal.spec > > pkgtool build SUNWhal.spec > > > > And then as root: > > > > # svcadm enable hal > > # > > > > Then svcs -vx hal should show it running: > > > > # svcs -vx hal > > svc:/system/hal:default (Hardware Abstraction Layer daemon) > > State: online since Sat May 31 12:32:32 2008 > > See: man -M /usr/man -s 1M hal > > See: /var/svc/log/system-hal:default.log > > Impact: None. > > # cat /etc/release > > Solaris 10 5/08 s10x_u5wos_10 X86 > > Copyright 2008 Sun Microsystems, Inc. All Rights > > Reserved. Use is subject to license terms. > > Assembled 24 March 2008 > > # > > > > I'm using SUNWgnome-base-libs and SUNWdbus from the > > JDS gnome 2.22, compiled from spec files, from: > > > > svn co > > svn+ssh://anon at svn.opensolaris.org/svn/jds/spec-files/branches/gnome-2-22 > > gnome-2-22 > > > > Take care, becaseu guys from JDS sometimes using gcc instead of Sun > Studio Hopefully gcc is only used in JDS for C/asm code like liboil. > > This also has the advantage that some things from SFE: > > > > http://pkgbuild.sourceforge.net/spec-files-extra/ > > > > like mplayer, compile on Solaris 10u5. > > > > same as one step before I can tweak SFEmplayer. > > (5) I tried to tweak things though so that if > > SUNWgnome-base-libs and SUNWdbus are not installed, then > > it tries to compile it as FOSShal. However it does not > > quite compile at present like that due to (3). > > > > No, we have FOSSglib (glib-2.12.12) and FOSSdbus (or SUNWdbus o > Nevada) for that Yes I guess it makes sense to build them as FOSSglib and FOSSdbus on a stock Solaris 10 machine running gnome 2.6. I tried to add logic for that, but I haven't tested it since I trashed gnome 2.6 off my Solaris 10u5 box. So I also tried to accomodate the situation like on my box where SUNWdbus has been compiled from JDS gnome 2.22, to then compile hal.pspc as SUNWhal, so that it should then be possible to compile KDE 4 and gnome 2.22 on a Solaris 10 box. Then it should be possible to run gnome 2.22 apps, like ekiga, on KDE 4. > > (6) I had to add libfstyp from OpenSolaris as FOSSlibfstyp, > > since it is missing from Solaris 10u5 (or at least it is > > from my box, it is not in SUNWhea which is installed). > > > > ??? Stefan ? > > > > > > > I've attached the diffs for this in case any one would > > like to test, comment, etc. > > > > There are some other little things in the diffs: > > > > (7) Mindless change to rm lib*.a files in various > > install.sh scripts. > > > > (8) Some stuff to change /bin/sh to /bin/bash, which > > is only required if libtool 2.2.4 was used. It > > would probably not hurt with libtool 1.5.X, but > > I haven't tested it. Anyway, if you don't want > > those change I can svn revert them. I've compiled FOSS > > up to and including FOSSlibshout with libtool 2.2.4, > > but we would probably like to pretend that libtool > > doesn't exist, so can understand if you want to > > stay with the hacked libtool 1.5.X for most stuff. > > If I hit any libtool issues though probably the first > > thing I will try is libtool 2.2.4. Its requirement for > > /bin/bash is kind of annoying. I've had problems > > earlier with trying to fix issues in the old libtool. > > > > this is the reason, why I would not use libtool 2.2.4 globaly. OK I agree we should not use libtool 2.2.4 globally. Although it will probably be possible to compile all of FOSS with libtool 2.2.4, after tweaking stuff to make it work, libtool 2.2.4 is kind of usesless for compiling other stuff. For example, xorg and JDS stuff would not compile with libtool 2.2.4 due to issues like: * libtool 2.2.4 requiring /bin/bash, which often requires hack to Makefile.in, Makefiles, configure, etc. * libtool 2.2.4 sometimes needing libtoolize --install --copy before configure. * doing things like: libtoolize --install --copy autoreconf --install --force May break packages due to changes in autotools, issues where the packages do not ship all the m4 macros, etc. So I pkgrm'd libtool 2.2.4 and pkgadd'd libtool 1.5.26 before building other stuff like xorg and JDS. > Stefan, Ade what do you think. Do you would using libtool 2.2.4 ? It > is simple put libtool 2.2.4 into KBE, harder way is migrate out > hacked libtool 1.5 transform to 'our hacked' libtool 2.2.4 libtool 2.2.4 could probably be made to work for FOSS, but almost all other stuff at the moment compiles easier with libtool 1.5.26, hence you would need some way to switch between them. One way is to keep around 2 sets of libtool packages, and used pkgrm/pkgadd to switch between them. It is probably easier to: - use the hacked libtool 1.5.X by default for FOSS. - Personally I use libtool 1.5.26 for compiling other stuff. - If either of those give me problems, I think it would be easier to try libtool 2.2.4 for that particular program. > > (9) libcaptury need /amd64 or whatever the 64 bit > > /$_arch is added to the end of the output for: > > > > you can use ${_libsuffix} in shell scripts (configure.sh and etc.) > which is exported by pkgtool and contains /amd64 or /sparcv9 Thanks, I have done that in places. > > pkg-config --libs "xfixes >= 1.0.0" > > > > I did not have a time to adjust libcaptury .... > > BTW, do you have capse built ? Yes I built FOSScapseo for 32 bit and 64 bit amd64. I have created/tweaked some of the /usr/lib/pkgconfig/*.pc files on my Solaris 10u5 box. > > (10) CTL needs some extra #includes when compiled with -g . > > > > It could be, but we don't use -g at this time. Maybe we should add > switch for Respectl .... somethng like --with-debug a then will be > setup just only debug flags. That would be good. I'm compiling stuff with -g and not stripping it so that I can look at any crashes more easilly. > > (11) Use SFElibcdio instead of FOSSlibcdio is SFElibcdio > > is installed. > > > > Why ? I don't know which vesion or fixes contains SFElibcdio, but you > can expect some troubles maybe. I will tweak SFE mplayer to look for SUNWlibcdio if its installed. So I'll pkgrm SFElibcdio on my box and build SUNWlibcdio instead, and I can get rid of this check for SFElibcdio. > > (12) jasper built %{_bindir}/jiv. > > > > ? I do not not know what jiv is, I guess I could rm it instead if you like? > > (13) dirmngr, I had problems compiling it with the hacked > > libtool 1.5.X earlier when compiling for 64 bit amd64, > > I submitted these diffs earlier to fix that. So not sure > > if anyone needs these now or not. > > > > no problem with dirmngr.... dude contains your previous patches for > dirmngr which are fine. :) OK, great. Thanks, Mark -- This message posted from opensolaris.org
