Bug 218323 - www/firefox: firefox-esr (v45) package fails to run
Summary: www/firefox: firefox-esr (v45) package fails to run
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-pkg (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-03 11:36 UTC by MMacD
Modified: 2018-09-03 19:19 UTC (History)
3 users (show)

See Also:
jbeich: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MMacD 2017-04-03 11:36:08 UTC
After installing the -esr (v45) package under 10.3 RELEASE, it fails to run although the problems reported during the install don't appear to be immediately-fatal ones.

6:18:13 Mon, 03Apr                                                                       [fastcat:root]~> pkg install firefox-esr
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
pkg: gstreamer1-plugins-lame has a missing dependency: lame
The following 12 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    firefox-esr: 45.8.0_1,1
    libav: 11.7_5
    vo-aacenc: 0.1.3_1
    opencv2: 2.4.13.1_5
    nss: 3.30
    alsa-plugins: 1.1.1_1
    soundtouch: 1.9.2_2
    libevent2: 2.0.22_1

Installed packages to be UPGRADED:
    spidermonkey170: 17.0.0_1 -> 17.0.0_4
    nspr: 4.12 -> 4.14
    enchant: 1.6.0_5 -> 1.6.0_7
    hunspell: 1.3.3 -> 1.6.0

Number of packages to be installed: 8
Number of packages to be upgraded: 4

The process will require 191 MiB more space.
46 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching firefox-esr-45.8.0_1,1.txz: 100%   42 MiB 107.3kB/s    06:51
Fetching spidermonkey170-17.0.0_4.txz: 100%    1 MiB  85.2kB/s    00:15
Fetching nspr-4.14.txz: 100%  229 KiB  78.2kB/s    00:03
Fetching enchant-1.6.0_7.txz: 100%   43 KiB  43.7kB/s    00:01
Fetching hunspell-1.6.0.txz: 100%  296 KiB  60.6kB/s    00:05
Fetching nss-3.30.txz: 100%    2 MiB  87.0kB/s    00:21
Fetching alsa-plugins-1.1.1_1.txz: 100%   24 KiB  24.8kB/s    00:01
Fetching soundtouch-1.9.2_2.txz: 100%   67 KiB  69.1kB/s    00:01
Fetching libevent2-2.0.22_1.txz: 100%  258 KiB  87.9kB/s    00:03
Checking integrity... done (0 conflicting)
[1/12] Upgrading nspr from 4.12 to 4.14...
[1/12] Extracting nspr-4.14: 100%
[2/12] Upgrading hunspell from 1.3.3 to 1.6.0...
[2/12] Extracting hunspell-1.6.0: 100%
[3/12] Installing vo-aacenc-0.1.3_1...
[3/12] Extracting vo-aacenc-0.1.3_1: 100%
[4/12] Installing opencv2-2.4.13.1_5...
[4/12] Extracting opencv2-2.4.13.1_5: 100%
[5/12] Installing nss-3.30...
[5/12] Extracting nss-3.30: 100%
[6/12] Installing alsa-plugins-1.1.1_1...
[6/12] Extracting alsa-plugins-1.1.1_1: 100%
[7/12] Installing soundtouch-1.9.2_2...
[7/12] Extracting soundtouch-1.9.2_2: 100%
[8/12] Installing libevent2-2.0.22_1...
[8/12] Extracting libevent2-2.0.22_1: 100%
[9/12] Installing firefox-esr-45.8.0_1,1...
[9/12] Extracting firefox-esr-45.8.0_1,1: 100%
[10/12] Upgrading spidermonkey170 from 17.0.0_1 to 17.0.0_4...
[10/12] Extracting spidermonkey170-17.0.0_4: 100%
[11/12] Upgrading enchant from 1.6.0_5 to 1.6.0_7...
[11/12] Extracting enchant-1.6.0_7: 100%
[12/12] Installing libav-11.7_5...
[12/12] Extracting libav-11.7_5: 100%
Message from vo-aacenc-0.1.3_1:
===>   NOTICE:

The vo-aacenc port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues, not be up-to-date, or even be removed in
the future. To volunteer to maintain this port, please create an issue at:

https://bugs.freebsd.org/bugzilla

More information about port maintainership is available at:

https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-port
Message from firefox-esr-45.8.0_1,1:
======================================================================

smb:// issues (Gvfs/GIO option):
Network group, machine, and share browsing does not work correctly.

sftp:// (Gvfs/GIO option):
Only sftp access using public key authentication works.  To easily
setup public key authentication to "remote_host":

ssh-keygen
cat ~/.ssh/id_rsa.pub | ssh remote_host "cat >> .ssh/authorized_keys"

The SSH server on remote_host must allow pub key authentication.

======================================================================

Any bug reports should be addressed to the maintainers at:
    gecko@FreeBSD.org
You may also Cc: freebsd-ports@FreeBSD.org. Please do not send
bug reports to any other addresses.

Please include the following information with any bug report:
* Output from 'uname -a'.
* Output from 'ident /usr/ports/www/firefox/Makefile'
* Where/when did the problem occur: configuring, building, or
    running firefox
* How can you reproduce the problem?

Thank you for your help in testing and reporting bugs, and we hope you
enjoy using Firefox.
###########################
6:41:49 Mon, 03 Apr
[fastcat:root]~> uname -a
FreeBSD fastcat.local.lan 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264:
Fri Mar 25 02:10:02 UTC 2016
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
###########################
6:41:53 Mon, 03 Apr
[fastcat:root]~> ident /usr/ports/www/firefox/Makefile
/usr/ports/www/firefox/Makefile:
     $FreeBSD: head/www/firefox/Makefile 436907 2017-03-25 16:51:30Z jbeich $
Comment 1 Jan Beich freebsd_committer freebsd_triage 2017-04-03 13:28:22 UTC
Looks like a pilot error. Otherwise, re-file the bug against pkg(8) describing in detail the kind of workflow you have in mind.

(In reply to MMacD from comment #0)
>          [fastcat:root]~> pkg install firefox-esr
[...]
> Installed packages to be UPGRADED:
>     spidermonkey170: 17.0.0_1 -> 17.0.0_4
>     nspr: 4.12 -> 4.14
>     enchant: 1.6.0_5 -> 1.6.0_7
>     hunspell: 1.3.3 -> 1.6.0

Partial package upgrades are fragile and aren't really supported. Before installing new packages consider running "pkg upgrade".

> New packages to be INSTALLED:
>     firefox-esr: 45.8.0_1,1
>     libav: 11.7_5
>     vo-aacenc: 0.1.3_1

libav is NOT supported by either multimedia@ or gecko@ teams. No port in the tree depends on those by default.
vo-aacenc is also unmaintained and not enabled by default.

> Installed packages to be UPGRADED:
>    libevent2: 2.0.22_1

Probably 2017Q1 package set from /quarterly repo (default on releases).

>     $FreeBSD: head/www/firefox/Makefile 436907 2017-03-25 16:51:30Z jbeich $

The port builds a different package: firefox, not firefo-esr. Did you step on the landmine of mixing /head ports and /quarterly packages? In such a case "pkg upgrade" may not help unless you add -f (force) flag, see pkg-upgrade(8) manpage.
Comment 2 MMacD 2017-04-03 17:52:03 UTC
"Looks like a pilot error."

It's not, though. Pkg is meant to be the installer and manager for pre-built apps and subsystems.  That's how I used it.

"Partial package upgrades are fragile and aren't really supported. Before installing new packages consider running "pkg upgrade"."

Something is BADLY broken with FreeBSD's process and engineering if we have to do a full upgrade of all packages in order to install another one. That's absolute lunacy.  

If you think I'm wrong about that, imagine being told by Microsoft and Apple that customers must buy and install the latest editions of all their installed applications before they can successfully buy and install an additional, unrelated product. 

There'd be thousands of people on the companies' front lawns with torches, pitchforks, and nooses before the announcement's echos died away.
Comment 3 MMacD 2017-04-03 18:08:43 UTC
"The port builds a different package: firefox, not firefo-esr. Did you step on the landmine of mixing /head ports and /quarterly packages? In such a case "pkg upgrade" may not help unless you add -f (force) flag, see pkg-upgrade(8) manpage."

I'm not sure what you're talking about.  I first tried to install the v52 pkg, which had problems.  This report is about the v45 esr package I tried to install this morning.  The errors are very similar to those from my attempt to install v52.  I didn't mix anything, I just tried to install 2 different packages:  "pkg install firefox" yesterday and "pkg install firefox-esr" this morning.
Comment 4 Jan Beich freebsd_committer freebsd_triage 2017-04-03 19:20:53 UTC
Debugging pkg-install(8) issues is outside gecko@ scope. Re-assigning.
Comment 5 MMacD 2017-04-03 20:22:16 UTC
Okay, I'm baffled.  You reassigned it as a pkg bug.  Who built those FF packages?  Surely it was one of the gecko team?  How were the problems not caught during those builds?
Comment 6 Jan Beich freebsd_committer freebsd_triage 2017-04-04 01:01:17 UTC
Each build is automated on the package cluster in a clean jail. The list of jails is available on http://pkg-status.freebsd.org/ where with enough clicks you can get to the build logs e.g.,

http://beefy2.nyi.freebsd.org/data/103amd64-quarterly/436927/logs/firefox-esr-45.8.0_1,1.log  (last 2017Q1)
http://beefy2.nyi.freebsd.org/data/103amd64-quarterly/437473/logs/firefox-esr-45.8.0_3,1.log (first 2017Q2)

2017Q1 has reached EOL as soon as 2017Q2 was built. comment 0 shows firefox-esr from 2017Q1 installed on top of what appears 2016Q[1-3] set. Even then the solver should be able to figure out when to upgrade dependencies. Maybe it's confused by some packages built with non-default options or coming from a custom repo (only guesses due to not enough details). A year ago (or more) firefox dependend on gstreamer but it has never pulled libav port (bundled version was used until ports r397984).

In short, "pkg install" alone is usually safe on a /quarterly repo until it switches to a new set. No one does QA for mixed sets - too many permutations.

comment 0 also said "it fails to run" without quoting the actual errors suggests the reporter knows better than maintainer which is why the focus is on pkg and not firefox. ;)
Comment 7 MMacD 2017-04-04 13:53:45 UTC
"comment 0 also said "it fails to run" without quoting the actual errors suggests the reporter knows better than maintainer which is why the focus is on pkg and not firefox. ;)"

Well, that's the thing -- it didn't say anything, it just failed to run.  If it wrote something to some log (what log?) it didn't say anything about that, either.  It should at a *minimum* write STDOUT with "I couldn't run.  Details in /usr/local/logs/firefox-esr.log" or similar.

The way fBSD apps report problems gets up my human-factors nostril.  It reminds me of the original C compiler:  "you have an error".  Oh? Do you think you're adding to my knowledge, you ridiculous piece of software?  I actually worked out for myself that there was an error when my code didn't execute!
Comment 8 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2017-04-04 18:19:18 UTC
Removing bugmeister@ from Cc: bug scope does not include bugtracker operations or triage/resolution procedures.
Comment 9 Walter Schwarzenfeld 2018-01-17 13:03:58 UTC
We have version 52.5.3. Overcome by events?