You are not logged in.
Does this produce a smaller install size then regular FF? I'm curious because I'd like to free up the space xulrunner takes on my netbook's 4Gb SSD.
I'm really not wanting to compile the whole thing just to find out, this being a netbook and all.
Currently #pacman -Rc gives:
Remove (2): firefox-3.5.7-1 xulrunner-1.9.1.7-1
Total Removed Size: 68.77 MB
/etc/rc.d/ is where daemons reside. Beware.
Offline
Offline
Ok, then it's worth a shot. Let me go get the power cord...
[edit]
Ok, now...
firefox-pgo-beta 3.6rc2-1, calls for 64-bit tracemonkey. My netbook is most assuredly 32-bit. Am I stuck with the firefox-pgo 3.5.7-1 instead.
[edit2]
Disabled the TM64 patch line in the PKBUILD. Here goes....
[edit3]
Meh, not going to install the gnome crap (depends of libgnomeui) just to build the damn thing.
Last edited by Kitty (2010-01-24 19:20:42)
/etc/rc.d/ is where daemons reside. Beware.
Offline
Well the TM64 patch won't affect the 32bit build process. There is no need to comment it out as it won't make a difference if you are compiling for a 32bit machine. All the patch does is enable TraceMonkey on a 64bit build, it is enabled by default (aka without the patch) on i686.
You'll likely need the gnome crap sooner or later, but that is your call. I think the speed benefits are worth it.
Offline
Offline
Well I compiled again on my i686 atom with -march=i686 and firefox doesn't segfault. Maybe at the very least a warning could be issued about this problem as it appears to affect anyone with an intel chip.
Last edited by pyther (2010-01-25 02:52:54)
Offline
[edit3]
Meh, not going to install the gnome crap (depends of libgnomeui) just to build the damn thing.
There are very few GNOME packages required, and you can remove them right after.
I do not use GNOME, and would be actively looking for a better fix if it was not a trivial matter.
And as pyther said, the 64-bit TraceMonkey patch does not affect 32-bit users; they've had TraceMonkey since 3.5.0.
But for smaller binary size, you could also set your C(XX)FLAGS in /etc/makepkg.conf to use "-Os" instead of "-O2" (be aware that -Os is _slightly_ more unpredictable). firefox-pgo sets its own C(XX)FLAGS, so you will have to edit the PKGBUILD for that too.
@pyther: What are you saying, exactly? -march=i686 works, on Atoms, but -march=native does not? (I assume then that GCC is auto-detecting the Atom as an entirely different CPU, and compiling in instructions that the Atom does not support) I don't think I can do anything more then add a notice to Atom users in the notice I already give, then, because I don't think I'll be able to detect Atom users and change their CFLAGS.
Could you provide a backtrace? I very highly doubt I'll be able to do anything with it, really, but it could confirm my suspicions if you want to give it a go.
You will have to add the line "options=('!strip')" to the PKGBUILD before building and getting the trace, and I believe that's it.
Offline
Exactly:
--march=native = segfault
--march=i686 = good (no segfault)
I got the idea to try --march=i686 from these post: http://bbs.archlinux.org/viewtopic.php? … 62#p656762 and http://bbs.archlinux.org/profile.php?id=26436
It seems the issue affects P4's and Core2's also, unless if I missed some important information following the above posts.
Edit:
As for doing a traceback, I'll try to do something in the next few days, but takes nearly 3 hours to compile on this Atom!
Last edited by pyther (2010-01-25 18:33:07)
Offline
There are very few GNOME packages required, and you can remove them right after.
out of curiosity, why is libgnomeui required for firefox build?
I am compiling ff without libgnomeui, but maybe I am loosing functionality, so if there is compelling reason to include libgnomeui I will add this lib to the next build.
Offline
There are very few GNOME packages required, and you can remove them right after.
out of curiosity, why is libgnomeui required for firefox build?
I am compiling ff without libgnomeui, but maybe I am loosing functionality, so if there is compelling reason to include libgnomeui I will add this lib to the next build.
I am guessing it's for dialog windows and such. i base this on the firefox-kde-opensuse packages using patches to replace gnomeui entries with something kde based, or commenting them out altogether.
but i have compiled firefox-pgo with gnomeui and gnomevfs disabled, and have had no problems. gconf is still needed though, for compiling, i'm not sure if it's needed for usage. I opt to use the --disable-gnomeui and --disable-gnomevfs in mozconfig to remove the dependency.
"I know what you're thinking, 'cause right now I'm thinking the same thing. Actually, I've been thinking it ever since I got here:
Why oh why didn't I take the BLUE pill?"
Offline
Exactly:
--march=native = segfault
--march=i686 = good (no segfault)I got the idea to try --march=i686 from these post: http://bbs.archlinux.org/viewtopic.php? … 62#p656762 and http://bbs.archlinux.org/profile.php?id=26436
It seems the issue affects P4's and Core2's also, unless if I missed some important information following the above posts.
Edit:
As for doing a traceback, I'll try to do something in the next few days, but takes nearly 3 hours to compile on this Atom!
You are right pyther. I have the exact same issue on my P4 machine. I have not been able to use --march=native for awhile now. It's weird because everything else builds fine using that flag all except for this package. Ever since I started using --march=i686 I have had no further issues.
Just wanted to jump in there to support pyther statement.
In solving a problem of this sort, the grand thing is to be able to reason backward. That is a very useful accomplishment, and a very easy one, but people do not practice it much. In the everyday affairs of life it is more useful to reason forward, and so the other comes to be neglected. There are fifty who can reason synthetically for one who can reason analytically. --Sherlock Holmes
Offline
Compiled great for me.
(Linux arch-desktop 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 25 20:06:48 UTC 2010 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux)
I do have a bit of a newbie queston which I apologize for in advance. Say I wanted to run this firefox-pgo (done) but I also wanted to run firefox-minefield-pgo at the same time what is the easiest and most commonly accepted way to do this?
I'm fairly new to PKGBUILDs and such but I notice that I would probably need to modify the pkgbuild file as I see it is set to conflict with one another. Is this truly the best way -- remove the needed parts in conflicts section and change the target around -- or is there a better way. Any good documentation on the best way to do this that anyone might point me to? Thank you.
Offline
Just a couple question here myself.
Now that libjpeg/libpng have been released is it advisable to wait to update that stuff until a working version of firefox-pgo can be put out? I know the consequences about it breaking my current build and my question has mainly to do with the state firefox-pgo has with the new xulrunner patch. I know some people have mentioned using it but does it seem to be working well or are there other issues involved that might warrant holding off of the update until those are addressed as well? I don't really want to update until something firm can be established as I don't want to be without my web browser for an indeterminate amount of time.
To davidm:
I'm pretty sure you can. I know I read it somewhere in the forums here. I believe it's either been covered earlier in this post or if not here then just just search posts for IceCat /IceWeasel. Somebody was asking how it could coexist together with firefox installed.
In solving a problem of this sort, the grand thing is to be able to reason backward. That is a very useful accomplishment, and a very easy one, but people do not practice it much. In the everyday affairs of life it is more useful to reason forward, and so the other comes to be neglected. There are fifty who can reason synthetically for one who can reason analytically. --Sherlock Holmes
Offline
Tried to build firefox-pgo-beta-3.6 after upgrdading to libpng-1.4.0-2, and got the following compiler error:
/home/jay/builds/firefox-pgo-beta/src/mozilla-1.9.2/modules/libpr0n/encoders/png/nsPNGEncoder.cpp:138: error: 'png_voidp_NULL' was not declared in this scope
Any ideas on how to fix?
Jay
Offline
There are very few GNOME packages required, and you can remove them right after.
hmm...
sudo pacman -S libgnomeui
resolving dependencies...
looking for inter-conflicts...
Targets (24): libgnomecanvas-2.26.0-1 orbit2-2.14.17-1 gconf-2.28.0-1 libgssglue-0.1-2 libtirpc-0.2.1-1
rpcbind-0.2.0-1 fam-2.7.0-14 avahi-0.6.25-1 gnome-mime-data-2.18.0-4 gnome-vfs-2.24.2-2
libbonobo-2.24.2-1 gnome-keyring-2.28.2-1 libproxy-0.2.3-1 libsoup-gnome-2.28.2-1 libunique-1.1.6-1
parted-2.1-1 libatasmart-0.17-1 devicekit-disks-009-3 libnotify-0.4.5-1.1 gnome-disk-utility-2.28.1-1
gvfs-1.4.3-1 libgnome-2.28.0-2 libbonoboui-2.24.2-1 libgnomeui-2.24.2-1
I would not call this very few. Some are ridiculous (Gnome's fault - reason I despise Gnome). Anyway this kills firefox-pgo for me since last 3.6.2 minefield
I am not blaming anyone, I suppose that libgnomeui is required by definition (?), but I will pass.
Offline
I would not call this very few. Some are ridiculous (Gnome's fault - reason I despise Gnome). Anyway this kills firefox-pgo for me since last 3.6.2 minefield
I am not blaming anyone, I suppose that libgnomeui is required by definition (?), but I will pass.
have you tried my suggestion from earlier?
in mozconfig
ac_add_options --disable-gnomeui --disable-gnomevfs
get the sha256sum for mozconfig, replace it in PKGBUILD
remove the gnomeui dependency
re-makepkg (I use -L to keep the log)
for the wireless-tools,
ac_add_option --disable-necko-wifi
same procedure as above
are you experiencing problems doing this? I can understand why the original PKGBUILD (for both pgo and the [extra] firefox maintain this, but there's nothing stopping you from changing the settings yourself, unless you're running into problems. This works for me in x86_64, so YMMV. This has worked for me in firefox-pgo-minefield (3.7), pgo-beta (3.6pre), and kde-opensuse(3.6) packages (as well as building the package in [extra])
a question for Ranguvar or others, pgo-minefield is still 3.7a1 right? or is beta now the 3.7 branch and trunk the future 3.8? I havent seen the roadmap for mozilla lately
[edit]cant spell tonight
Last edited by toxygen (2010-02-02 06:24:16)
"I know what you're thinking, 'cause right now I'm thinking the same thing. Actually, I've been thinking it ever since I got here:
Why oh why didn't I take the BLUE pill?"
Offline
toxygen, browser/config/version.txt in the source is where you want to look
Minefield is still tagged 3.7a1pre.
I will keep firefox-pgo-beta in sync with firefox-pgo until a beta (or possibly alpha) of 3.7 arrives.
firefox-pgo-minefield, though, will always follow mozilla-central.
I have 3.6 ready and waiting for when at least a few common mirrors have synced to libpng 1.4.0 and the associated rebuilds so that it won't cause trouble.
Offline
@toxygen
I have not seen your suggestion regarding mozconfig.
Let me try this, I will post results.
thanks
note added
yes, your suggestions worked like a charm, so thanks again
Last edited by broch (2010-02-02 16:06:14)
Offline
I have 3.6 ready and waiting for when at least a few common mirrors have synced to libpng 1.4.0 and the associated rebuilds so that it won't cause trouble.
is there any way to provide us unofficialy the pkgbuild and the other files required, in order to be able to build it ?
Mikes on AUR
Offline
I ran some benchmarks with firefox-pgo 3.6rc2 (libpng 1.2) and firefox 3.6 official (libpng 1.4).
firefox-pgo:
Sunspider: 730.2 ms +- 1.9%
Peacekeeper: 3173
firefox (official):
Sunspider: 1447.4 ms +- 2.2%
Peacekeeper: 2497
The difference is huge. I will run some additional tests with firefox-pgo final and libpng 1.4 to see if that affects.
EDIT:
firefox-pgo 3.6 with libpng 1.4:
Sunspider: 762.8ms +/- 2.3%
Peacekeeper: 3113
Last edited by Ape (2010-02-09 08:00:43)
Offline
If you're using x86_64, that difference is because of TraceMonkey being forcibly enabled in firefox-pgo
I can't see PGO providing THAT big of a boost, hehe.
@mechmg93: Err, sure, when I get home again.
Though there's not too much of a point, it's pretty simple to edit the PKGBUILD of firefox-pgo-beta for the final version, and it'll just be until the mirrors sync everything, then I'll update in the AUR.
It's taking forever?
Offline
Here is a very unofficial version of 3.6 I updated for myself. I'm using it now so apparently it works. This version unlike Ranguvar's doesn't use wireless_tools or libgnomeui (thanks by the way for the tip toxygen). I'm only throwing this up to help those who have requested this until everything synchs and Ranguvar does his update. I have to change a few things for this to build on my machine but I think I set everything back to default except the after-mentioned dependencies.
Ranguvar, if you feel this is an intrusion upon your build then please delete this post. I'm just trying to save you a bit of time.
The bz2 file contains everything (including the source file). I also made a sha256 checksum file for the bz2 file.
Enjoy
firefox-pgo:
http://www.mediafire.com/?ejgymtywuo5
sha256checksum:
http://www.mediafire.com/?mjjkignmmwh
Edit: Re-uploaded with fixed dependency autoconf2.13.
Last edited by harryNID (2010-02-07 22:37:09)
In solving a problem of this sort, the grand thing is to be able to reason backward. That is a very useful accomplishment, and a very easy one, but people do not practice it much. In the everyday affairs of life it is more useful to reason forward, and so the other comes to be neglected. There are fifty who can reason synthetically for one who can reason analytically. --Sherlock Holmes
Offline
Here is a very unofficial version of 3.6 I updated for myself. I'm using it now so apparently it works. This version unlike Ranguvar's doesn't use wireless_tools or libgnomeui (thanks by the way for the tip toxygen). I'm only throwing this up to help those who have requested this until everything synchs and Ranguvar does his update. I have to change a few things for this to build on my machine but I think I set everything back to default except the after-mentioned dependencies.
very nicely done, it works well here.
on an unrelated note, i just built 3.7a1 (pgo-minefield) with the latest changes and so far I had no problems except one: youtube no longer plays videos.
I should amend that to say youtube comes up, and one of my cores (quadcore) goes to 100%, and the video plays about 1 frame per minute, sound comes on, then firefox freezes for some time, a new frame is displayed, and sound cuts in again, then freeze. google video works, as does dailymotion, so I'm guessing youtube is doing something in the back that is freezing and/or crashing flash player. (perhaps it's the html5 thing, I'm not sure). anyone else seeing this?
edit to add, hulu also goes to 100% and does not play video (hulu-desktop works). i turned on html5 for youtube and some videos seem to work, others give me an error "Your browser does not currently recognize any of the video formats available."
Last edited by toxygen (2010-02-05 18:24:42)
"I know what you're thinking, 'cause right now I'm thinking the same thing. Actually, I've been thinking it ever since I got here:
Why oh why didn't I take the BLUE pill?"
Offline
Here is a very unofficial version of 3.6 I updated for myself. I'm using it now so apparently it works. This version unlike Ranguvar's doesn't use wireless_tools or libgnomeui (thanks by the way for the tip toxygen). I'm only throwing this up to help those who have requested this until everything synchs and Ranguvar does his update. I have to change a few things for this to build on my machine but I think I set everything back to default except the after-mentioned dependencies.
Ranguvar, if you feel this is an intrusion upon your build then please delete this post. I'm just trying to save you a bit of time.
The bz2 file contains everything (including the source file). I also made a sha256 checksum file for the bz2 file.
Enjoy
firefox-pgo:
http://www.mediafire.com/?ezwzyyiz2zysha256checksum:
http://www.mediafire.com/?y3zj2mkmklo
It compiled nicely for me but it had some crashing issues (which admittedly I never bothered to debug and just went back to the repo version of firefox because I was lazy). More than likely it has something to do with my local setup likely with flash because firefox-pgo-minefield does the same thing.
Regarding the delay it is certainly understandable as I can see maintaining these packages is a bit of work and often a thankless job but I think some good will come out of it for me because I am learning a lot by having to hack around with stuff. I'm hoping to be able to set up my own PKGBUILDS for the nightly electrolysis and the stable firefox (PGO builds) so as to not have to be reliant upon others and better understand what is going on while having more control. But that's part of my reason for running Arch in the first place.
Last edited by davidm (2010-02-05 22:05:27)
Offline