Ubuntu 16.04, 16.10, 17.04, 18.04 Debian 8, 9 Pale Moon repositories

[jiawen]

Downloading from Google Drive isn't working for me (apparently due to this Google bug), and I get 504 or other errors on the Opensuse repositories. I use Linux Mint 17.3 (based on 14.04). Are there other ways to download the palemoon debs?

[stevepusser]

OK, I uploaded them to archive.org, do these direct links for the Trusty debs work?

32 bit

64-bit

[jiawen]

Works brilliantly for me; I'm writing this using 28.1.0. Thank you.

[stevepusser]

The Firejail sandboxing app in the same repository has been updated to the current 0.9.56: https://build.opensuse.org/package/show ... r/firejail

It will be available if you've already added the palemoon repository.

Debian Testing builds are disabled because it's already available there.

[stevepusser]

Though Ubuntu 18.10 has been officially released, the openSUSE build service hasn't yet added support for it. Usually they add new releases in a day or so, so I'll be watching for it.

[stevepusser]

I see there's now OBS support, so 18.10 repo: ACTIVATE!

It may take an hour or so to finish or fail compiling, so give it some time.

[stevepusser]

Apparently the OBS's 18.10 64-bit build machines were being overworked the first day, as the PM build would hang for hours and then fail, but it eventually succeeded after I triggered rebuilds a couple times.

If a mod sees this, the original thread title can be modified to remove Debian 7 and Ubuntu 14.04, then add 18.10 repos.

Mod edit: thread title updated.

[smoki]

If a mod sees this, the original thread title can be modified to remove Debian 7 and Ubuntu 14.04, then add 18.10 repos.

May i ask why you still build and keep Ubuntu 16.10, 17.04, 17.10... these are AFAIK not supported distro versions anymore.

https://wiki.ubuntu.com/Releases

That 16.10 is not supported even for more than 2 years

Just asking, you know Sounds total illogical to me, that something which is still supported is unsupported, while something which is not supported is supported

[stevepusser]

Generally, as soon as I remove some distro's packages, I get messages from people asking me to restore them...

But I can free up resources on the OBS that they are donating gratis by removing those packages, and they are easy to restore by clicking a checkbox, so I'll remove them unless I hear otherwise.

[stevepusser]

28.2.0 packages are building on the OBS.

Manually built debs for Ubuntu 14.04 with the trusty gcc-5 from ppa:ubuntu-toolchain-r/test are here:

32-bit (i386): https://archive.org/download/Palemoon_2 ... 1_i386.deb

64-bit (amd64): https://archive.org/download/Palemoon_2 ... _amd64.deb

Update: all builds succeeded except for 64-bit Ubuntu 18.04, which ran out of virtual memory with the settings of 10GB RAM plus 2 GB swap. I bumped the RAM up to 16 GB, builds are waiting for machines with that much RAM to be available, but the previously successful builds remain accessible in their repos.

If that doesn't work, I can try to limit the amount of RAM needed by setting the maximum threads used for a build in mozconfig to something like six instead of the default "use all available", which I think is eight on the OBS.

Update: I went with the six thread option, because it seemed to be taking quite a while for any 16 GB workers to be available. This means there won't be any packages available until these new builds finish.

[Walter Dnes]

Update: I went with the six thread option, because it seemed to be taking quite a while for any 16 GB workers to be available. This means there won't be any packages available until these new builds finish.

Gentoo users run into stuff like this, because almost all packages are built from source in Gentoo. Someone has gone to the trouble of testing various values, and has come to the conclusion that "MAKEOPTS=”-j${core} +1″ is NOT the best optimization" https://blogs.gentoo.org/ago/2013/01/14/makeopts-jcore-1-is-not-the-best-optimization/

It looks like using exact number of cores is the fastest, or very close to it, by a few seconds. And of course, you can get away with less ram. Try 4 threads, and see if it makes any noticable difference. I don't know how much control you have over the build script on the OBS machine. On my system, the buildscript (written in bash) includes the following code...

# Set cpucount to count of cores, but do not exceed 4,
# due to diminishing returns.
cpucount=`grep -c "^flags" /proc/cpuinfo`
[ ${cpucount} -gt 4 ] && cpucount=4
export cpucount

...and the mozconfig has the line...

mk_add_options MOZ_MAKE_FLAGS="-j${cpucount}"

This finds the number of available cores on the machine, and sets MOZ_MAKE_FLAGS accordingly, which is optimal.

[stevepusser]

I just used

Code: Select all

mk_add_options MOZ_MAKE_FLAGS="-j6

in my mozconfig. I had that option commented out with an explanation on why it might be necessary to use on a machine with more threads and lower RAM, such as a 6 core-12 thread laptop with 8GB of RAM like some current budget gaming laptops. It shouldn't be necessary on something like another MX packager has, 16 threads and 32 GB RAM.

[stevepusser]

Pale Moon 28.2.1 building to fix those history and bookmark issues--should be ready in the OBS repo within an hour or so. The Trusty manual builds will take longer, though.

Edit: Trusty debs (Ubuntu 14.04), requiring gcc-5, are done.

32-bit: https://archive.org/download/Palemoon_2 ... y_i386.deb

64-bit: https://archive.org/download/Palemoon_2 ... _amd64.deb

[stevepusser]

Ubuntu Trusty debs for Pale Moon 28.2.2, requiring gcc-5:

32-bit: https://archive.org/download/Palemoon_2 ... y_i386.deb

64-bit: https://archive.org/download/Palemoon_2 ... _amd64.deb

[Moonchild]

Just a note for people getting this early release: it is legit, and it doesn't look like there are any issues so the builds are safe to use. You'll have to wait for the release notes until the version is officially released for all platforms, though, which will be later today (approx 15:00 UTC)

[stevepusser]

Update: I went with the six thread option, because it seemed to be taking quite a while for any 16 GB workers to be available. This means there won't be any packages available until these new builds finish.

Gentoo users run into stuff like this, because almost all packages are built from source in Gentoo. Someone has gone to the trouble of testing various values, and has come to the conclusion that "MAKEOPTS=”-j${core} +1″ is NOT the best optimization" https://blogs.gentoo.org/ago/2013/01/14/makeopts-jcore-1-is-not-the-best-optimization/

It looks like using exact number of cores is the fastest, or very close to it, by a few seconds. And of course, you can get away with less ram. Try 4 threads, and see if it makes any noticable difference. I don't know how much control you have over the build script on the OBS machine. On my system, the buildscript (written in bash) includes the following code...

# Set cpucount to count of cores, but do not exceed 4,
# due to diminishing returns.
cpucount=`grep -c "^flags" /proc/cpuinfo`
[ ${cpucount} -gt 4 ] && cpucount=4
export cpucount

...and the mozconfig has the line...

mk_add_options MOZ_MAKE_FLAGS="-j${cpucount}"

This finds the number of available cores on the machine, and sets MOZ_MAKE_FLAGS accordingly, which is optimal.

I recently also discovered that the Debian dpkg-buildpackage command, besides the standard "-jN" flag, also supports "-jauto" to use all available threads automatically, as well as "-JN" to force the number of build threads for packages that ignore "-jN" like Pale Moon. I guess I should have read the man page earlier. .

[martywd]

@stevepusser

FYI, Linux Mint 19's 'Update Manager' is throwing this error today (also getting it running 'apt update',etc.):

An error occurred during the signature verification. The repository is not updated and the previous index files will be used.
GPG error: http://download.opensuse.org/repositori ... untu_18.04
Release:
The following signatures were invalid: EXPKEYSIG 0FAD31CA8719FCE4 home:stevenpusser OBS Project <home:stevenpusser@build.opensuse.org>Failed to fetch http://download.opensuse.org/repositori ... elease.gpg
The following signatures were invalid: EXPKEYSIG 0FAD31CA8719FCE4 home:stevenpusser OBS Project <home:stevenpusser@build.opensuse.org>Some index files failed to download.
They have been ignored, or old ones used instead.

.

[martywd]

@stevepusser

FYI, Linux Mint 19's 'Update Manager' is throwing this error today (also getting it running 'apt update',etc.):

An error occurred during the signature verification. The repository is not updated and the previous index files will be used.
GPG error: http://download.opensuse.org/repositori ... untu_18.04
Release:
The following signatures were invalid: EXPKEYSIG 0FAD31CA8719FCE4 home:stevenpusser OBS Project <home:stevenpusser@build.opensuse.org>Failed to fetch http://download.opensuse.org/repositori ... elease.gpg
The following signatures were invalid: EXPKEYSIG 0FAD31CA8719FCE4 home:stevenpusser OBS Project <home:stevenpusser@build.opensuse.org>Some index files failed to download.
They have been ignored, or old ones used instead.

.

Ok, I see the problem, the key expired. For Linux Mint 19 / Ubuntu 18.04, in a terminal window run the following commands to fix:

Code: Select all

wget -nv https://download.opensuse.org/repositories/home:stevenpusser/xUbuntu_18.04/Release.key -O Release.key

sudo apt-key add Release.key

sudo apt update

.

[Isengrim]

I noticed the same thing, and this solution worked for me as well. Do repo keys routinely expire like this?

[stevepusser]

Apparently the OBS keys do; just got a PM about my Veracrypt repo for Debian.