| Summary: | mail-client/thunderbird-115.2.3[pgo] should depend on net-libs/libotr? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Dec <moog621> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | trivial | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
It's been going for 27 hours now. I'm pretty sure the pgo stage is bugged. I don't think Thunderbird upstream even wants to implement the pgo. It's been broken since 68. The reason why the mask is "visible" but not "available" in Gentoo is that the ebuild is 99 % identical to Firefox. It's easier to use profiles and mask the broken functionality instead of always stripping the pgo-related bits off when doing version bumps. |
I've noticed that when pgo is in USE, Thunderbird will try to launch Xvfb, then itself, and then try to load libotr.so, but to no avail. I've repeated the process, but it doesn't seem to be improving things. In both cases: 1. We don't have net-libs/libotr 2. We have net-libs/libotr Thunderbird still takes ages to do its pgo thing, and leaves no log messages to let us know how's progress. Is this supposed to take this long? Is libotr really needed? I don't know, because I didn't wait long enough to find out out of fear that the process may have entered an infinite loop, or hanged, due to lack of libotr. There's no output to say it didn't. Reproducible: Always Steps to Reproduce: 1. USE=pgo emerge -1v =mail-client/thunderbird-115.2.3 2. Wait to the pgo stage 3. Notice the logs Actual Results: Common: 66:58.49 gmake: Leaving directory '/var/tmp/portage/mail-client/thunderbird-115.2.3/work/thunderbird_build/instrumented' console.warn: services.settings: Ignoring preference override of remote settings server console.warn: services.settings: Allow by setting MOZ_REMOTE_SETTINGS_DEVTOOLS=1 in the environment [ImapModuleLoader] Using nsImapService.cpp ATTENTION: default value of option mesa_glthread overridden by environment. JavaScript error: resource:///modules/CalStartupService.jsm, line 18: uncaught exception: ParserError: invalid line (no token ";" or ":") "Europe/Warsaw[2023c]" JavaScript error: resource:///modules/CalStartupService.jsm, line 18: NS_ERROR_XPC_JS_THREW_JS_OBJECT: ParserError: invalid line (no token ";" or ":") "Europe/Warsaw[2023c]"'ParserError: invalid line (no token ";" or ":") "Europe/Warsaw[2023c]"' when calling method: [calIStartupService::startup] [Parent 25660, Main Thread] WARNING: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed: 'glib warning', file /var/tmp/portage/mail-client/thunderbird-115.2.3/work/thunderbird-115.2.3/toolkit/xre/nsSigHandlers.cpp:167 (thunderbird:25660): GLib-GIO-CRITICAL **: 18:15:23.482: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed [Parent 25660, Main Thread] WARNING: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed: 'glib warning', file /var/tmp/portage/mail-client/thunderbird-115.2.3/work/thunderbird-115.2.3/toolkit/xre/nsSigHandlers.cpp:167 (thunderbird:25660): GLib-GIO-CRITICAL **: 18:15:23.483: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed [Parent 25660, Main Thread] WARNING: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed: 'glib warning', file /var/tmp/portage/mail-client/thunderbird-115.2.3/work/thunderbird-115.2.3/toolkit/xre/nsSigHandlers.cpp:167 (thunderbird:25660): GLib-GIO-CRITICAL **: 18:15:23.483: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed [Parent 25660, Main Thread] WARNING: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed: 'glib warning', file /var/tmp/portage/mail-client/thunderbird-115.2.3/work/thunderbird-115.2.3/toolkit/xre/nsSigHandlers.cpp:167 (thunderbird:25660): GLib-GIO-CRITICAL **: 18:15:23.483: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed JavaScript error: resource:///modules/CalCalendarManager.jsm, line 444: TypeError: right-hand side of 'in' should be an object, got undefined JavaScript error: chrome://calendar/content/calendar-management.js, line 402: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "right-hand side of 'in' should be an object, got undefined" {file: "resource:///modules/CalCalendarManager.jsm" line: 444}]'[JavaScript Error: "right-hand side of 'in' should be an object, got undefined" {file: "resource:///modules/CalCalendarManager.jsm" line: 444}]' when calling method: [calICalendarManager::registerCalendar] console.debug: "Found 0 public keys and 0 secret keys (0 protected, 0 unprotected)" console.error: ({}) console.error: (new TypeError("gDownloadLastDir is undefined", "resource://gre/modules/HelperAppDlg.sys.mjs", 343)) console.debug: "Trying to load /var/tmp/portage/mail-client/thunderbird-115.2.3/work/thunderbird_build/instrumented/dist/thunderbird/libotr.so" console.debug: "Trying to load libotr.so from system's standard library locations" If we don't have libotr: console.debug: "Trying to load libotr.so.5 from system's standard library locations" console.debug: "Trying to load libotr.so from system's standard library locations" console.log: (new Error("Cannot load required OTR library", "resource:///modules/OTRLib.sys.mjs", 110)) If we have libotr: console.debug: "Successfully loaded OTR library libotr.so from system's standard library locations" Expected Results: I'm not sure. Neither scenario seems to help unhanging pgo stage. This bug report is more like an open question - should this depend on libotr at the ebuild's BDEPEND level, or not?