Compile Pale Moon 28 on Fedora 27

Introduction

Pale Moon 28 was released on August 16, 2018. I package it myself on Fedora because I don’t see it in the fedora repositories, and plus I like the experience of assembling packages myself. For a basic compile (not in an rpm), you can follow these instructions.

Install dependencies

Install the whole set of packages listed on the Pale Moon site (reference 2) or CentOS7

sudo dnf -y install gtk2-devel dbus-glib-devel autoconf213 yasm mesa-libGL-devel alsa-lib-devel libXt-devel zlib-devel openssl-devel sqlite-devel bzip2-devel pulseaudio-libs-devel
sudo dnf -y groupinstall 'Development Tools'

Install the dependencies I found.

sudo dnf -y install GConf2-devel notification-daemon

Use autoconf 2.13

Pale Moon depends on autoconf 2.13. Thankfully, it’s in the Fedora repos, but changing the main autoconf link to point to this specific version will save a bunch of headache later. Be aware that this step exactly as shown will change your system’s default autoconf. I’m sure this is a crude way to do it, but aren’t build systems throwaway systems nowadays?

autoconfver="$( autoconf --version 2>/dev/null | awk 'NR==1 {print $NF*100;} END {print "0";}' | head -n1 )"
test ${autoconfver} -ne 213 &&amp test ${autoconfver} -gt 0 && sudo mv /usr/bin/autoconf /usr/bin/autoconf-${autoconver} 2>/dev/null ; sudo ln -sf autoconf-2.13 /usr/bin/autoconf

Fetch source

Pale Moon likes to compile in ~/pmsrc. Don’t change it. It just makes it easier.

mkdir ~/pmsrc ~/pmbuild
cd ~/pmsrc
git clone https://github.com/MoonchildProductions/UXP .

Prepare to compile

Use the recommended .mozconfig from the Pale Moon site (reference 2)

tf=~/pmsrc/.mozconfig
touch "${tf}"
cat <<'EOFMOZCONFIG' > "${tf}"
mk_add_options AUTOCLOBBER=1
mk_add_options MOZ_OBJDIR=/home/$USER/pmbuild/
ac_add_options --enable-application=palemoon
 
ac_add_options --enable-optimize="-O2"
 
# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1
 
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --with-pthreads
 
ac_add_options --disable-tests
ac_add_options --disable-eme
ac_add_options --disable-parental-controls
ac_add_options --disable-accessibility
ac_add_options --disable-webrtc
ac_add_options --disable-gamepad
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
 
ac_add_options --x-libraries=/usr/lib
EOFMOZCONFIG

Compile

These instructions include saving the output to a log file, but that’s not necessary.

mkdir ~/log
cd ~/pmsrc
{ time ./mach build && time ./mach package ; } | tee -a ~/log/pmsrc.$( date "+%F-%H%M%S" ).log
echo done

References

Weblinks

  1. https://bugzilla.mozilla.org/show_bug.cgi?id=1167201
  2. http://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux#head:Fedora
  3. Compiling Pale Moon web browser on Fedora (published 2018-02-09)
Advertisements

Compiling Pale Moon web browser on Fedora 27

<

Story

I like the traditional model of Firefox. This is easily represented in the current project Pale Moon. The upstream project does not currently provide instructions for compiling on Fedora 27. All the options they have documented are on their developer site: https://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux.

You might think it is no big deal to download and compile an application. But when the application is still targeted for gcc4.9, it’s a little tricky to compile on the current Fedora which uses gcc7.

After consulting the Internet, I have assembled my instructions for compiling Palemoon on Fedora.

Compile palemoon on Fedora 27

# Install the whole set of packages listed on (primary ref 1) for CentOS7
sudo dnf -y install gtk2-devel dbus-glib-devel autoconf213 yasm mesa-libGL-devel alsa-lib-devel libXt-devel zlib-devel openssl-devel sqlite-devel bzip2-devel pulseaudio-libs-devel
sudo dnf -y groupinstall 'Development Tools'

# Install additional dependencies I found
sudo dnf -y install nspr-devel

# Use autoconf 2.13
autoconfver="$( autoconf --version 2>/dev/null | awk 'NR==1 {print $NF*100;} END {print "0";}' | head -n1 )"
test ${autoconfver} -ne 213 && test ${autoconfver} -gt 0 && sudo mv /usr/bin/autoconf /usr/bin/autoconf-${autoconver} 2>/dev/null ; sudo ln -sf autoconf-2.13 /usr/bin/autoconf

# Use the copr davidva/gcc49
sudo dnf -y copr enable davidva/gcc49
# fix the $releasever variable in the repo
sudo sed -i -r -e 's/-\$releasever-/-23-/;' /etc/yum.repos.d/_copr_davidva-gcc49.repo
sudo dnf -y install gcc49
# fix a minor library problem (primary ref 2)
pushd /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3
sudo cp -p ../lib64/libgcc_s.so.1 .
sudo ln -s libgcc_s.so.1 libgcc_s.so
popd

# Fetch palemoon source
mkdir ~/pmsrc ~/pmbuild
cd ~/pmsrc
git clone https://github.com/MoonchildProductions/Pale-Moon.git .

# Prepare to compile
# use .mozconfig from (primary ref 1)
tf=~/pmsrc/.mozconfig
touch "${tf}"
cat <<'EOFMOZCONFIG' > "${tf}"
# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1

mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-application=browser

mk_add_options MOZ_OBJDIR=/home/$USER/pmbuild/

ac_add_options --enable-optimize="-O2 -msse2 -mfpmath=sse"
ac_add_options --with-pthreads

ac_add_options --disable-installer
ac_add_options --disable-updater

ac_add_options --enable-release
ac_add_options --enable-devtools
ac_add_options --enable-jemalloc
ac_add_options --enable-shared-js

ac_add_options --enable-strip

ac_add_options --x-libraries=/usr/lib
EOFMOZCONFIG

# Compile:
mkdir ~/log
cd ~/pmsrc
source /usr/bin/gcc49
{ time ./mach build ; } | tee -a ~/log/pmsrc.$( date "+%Y-%m-%d-%H%M%S" ).log
echo done

Future steps

Post these instructions on the fedora and palemoon fora.
Ask Pale Moon devs if these can be adapted and shared on Reference 1.

References

Weblinks

primary

  1. http://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux
  2. ensure lib files are in right dir: https://serverfault.com/questions/266138/cannot-find-lgcc-s-from-gcc-3-4-on-unbuntu-11-04/266141#266141

auxiliary

  1. A great example and future reference http://ftp.nluug.nl/pub/os/Linux/distr/pclinuxos/pclinuxos/srpms/SRPMS.pclos/palemoon-27.0.3-1pclos2017.src.rpm
  2. https://build.opensuse.org/package/show/network/palemoon

gcc 4.9 for Fedora 27

If you want gcc 4.9 (the GNU Compiler Collection) on the current version of Fedora, which is Fedora 27, there is an easy option for you!

You can use the Cool Other Packages Repo, or copr, written by the user davidva.
The easiest way to use his gcc49 copr is this:

sudo dnf -y copr enable davidva/gcc49
sudo sed -i -r -e 's/-\$releasever-/-23-/;' /etc/yum.repos.d/_copr_davidva-gcc49.repo
sudo dnf -y install gcc49

There is a weakness in the repo file delivered by the copr, where it uses the $releasever instead of a static number 23 used by the repo. Davidva compiled the package without a specific fedora version number tied to it, so it will install on any version of Fedora, as long as you can get to the rpm package.
There is also a weakness with a particular library. It’s in the wrong directory, so it cannot be found. You might find an error when trying to compile a project:

/usr/bin/ld: cannot find -lgcc_s

Use these steps to fix it (Weblink 2).

pushd /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3
sudo cp -p ../lib64/libgcc_s.so.1 .
sudo ln -s libgcc_s.so.1 libgcc_s.so
popd

As the copr page (Weblink 1) indicates, this installation of gcc 4.9 can be present concurrently with the main gcc installation. To use version 4.9, you need to run:

source /usr/bin/gcc49

Which sets a few variables, notably $CC and $CXX to be the specific binaries from this package.

References

  1. https://copr.fedorainfracloud.org/coprs/davidva/gcc49/
  2. ensure lib files are in right dir: https://serverfault.com/questions/266138/cannot-find-lgcc-s-from-gcc-3-4-on-unbuntu-11-04/266141#266141

Moving the application installation directory for bgscripts

Overview

My bgscripts package in version 1.1-27 and before was installed in /usr/bgscripts. The more I thought about it, and the more I read the spec for FHS 3.0 (filesystem hierarchy standard) (PDF), the more I realized it should actually be in /usr/share/bgscripts.

Moving the files in the build directory was easy.

Wrapper script

But despite my symlinks in /usr/bin, which were easy to update, I have many, many hard-coded pathname calls of my scripts everywhere. So to mitigate the problem, I wrote a fancy wrapper script for regular scripts, including bup, send, bgscripts.bashrc, rdp, and treesize.

I needed to send myself a message with the various information about what script called the old location. I picked send.sh because that’s what it’s for– sending emails. I slapped in a bunch of diagnostic information and wrote a call to the new location.

#!/bin/bash
# Wrapper at legacy location for bgscripts. Sends alert and then continues the process.
# DETERMINE LOCATION OF FRAMEWORK
while read flocation; do if test -x ${flocation} && test "$( ${flocation} --fcheck )" -ge 20161212; then frameworkscript="${flocation}"; break; fi; done <<EOFLOCATIONS
./framework.sh
${scriptdir}/framework.sh
/usr/share/bgscripts/framework.sh
/home/bgirton/rpmbuild/SOURCES/bgscripts-1.1-28/usr/share/bgscripts/framework.sh
EOFLOCATIONS
test -z "${frameworkscript}" && echo "$0: framework not found. Aborted." 1>&2 && exit 4
. ${frameworkscript} || echo "$0: framework did not run properly. Aborted." 1>&2
### CUSTOM WRAPPER BEGINS HERE
pwd="$( pwd )"
psout="$( ps -ef )"
parentprocess="$( ps -ef | grep -iE -- "${thisppid}" | grep -viE -- "grep.*-iE.*--" )"
/usr/share/bgscripts/send.sh -hs "bgscripts alert ${server}: ${scriptfile}" bgstack15@gmail.com <<EOF
----- Description -----
This alert means that script "${scriptfile}" was called, and you need to fix it because /usr/bgscripts/* has been deprecated and will be removed in a future version.
----- Debug info-----
pwd: ${pwd}
Scriptdir: ${scriptdir}
Scriptfile: ${scriptfile}
All parameters: $@
Server: ${server}
Now: ${now}
Thisos: ${thisos}
Thisflavor: ${thisflavor}
Thisppid: ${thisppid}
Parent process: ${parentprocess}
----- Process list -----
${psout}
EOF
### CALL NEW LOCATION
/usr/share/bgscripts/${scriptfile} "${@}"

So if something of mine calls /usr/bgscripts/bgscripts.bashrc, this wrapper script will throw an email alert, and then redirect the script call so workflows are not interrupted!

The very first production use of the wrapper script was when I logged onto my test Ubuntu box to conduct a deep-dive search (more on that in the next heading) of scripts that call framework.sh. I got an email right away, saying I had dot-sourced the bashrc script. Looking at the diagnostic info, I was reminded that I tended to hardcode into my ~/.bashrc the call to /usr/bgscripts/bgscripts.bashrc.

I have now updated that to point to /usr/bin/bp, so in the future it will point to wherever I want it to. However, I seriously doubt the location will change now. My package is now FHS 3.0 compliant, and I don’t want to break that.

Deep dive search

So, I wanted to conduct a deep-dive search of all shell scripts (defined by me as everything ending in .sh, because I almost always use the extension) on all systems that refer to framework.sh, which is going to be the big hangup. So I whipped up this oneliner.
sudo updatedb; locate .sh | grep -iE "\.sh$" | grep -viE "\/usr\/src|\/usr\/share|\/usr\/lib|\/home\/.*\/rpmbuild/|\/home\/work\/.*clean" | xargs grep -iE "framework\.sh"

Now, an reading of my code shows that many of my scripts do a lookup for framework.sh in various locations, including ./framework.sh, ~/framework.sh, /usr/local/bin/framework.sh, and so on. You can observe this pattern in my wrapper script in this post.

So the serach will catch those, but I will recognize those blocks of code because they are just the filename on a separate line (in a here-doc) and as long as I see the /usr/share/bgscripts/framework.sh final resting place of framework, I’ll be satisfied.

References

Weblinks

  1. Filesystem hierarchy standard 3.0 http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
  2. FHS 3.0 in pdf http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
  3. Here document https://en.wikipedia.org/wiki/Here_document