[root@uranus ~]# hald --daemon=no --verbose=yes 2>&1 | tail 18:59:03.574 [I] coldplug.c:252: new event (dev node from udev) '/sys/block/sda/sda1' '/dev/sda1' 18:59:03.574 [I] coldplug.c:252: new event (dev node from udev) '/sys/block/sda/sda2' '/dev/sda2' 18:59:03.574 [I] coldplug.c:252: new event (dev node from udev) '/sys/block/sda/sda3' '/dev/sda3' 18:59:03.574 [I] coldplug.c:252: new event (dev node from udev) '/sys/block/sr0' '/dev/scd0' 18:59:03.574 [I] coldplug.c:280: new event (no dev node) '/sys/block/dm-0' 18:59:03.575 [I] coldplug.c:280: new event (no dev node) '/sys/block/dm-1' 18:59:03.575 [I] osspec.c:601: Synthesizing powermgmt events... 18:59:03.575 [I] osspec.c:611: No powermgmt capabilities 18:59:03.575 [I] osspec.c:613: Done synthesizing events *** [DIE] device_info.c:rules_match_and_merge_device():927 : Rule is NULL on jump
Hmm, please either attach the full output of 'hald --daemon=no --verbose=yes' or, if you want, the place where hald-generate-fdi-cache is called. I bet this has to do with 64-bit. Also, you probably want to remove /var/cache/hald/fdi-cache before each debug run. Thanks.
Created attachment 149438 [details] hald output 09:09:22.425 [I] mmap_cache.c:149: Regenerating fdi cache.. 09:09:22.427 [W] hald_dbus.c:1043: Could not get uid for connection: org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name 'org .freedesktop.DBus': no such name 09:09:22.427 [E] hald_dbus.c:4040: Cannot get caller info for org.freedesktop.DBus 09:09:22.428 [W] hald_dbus.c:1043: Could not get uid for connection: org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name 'org .freedesktop.DBus': no such name 09:09:22.428 [E] hald_dbus.c:4040: Cannot get caller info for org.freedesktop.DBus 09:09:22.430 [W] hald_dbus.c:1043: Could not get uid for connection: org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name 'org .freedesktop.DBus': no such name 09:09:22.430 [E] hald_dbus.c:4040: Cannot get caller info for org.freedesktop.DBus 09:09:22.431 [W] hald_dbus.c:1043: Could not get uid for connection: org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name 'org .freedesktop.DBus': no such name 09:09:22.431 [E] hald_dbus.c:4040: Cannot get caller info for org.freedesktop.DBus 09:09:22.809 [I] mmap_cache.c:126: In regen_cache_cb exit_type=0, return_code=0 09:09:22.809 [I] mmap_cache.c:185: fdi cache generation done
What is the size of /var/cache/hald/fdi-cache?
Created attachment 149439 [details] fdi-cache -rw-r--r-- 1 root root 196416 2007-03-07 09:09 /var/cache/hald/fdi-cache DBus is not working at all on this system. I can let you log in to it if that's helpful.
(In reply to comment #4) > DBus is not working at all on this system. Oh, the D-Bus daemon isn't even running? > I can let you log in to it if that's > helpful. Yeah, that would help a lot. I probably don't even need root as we have a test-case for the fdi cache generator / fdi cache reader. I will need the build requires for the HAL package. Please mail me directly with details. Thanks!
Huh, rpm dbus packages works just fine and running hal from git works fine too; perhaps some of the fixes from the last few days after rc1 was. Btw, I see you were running hal-0.5.9-0.git20070218.fc7 which is old. Please test latest packages the next time you file bugs. Updating to hal-0.5.9-0.git20070304.fc7 didn't fix it either but as the git version works it will probably be fixed with rc2 which should hit rawhide in a few days. I'll keep this bug open.
Actually this just shows that ppc works; I'll try now with CC='gcc -m64' (I hate multilib)
22:10:17.065 [E] create_cache.c:479: .local-fdi-test/share/hal/fdi/policy/10osvendor/15-storage-luks.fdi:1: XML parse error: no element found 22:10:17.065 [E] create_cache.c:544: error processing fdi file '.local-fdi-test/share/hal/fdi/policy/10osvendor/15-storage-luks.fdi' 22:10:17.065 [I] create_cache.c:551: skipped fdi file '.local-fdi-test/share/hal/fdi/policy/10osvendor/15-storage-luks.fdi' Almost positive that the 64-bit expat library is broken. You can # cd /root/Hacking/hal/hald # make check to see this yourself and try again with newer / patched expat libraries.
Reassigning to expat for now to get input from expat package owner - feel free to reassign back to hal in case this isn't an expat problem. Thanks.
The length being passed to XML_Parse() is zero with the "final" flag set, so expat is rightly giving a parse error, a zero-length XML document isn't allowed. I think this is due to the wrong glib arch-specific header being picked up: CPPFLAGS in that build show: -I/usr/lib/glib-2.0/include. (gdb) print sizeof(gsize) $1 = 4 I'd suspect the root cause is bug 224037.
With config.status hacked to substitute correct /usr/lib64-relative glib/dbus include paths, the hald test suite passes.
Why are we running (or indeed installing) 64-bit /usr/sbin/hald _anyway_? That's the equivalent of installing 32-bit /usr/sbin/hald on x86_64. It's just wrong.
Hey, Joe, thanks for looking into this... so this looks like it's not a hal bug. I wonder if there is a Fedora bug for pkg-config I can close this as a dupe of? Or perhaps as dwmw2 says, the problem is that 64-bit hal gets installed.
Still not working today.
releng can do special magic to prevent hal.ppc64 appearing in composes I think, that's presumably the simplest fix. Jesse?
Another option might be to fix rpm to prefer the 32-bit version of executables. That's arguably the right thing to do for ppc64 hardware anyway. (Except for gdb which is a special case).
We can setup blacklists but not at the price of broken deps. We have to figure out if hal is being brought in as multilib because it has a -devel subpackage and library requirements on the hal package, or it is being brought in to satisfy the library requirements of something else that is multilib. I just looked, it does appear that hal has a -devel and thus is multilib. However instead of carrying a blacklist, might it make sense to split the libs out of the base hal package into hal-libs which would be multilib along with hal-devel, but not the actual base hal package?
Moving to 'distribution' component.
fixing up summary
There's already a 'distribution' bug open to that effect -- I think the solution we settled upon for F7 was that we were going to drop _all_ ppc64 packages from the 'ppc' repository apart from the basics (kernel, glibc, kexec-tools, gdb), and anyone wanting more 64-bit packages than that could get them from the 'ppc64' repo. The hal situation isn't ideal after we do that -- because to build against libhal for ppc64 you'd still need to pull in the 64-bit hal-devel and hal packages, and the hal package contains _executables_. Can we split the 'hal' package into 'hal' and 'hal-libs' to avoid that?
(In reply to comment #22) > Can we split the 'hal' > package into 'hal' and 'hal-libs' to avoid that? Can rpm cope with that? For example, will a package foo that (wrongly) Requires: hal (for libhal) automagically pull in hal-libs? If yes, I'm fine with this change..
Well, if the 'hal-libs' package is the one which contains /usr/lib/libhal*.so.* then it'll have automatic dependencies anyway, not explicit ones. Unless you expect people to be using dlopen() for libhal? And explicit dependencies would be broken already, because they wouldn't specify the right architecture. Any version would do.... at least as far as RPM was concerned. Unless, of course, you used filenames for the explicit dependency. Which would do the right thing when you split the package too.
And yes, even if your 'foo' package _does_ just 'Requires: hal' then it'll pull in hal-libs too automatically -- because hal will pull in hal-libs for itself.
* Mon Apr 02 2007 David Zeuthen <davidz> - 0.5.9-0.git20070401.2 - Split hal package into hal and hal-libs (#231200) - Fix hal-device-manager ownership (#234696) OK, done that. I'm closing this bug.
Thanks.
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235524#c8 regarding a dependency loop which could cause problems when upgrading from FC6 to the new split packages. It seems that hal depends on hal-info, and vice versa.