Summary: | www/firefox: firefox-esr (v45) package fails to run | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | MMacD <scratch65535> |
Component: | Individual Port(s) | Assignee: | freebsd-pkg (Nobody) <pkg> |
Status: | Closed Overcome By Events | ||
Severity: | Affects Only Me | CC: | gecko, gonzo, w.schwarzenfeld |
Priority: | --- | Flags: | jbeich:
maintainer-feedback+
|
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
MMacD
2017-04-03 11:36:08 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. "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. "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. Debugging pkg-install(8) issues is outside gecko@ scope. Re-assigning. 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? 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 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! Removing bugmeister@ from Cc: bug scope does not include bugtracker operations or triage/resolution procedures. We have version 52.5.3. Overcome by events? |