Firefox KDE support

[shadeslayer]

In addition to Firefox, the developers also working on getting the KDE SC 4.10 betas and KDE 4.9.4 bug fix updates out, which is why updates can take a bit more time.

[MountainX]

Hi everyone
Just wanted to let you know that firefox has been updated to v17 for Precise and Quantal. Please do post here if you find any issues, alternatively, please contact us via https://launchpad.net/~blue-shell/+contactuser

We will try and resolve your issues ASAP

Ninja Edit : Precise packages still need to be built.

Thank you so much for this!!!

I also want to share my steps for installing and upgrading Firefox on Kubuntu 12.04.

First, set up the repo:
(see http://www.bluemintlinux.com/2012/08...n-firefox.html)

sudo apt-add-repository ppa:blue-shell/firefox-kde
sudo apt-get update
sudo apt-get install firefox firefox-kde-support

Then hold firefox upgrades so the customized firefox version with kde support doesn't get overwritten by normal updates.
(see http://serverfault.com/questions/384...wngrade-vsftpd, for example)
echo firefox hold | dpkg –set-selections
echo firefox-kde-supported hold | dpkg --set-selections

This will prevent your customised packages being overwritten as part of the normal update processes. However, even with the hold set, Firefox can now be manually upgraded like this:

sudo apt-get install firefox firefox-kde-support
The following held packages will be changed:
firefox firefox-kde-support
The following packages will be upgraded:
firefox firefox-kde-support

[SteveRiley]

Placing a hold is no guarantee that an update from the normal repository won't overwrite Firefox from Blue Shell. You have to pin the Blue Shell PPA at a higher priority. Here's now:

sudo add-apt-repository ppa:blue-shell/firefox-kde
echo -e 'Package: *' | sudo tee /etc/apt/preferences.d/blue-shell-firefox > /dev/null
echo -e 'Pin: release o=LP-PPA-blue-shell-firefox-kde' | sudo tee -a /etc/apt/preferences.d/blue-shell-firefox > /dev/null
echo -e 'Pin-Priority: 1000' | sudo tee -a /etc/apt/preferences.d/blue-shell-firefox > /dev/null
sudo apt-get update
sudo apt-get install --no-install-recommends firefox firefox-kde-support

[MountainX]

Placing a hold is no guarantee that an update from the normal repository won't overwrite Firefox from Blue Shell. You have to pin the Blue Shell PPA at a higher priority. Here's now:

sudo add-apt-repository ppa:blue-shell/firefox-kde
echo -e 'Package: *' | sudo tee /etc/apt/preferences.d/blue-shell-firefox > /dev/null
echo -e 'Pin: release o=LP-PPA-blue-shell-firefox-kde' | sudo tee -a /etc/apt/preferences.d/blue-shell-firefox > /dev/null
echo -e 'Pin-Priority: 1000' | sudo tee -a /etc/apt/preferences.d/blue-shell-firefox > /dev/null
sudo apt-get update
sudo apt-get install --no-install-recommends firefox firefox-kde-support

Thanks. My hold method was an attempt to get around the issue mentioned by Mr_Bumpy in post #178. However, I now have another idea that might be better. I appreciate any comments on it:

create and edit these two files so they have the contents shown here:
cat /etc/apt/preferences.d/blue-shell-firefox-kde-pin-1001

Package: *
Pin: release o=LP-PPA-blue-shell-firefox-kde
Pin-Priority: 1001

cat /etc/apt/preferences.d/alexey-ivanov-firefox-kde-pin-1000

Package: *
Pin: release o=LP-PPA-alexey-ivanov-firefox-kde
Pin-Priority: 1000

run sudo -apt-get update, then check: apt-cache policy firefox. Here are my current results:

sudo apt-cache policy firefox

firefox:
  Installed: 16.0.2+build1-0ubuntu0.12.04.1+ppa1
  Candidate: 17.0+build2-0ubuntu0.12.04.2~ppa2
  Version table:
     17.0.1+build1-precise3 0
       1000 [url]http://ppa.launchpad.net/alexey-ivanov/firefox-kde/ubuntu/[/url] precise/main amd64 Packages
     17.0.1+build1-0ubuntu0.12.04.1 0
        500 [url]http://us.archive.ubuntu.com/ubuntu/[/url] precise-updates/main amd64 Packages
        500 [url]http://security.ubuntu.com/ubuntu/[/url] precise-security/main amd64 Packages
     17.0+build2-0ubuntu0.12.04.2~ppa2 0
       1001 [url]http://ppa.launchpad.net/blue-shell/firefox-kde/ubuntu/[/url] precise/main amd64 Packages
 *** 16.0.2+build1-0ubuntu0.12.04.1+ppa1 0
        100 /var/lib/dpkg/status
     14.0.1+build1-0ubuntu0.12.04.1+KDE 0
        500 [url]http://ppa.launchpad.net/hrvojes/firefox-kde/ubuntu/[/url] precise/main amd64 Packages
     11.0+build1-0ubuntu4 0
        500 [url]http://us.archive.ubuntu.com/ubuntu/[/url] precise/main amd64 Packages

You can exchange the pin priorities of those two PPAs if you wish.

[MountainX]

Placing a hold is no guarantee that an update from the normal repository won't overwrite Firefox from Blue Shell. You have to pin the Blue Shell PPA at a higher priority.

I'm not an expert on this, so I accepted your statement as true and I changed my method. Next I decided to try to understand the issue better. So I went here.

It says, "Holding a package basically means you're telling the package manager to keep the current version no matter what." That statement would seem to imply that you aren't correct. Care to explain further?

I get the feeling that my original method is the better choice if you want to be absolutely sure you don't lose firefox-kde-support.

[SteveRiley]

Here's the scenario:

* Regular repository contains version 25.
* Blue Shell contains version 25.
* You install from Blue Shell, and issue the APT hold.
* Regular repository updates to version 26.
* Blue Shell still contains version 25.
* apt-get upgrade and apt-get dist-upgrade will not replace Blue Shell 25 with regular 26.
* However, apt-get install firefox will replace Blue Shell 25 with regular 26.

Holding is appropriate when the desired goal is to keep a particular version of a package when that package is generally available only from one repository. Holds are honored during upgrades and dist-upgrades, but are not honored when a specific package name is included on the command line.

Pinning is appropriate when the desired goal is to ensure that all installs, whether specific or via an upgrade/dist-upgrade, come from a particular PPA. In the case with Blue Shell, we have two conflicting and not always simultaneously-updated sources of binaries: the regular repository and the Blue Shell PPA.

The process to pin the PPA is a one-time-only sequence; once accomplished, users don't have to manually track upgrades in the PPA, because they'll be automatically installed.

[MountainX]

Thanks. It all makes sense now. Pinning, once set up, is easier. But if the repos disappear (or there is a temporary issue, as was discussed back in post #178), your last kde-enabled firefox will be replaced by Ubuntu's version. Conversely, when using the "hold" approach, you have to manually upgrade firefox each time the PPA releases a new version, but you will never be surprised by an unexpected replacement of your kde-enabled firefox. For me, using a hold is preferrable, but I understand many users may want to use pinning.

[SteveRiley]

The issue earlier was an unusual case where the existing binary in the PPA disappeared before the replacement build was ready. Usually that doesn't happen.

[MountainX]

Another example, where it happened to me, was when sumski's PPA was taken down. I had the non-KDE version of firefox before I knew what was going on. That's always an unpleasant surprise. I would just rather control this package's updates manually, using a hold. If necessary, I would rather stay with a prior version of firefox, for example, than lose KDE integration. That's just me.

[shadeslayer]

The issue earlier was an unusual case where the existing binary in the PPA disappeared before the replacement build was ready. Usually that doesn't happen.

Uh, yeah, chalk that one up to me being ultra sleepy and not noticing I was doing a source copy instead of a binary copy.

I've copied over the 17.01 binaries over to the blue-shell ppa now, let me know if there are issues.

On a separate note, I'm now running raring and testers are a bit hard to come by, would someone like to volunteer for QA'ing my uploads before they're released to the blue-shell PPA?

[Wallace]

Uh, yeah, chalk that one up to me being ultra sleepy and not noticing I was doing a source copy instead of a binary copy.

I've copied over the 17.01 binaries over to the blue-shell ppa now, let me know if there are issues.

On a separate note, I'm now running raring and testers are a bit hard to come by, would someone like to volunteer for QA'ing my uploads before they're released to the blue-shell PPA?

No issues here..thanks!

[ronw]

On a separate note, I'm now running raring and testers are a bit hard to come by, would someone like to volunteer for QA'ing my uploads before they're released to the blue-shell PPA?

I run raring in a Virtualbox VM if that would be useful for testing purposes.

[dequire]

I run raring in a Virtualbox VM if that would be useful for testing purposes.

That should work fine. Shadeslayer I can test as well. Ping me here or on IRC with details.

[SteveRiley]

On a separate note, I'm now running raring and testers are a bit hard to come by, would someone like to volunteer for QA'ing my uploads before they're released to the blue-shell PPA?

When I return home from my current trip (in DC now), I will rebuild one of my laptops with Raring.

[shadeslayer]

Actually, what I meant was that I wanted someone to QA the Precise and Quantal builds :P