Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 360427 - >=www-client/firefox-12.0 rekeywording request for ~sparc
Summary: >=www-client/firefox-12.0 rekeywording request for ~sparc
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL: http://img31.imageshack.us/img31/6159...
Whiteboard:
Keywords: KEYWORDREQ
: 365997 (view as bug list)
Depends on: 323927 362237 406233 406349
Blocks: 364243 381245
  Show dependency tree
 
Reported: 2011-03-25 13:45 UTC by Alexander Koryushkin
Modified: 2017-08-26 17:57 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ppc support (xulrunner-2.0-powerpc.patch,1.38 KB, patch)
2011-05-04 12:29 UTC, Jory A. Pratt
Details | Diff
ppc-atomic-ops-support.patch (ppc-atomicops.patch,6.74 KB, patch)
2011-05-06 01:45 UTC, Jory A. Pratt
Details | Diff
build log (ppc64) (xulrunner-2.0.1-r1:20110516-082503.log,115.76 KB, text/x-log)
2011-05-16 08:38 UTC, Kacper Kowalik (Xarthisius) (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Koryushkin 2011-03-25 13:45:57 UTC
net-libs/xulrunner-2.0 and www-client/firefox-4.0-r1 successfully build with "- disable-ipc". Thus the need to return "ipc" USE-flag, as in previous ebilds.
Also need to remove the dependency of dev-lang/yasm for architecture ppc

Reproducible: Always
Comment 1 Jeroen Roovers gentoo-dev 2011-03-25 15:32:54 UTC
I don't see a KEYWORDREQ bug report yet, so let's just use this one for all lost arches.

Needs =net-libs/xulrunner-2.0 and consequently media-libs/libvpx or a package.use.mask entry in the arch profile on "net-libs/xulrunner webm" (especially when USE=vpx is already masked for you, perhaps through bug #323727).
Comment 2 Alexander Koryushkin 2011-04-09 06:40:35 UTC
media-libs/libvpx-0.9.5 successfully compiles and works on my ppc32.
The current ebuild net-libs/xulrunner-2.0-r1 for successful build requires the addition of section "src_configure()" for NOT x86/amd64 arch:

mozconfig_annotate''- disable-ipc

IPC code written ugly x86-specific...
Comment 3 Jory A. Pratt gentoo-dev 2011-04-10 15:50:26 UTC
(In reply to comment #2)
> media-libs/libvpx-0.9.5 successfully compiles and works on my ppc32.
> The current ebuild net-libs/xulrunner-2.0-r1 for successful build requires the
> addition of section "src_configure()" for NOT x86/amd64 arch:
> 
> mozconfig_annotate''- disable-ipc
> 
> IPC code written ugly x86-specific...

IPC is being made mandatory, if we do not find someone to step up and write the ipc code for ppc and other archs they will be left with ff-3.x this was one of the main reasons all archs that could not be tested on where drop'd from keywords.
Comment 4 Lars Wendler (Polynomial-C) gentoo-dev 2011-04-20 13:44:57 UTC
Adjusted summary as the old one was way too ambiguous to find this bug via search...
Comment 5 Alexander Koryushkin 2011-04-20 15:13:14 UTC
At first:
mozilla-2.0/ipc/chromium/src/build/build_config.h
-#elif defined(__ppc__)
+#elif defined(__PPC__)
I do not know why the __ppc___ is checked, not __PPC__

The second case is more complicated:
mozilla-2.0/ipc/chromium/src/base/data_pack.cc

A cursory study of the code has not yet allowed me to fix the working of the IPC. Build is successful, but the plug-ins (gnash, for example) do not work .. Somehow later I'll try to look code in detail.
And while I have everything works well without IPC.
Comment 6 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2011-04-20 15:18:36 UTC
On behalf of the prefix team, leave the missing keywords dropped until someone has time/motivation to test it (if it isn't done and you want to remove old versions from the tree, please do so).
Comment 7 Fabian Groffen gentoo-dev 2011-04-20 16:21:53 UTC
(In reply to comment #5)
> At first:
> mozilla-2.0/ipc/chromium/src/build/build_config.h
> -#elif defined(__ppc__)
> +#elif defined(__PPC__)
> I do not know why the __ppc___ is checked, not __PPC__

Because on e.g. Darwin, __ppc__ and __ppc64__ are defined :)  So check both, not just one.
Comment 8 Jory A. Pratt gentoo-dev 2011-05-04 12:29:11 UTC
Created attachment 272075 [details, diff]
ppc support

If someone from ppc herd could test and confirm working or not working would be appreciated.
Comment 9 Alexander Koryushkin 2011-05-05 09:53:41 UTC
(In reply to comment #8)
> If someone from ppc herd could test and confirm working or not working would be
> appreciated.

Without data_pack.cc it will fail to link.
Comment 10 Jory A. Pratt gentoo-dev 2011-05-05 11:38:54 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > If someone from ppc herd could test and confirm working or not working would be
> > appreciated.
> 
> Without data_pack.cc it will fail to link.

Did you actually test the patch? It did not fail to link on any of my systems, just for the record data_pack.cc has not been used in many moons.
Comment 11 Alexander Koryushkin 2011-05-05 11:58:02 UTC
(In reply to comment #10)
> Did you actually test the patch? It did not fail to link on any of my systems,
> just for the record data_pack.cc has not been used in many moons.

What are your USE?

net-libs/xulrunner-2.0.1 "alsa (consolekit) dbus (ipc) (policykit) webm -crashreporter -custom-optimization -debug -gconf  -libnotify -startup-notification -system-sqlite -wifi"

...

../../staticlib/components/libnecko.a(race.o): In function `race_decode_decompress':
race.c:(.text+0x180): undefined reference to `_restgpr_30_x'
../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_map_id11':
nameprep.c:(.text+0x70): undefined reference to `_restgpr_30_x'
../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_prohibited_id11':
nameprep.c:(.text+0xe0): undefined reference to `_restgpr_30_x'
../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_unassigned_id11':
nameprep.c:(.text+0x150): undefined reference to `_restgpr_30_x'
../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_biditype_id11':
...
Comment 12 Jory A. Pratt gentoo-dev 2011-05-05 12:23:53 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > Did you actually test the patch? It did not fail to link on any of my systems,
> > just for the record data_pack.cc has not been used in many moons.
> 
> What are your USE?
> 
> net-libs/xulrunner-2.0.1 "alsa (consolekit) dbus (ipc) (policykit) webm
> -crashreporter -custom-optimization -debug -gconf  -libnotify
> -startup-notification -system-sqlite -wifi"
> 
> ...
> 
> ../../staticlib/components/libnecko.a(race.o): In function
> `race_decode_decompress':
> race.c:(.text+0x180): undefined reference to `_restgpr_30_x'
> ../../staticlib/components/libnecko.a(nameprep.o): In function
> `nameprep_map_id11':
> nameprep.c:(.text+0x70): undefined reference to `_restgpr_30_x'
> ../../staticlib/components/libnecko.a(nameprep.o): In function
> `nameprep_prohibited_id11':
> nameprep.c:(.text+0xe0): undefined reference to `_restgpr_30_x'
> ../../staticlib/components/libnecko.a(nameprep.o): In function
> `nameprep_unassigned_id11':
> nameprep.c:(.text+0x150): undefined reference to `_restgpr_30_x'
> ../../staticlib/components/libnecko.a(nameprep.o): In function
> `nameprep_biditype_id11':
> ...

These are actually gcc undefines, please post your emerge --info
Comment 13 Jory A. Pratt gentoo-dev 2011-05-06 01:45:25 UTC
Created attachment 272251 [details, diff]
ppc-atomic-ops-support.patch

This should complete the support for ppc :)
Comment 14 Alexander Koryushkin 2011-05-07 19:03:39 UTC
(In reply to comment #13)
> This should complete the support for ppc :)

Confirm working.
Comment 15 Jory A. Pratt gentoo-dev 2011-05-11 20:46:36 UTC
*** Bug 365997 has been marked as a duplicate of this bug. ***
Comment 16 Jory A. Pratt gentoo-dev 2011-05-16 00:42:13 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > This should complete the support for ppc :)
> 
> Confirm working.

PPC is now supported in main tree no need to continue to patch. Just need a ppc member to test and keyword. Thanks to those who helped testing.
Comment 17 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2011-05-16 08:38:35 UTC
Created attachment 273381 [details]
build log (ppc64)

PPC64 seems to be suffering from some derivative of https://bugzilla.mozilla.org/show_bug.cgi?id=618485
Comment 18 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2011-05-16 11:01:39 UTC
(In reply to comment #17)
> Created attachment 273381 [details]
> build log (ppc64)
> 
> PPC64 seems to be suffering from some derivative of
> https://bugzilla.mozilla.org/show_bug.cgi?id=618485
Wrong bug for ppc64... The proper one:
https://bugzilla.mozilla.org/show_bug.cgi?id=627664
it haven't been touched since February so I would be grateful if you could apply patch provided there.

On ppc is good to go, as soon as you sanitize:
xulrunner-2.0.1-r1.ebuild: append-flags -mno-avx
That flag is x86/amd64 specific.
Comment 19 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2011-05-16 18:00:43 UTC
Marked ~ppc/~ppc64. Thanks to all involved!
Comment 20 Raúl Porcel (RETIRED) gentoo-dev 2011-06-24 15:03:55 UTC
Segfaults on alpha/ia64, sigbuses on ia64...

On arm bug 362237 needs to be fixed
Comment 21 Raúl Porcel (RETIRED) gentoo-dev 2011-07-03 10:49:36 UTC
(In reply to comment #20)
> Segfaults on alpha/ia64, sigbuses on ia64...

I obviously meant sigbuses on sparc...
Comment 22 Markus Meier gentoo-dev 2011-08-25 20:53:22 UTC
+  25 Aug 2011; Markus Meier <maekke@gentoo.org> firefox-6.0.ebuild:
+  add ~arm, bug #360427
+

xulrunner-2* isn't building yet.
Comment 23 Jory A. Pratt gentoo-dev 2011-08-25 21:18:01 UTC
(In reply to comment #22)
> +  25 Aug 2011; Markus Meier <maekke@gentoo.org> firefox-6.0.ebuild:
> +  add ~arm, bug #360427
> +
> 
> xulrunner-2* isn't building yet.

the patch will not be backported for xulrunner-2.0, everything is going into getting fx-6 to stable which will allow us to kill xulrunner-2.0 all together.
Comment 24 Raúl Porcel (RETIRED) gentoo-dev 2011-09-04 14:29:18 UTC
Removing xulrunner from the summary since its going to get removed
Comment 25 Raúl Porcel (RETIRED) gentoo-dev 2011-09-11 17:32:00 UTC
No more 4...
Comment 26 Jory A. Pratt gentoo-dev 2011-10-02 21:45:42 UTC
ALL arch's should be fine to add keywords to fx-7.0.1-r1, if your arch can not add its keywords please drop your keywords from Mozilla ebuilds. Thunderbird will get a bump that will also allow you to re-keyword, this should be available later tonight.
Comment 27 Raúl Porcel (RETIRED) gentoo-dev 2011-10-09 17:05:54 UTC
(In reply to comment #26)
> ALL arch's should be fine to add keywords to fx-7.0.1-r1, if your arch can not
> add its keywords please drop your keywords from Mozilla ebuilds. Thunderbird
> will get a bump that will also allow you to re-keyword, this should be
> available later tonight.

You mean that any arch that can't keyword fx-7* due to it failing to work, must drop keywords from all firefox versions?!
Comment 28 Jory A. Pratt gentoo-dev 2011-10-10 03:14:15 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > ALL arch's should be fine to add keywords to fx-7.0.1-r1, if your arch can not
> > add its keywords please drop your keywords from Mozilla ebuilds. Thunderbird
> > will get a bump that will also allow you to re-keyword, this should be
> > available later tonight.
> 
> You mean that any arch that can't keyword fx-7* due to it failing to work, must
> drop keywords from all firefox versions?!

Exactly. We do not have the time with the new release schedule to support multiple versions of mozilla products for a few archs.
Comment 29 Matt Turner gentoo-dev 2011-10-12 15:21:04 UTC
(In reply to comment #28)
> Exactly. We do not have the time with the new release schedule to support
> multiple versions of mozilla products for a few archs.

How about we do something like grub-2 does, and say in metadata.xml that the mozilla team only supports >=firefox-${XXX}

<herd restrict="&gt;=www-client/firefox-${XXX}">mozilla</herd>

That would let architectures that the mozilla herd doesn't have time to support manage these packages as they have time, without slowing the mozilla team down.
Comment 30 Jeroen Roovers gentoo-dev 2011-10-12 16:17:41 UTC
I'm happy to give firefox-7 another try on HPPA. If it fails and is too difficult to fix, then I'll gladly drop the remaining HPPA keywording too. It's not like web browsing on decade old systems without proper X11 support is a pleasure to do, let alone a requirement (it started out more as a proof of concept).
Comment 31 Jeroen Roovers gentoo-dev 2011-10-31 12:37:00 UTC
HPPA keywording dropped.
Comment 32 Markus Meier gentoo-dev 2011-11-20 20:52:39 UTC
~arm keywords restored for firefox-7/8.
Comment 33 Raúl Porcel (RETIRED) gentoo-dev 2011-12-26 11:01:21 UTC
~alpha/~ia64 done

its unlikely its going to work on sparc, but i'll have a look...
Comment 34 Jeroen Roovers gentoo-dev 2012-02-28 18:32:55 UTC
Let's give this another go.
Comment 35 Jeroen Roovers gentoo-dev 2012-03-06 20:57:30 UTC
Marked ~hppa: =www-client/firefox-10.0.1-r1
This will require
sys-devel/binutils-2.22-r1 : PATCHVER="1.2"

when going stable, if ever it does.
Comment 36 Raúl Porcel (RETIRED) gentoo-dev 2012-07-29 16:19:02 UTC
FYI sigbuses on sparc...

Jory, you were taking care of this if you remember :D
Comment 37 Jory A. Pratt gentoo-dev 2017-08-26 17:57:13 UTC
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system.

Thank You for your support and understanding
The Mozilla Team