| Summary: | Request to apply patch 205_ppc64_mozilla-1.7.6-ppc64.patch.bz2 by ppc use flag in mozilla/firefox etc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kraml Liu <kraml.liu> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ppc64, vapier |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | PPC64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Kraml Liu
2005-09-28 23:23:26 UTC
Hmm, first time you tried it now? As it was also with 'use ppc64' in the older ebuilds ... Yes I know it was "use ppc64" in old ebuilds. I was just going to file the bug and the ebuilds switch to the patch tarball, so I talk about the new patch in the bugzilla. Any reason stop it from been applied by ppc keyword? Hmm, it was for ppc64 only, and it tweaks endianness and type sizes, so I'd rather check with the ppc guys if that is fine for ppc64 with 32bit userland. Anybody on ppc64 team care to comment? Not sure if normal ppc team care about this. Thanks, I saw Michael Hanselmann's fix went into mozilla&firefox ebuild, but I
think that fix may still need polish. I'm using the
ppc(profiles/default-linux/ppc/2005.1/ppc) profile on ppc64, not the ppc64
32-bit userland(profiles/default-linux/ppc/2005.1/ppc64/32bit-userland) on
ppc64, the fix will takes care of the later one but not mine. I suggest to make
this change:
- if use ppc && [[ "${PROFILE_ARCH}" == ppc64 ]]; then
+ if use ppc && [[ `uname -m` == ppc64 ]]; then
Because ${PROFILE_ARCH} is only defined in ppc64 32-bit userland profile, I
changed it to use `uname -m` instead. Then I re-emerge firefox, success.
It's fine from a ppc32 standpoint, I have no idea about ppc32 UL on a ppc64 machine though. (In reply to comment #5) > Thanks, I saw Michael Hanselmann's fix went into mozilla&firefox ebuild, but I > think that fix may still need polish. I'm using the > ppc(profiles/default-linux/ppc/2005.1/ppc) profile on ppc64, not the ppc64 > 32-bit userland(profiles/default-linux/ppc/2005.1/ppc64/32bit-userland) on > ppc64, the fix will takes care of the later one but not mine. I suggest to make > this change: > > - if use ppc && [[ "${PROFILE_ARCH}" == ppc64 ]]; then > + if use ppc && [[ `uname -m` == ppc64 ]]; then > > Because ${PROFILE_ARCH} is only defined in ppc64 32-bit userland profile, I > changed it to use `uname -m` instead. Then I re-emerge firefox, success. > I am not too keen on this, give me a few days to think on it. (In reply to comment #5) > Thanks, I saw Michael Hanselmann's fix went into mozilla&firefox ebuild, but I > think that fix may still need polish. I'm using the > ppc(profiles/default-linux/ppc/2005.1/ppc) profile on ppc64, not the ppc64 > 32-bit userland(profiles/default-linux/ppc/2005.1/ppc64/32bit-userland) on > ppc64, the fix will takes care of the later one but not mine. I suggest to make > this change: > > - if use ppc && [[ "${PROFILE_ARCH}" == ppc64 ]]; then > + if use ppc && [[ `uname -m` == ppc64 ]]; then > > Because ${PROFILE_ARCH} is only defined in ppc64 32-bit userland profile, I > changed it to use `uname -m` instead. Then I re-emerge firefox, success. > What is the reason you can not use the 32bit userland profile? using `uname` in an ebuild is never acceptable applying conditional patches is highly discouraged the problem you describe doesnt make any sense ... the only thing that should care that you're running on 64bit is the kernel, and firefox certainly does not qualify as kernel space using a ppc profile instead of a ppc64/32bit profile is just wrong. also the patch has been applied upstream and is in firefox 2.0. and the mentioned patch is no longer in the patch tarball either. marking bug as INVALID. closing it doesnt matter, `uname -m` is wrong so fix it no `uname -m` any more in ebuild. |
