Bug 231200 - 64-bit hal package should not get installed on ppc64
64-bit hal package should not get installed on ppc64
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
ppc64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
:
Depends On:
Blocks: FC7Blocker
  Show dependency treegraph
 
Reported: 2007-03-06 13:59 EST by David Woodhouse
Modified: 2014-03-16 23:06 EDT (History)
5 users (show)

See Also:
Fixed In Version: 0.5.9-0.git20070401.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-02 21:33:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hald output (45.13 KB, text/plain)
2007-03-07 04:15 EST, David Woodhouse
no flags Details
fdi-cache (191.81 KB, application/octet-stream)
2007-03-07 04:30 EST, David Woodhouse
no flags Details

  None (edit)
Description David Woodhouse 2007-03-06 13:59:57 EST
[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
Comment 1 David Zeuthen 2007-03-06 14:41:03 EST
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.
Comment 2 David Woodhouse 2007-03-07 04:15:35 EST
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
Comment 3 David Zeuthen 2007-03-07 04:21:43 EST
What is the size of /var/cache/hald/fdi-cache?
Comment 4 David Woodhouse 2007-03-07 04:30:01 EST
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.
Comment 5 David Zeuthen 2007-03-07 11:56:31 EST
(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!

Comment 6 David Zeuthen 2007-03-07 14:16:07 EST
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.
Comment 7 David Zeuthen 2007-03-07 15:03:51 EST
Actually this just shows that ppc works; I'll try now with CC='gcc -m64'

(I hate multilib)
Comment 8 David Zeuthen 2007-03-07 17:18:05 EST
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.
Comment 9 David Zeuthen 2007-03-07 17:31:16 EST
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.
Comment 10 David Zeuthen 2007-03-07 17:31:38 EST
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.
Comment 12 Joe Orton 2007-03-08 04:42:15 EST
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.
Comment 13 Joe Orton 2007-03-08 04:57:55 EST
With config.status hacked to substitute correct /usr/lib64-relative glib/dbus
include paths, the hald test suite passes.
Comment 14 David Woodhouse 2007-03-08 05:03:37 EST
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.
Comment 15 David Zeuthen 2007-03-08 11:06:15 EST
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.
Comment 16 David Woodhouse 2007-03-22 08:30:36 EDT
Still not working today.
Comment 17 Joe Orton 2007-03-22 09:20:25 EDT
releng can do special magic to prevent hal.ppc64 appearing in composes I think,
that's presumably the simplest fix.  Jesse?
Comment 18 David Woodhouse 2007-03-22 09:35:33 EDT
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).
Comment 19 Jesse Keating 2007-03-22 10:31:14 EDT
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?
Comment 20 David Zeuthen 2007-04-02 20:12:23 EDT
Moving to 'distribution' component.
Comment 21 David Zeuthen 2007-04-02 20:16:02 EDT
fixing up summary
Comment 22 David Woodhouse 2007-04-02 20:35:13 EDT
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?
Comment 23 David Zeuthen 2007-04-02 20:44:41 EDT
(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..

Comment 24 David Woodhouse 2007-04-02 20:50:44 EDT
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.
Comment 25 David Woodhouse 2007-04-02 20:53:36 EDT
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.
Comment 26 David Zeuthen 2007-04-02 21:33:20 EDT
* Mon Apr 02 2007 David Zeuthen <davidz@redhat.com> - 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.
Comment 27 David Woodhouse 2007-04-03 00:18:38 EDT
Thanks.
Comment 28 David Woodhouse 2007-04-25 06:22:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.