June 2023 - openSUSE Factory Mozilla - openSUSE Mailing Lists

[Bug 1212259] New: MozillaThunderbird: bundled rnp/Botan, and supporting pluggable OpenPGP providers
by bugzilla_noreply＠suse.com 24 Mar '24

24 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1212259 Bug ID: 1212259 Summary: MozillaThunderbird: bundled rnp/Botan, and supporting pluggable OpenPGP providers Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Mozilla Thunderbird bundles a number of libraries for OpenPGP support: * rnp: https://github.com/rnpgp/rnp and openSUSE:Factory/rnp * (bundled in rnp) https://github.com/rnpgp/sexp * Botan (rnp has an experimental OpenSSL backend too) We should look into un-bundling here due to: * general packaging policy - avoiding bundled libs * especially for crypto routines: shared crypto policy, and maybe to use OpenSSL FIPS? * incorrectly attributed bugs, e.g. bug 1212253 (CVE-2023-29479) considered against MozillaThunderbird and missed for rnp. * there are other compatible and pluggable providers of the Thunderbird plugin: https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp Background: RH dropping Botan https://bugzilla.redhat.com/show_bug.cgi?id=1837512 FC splitting plugin: https://src.fedoraproject.org/rpms/thunderbird/c/edf3b30dbedcb43be087001509… FC system rnp: https://src.fedoraproject.org/rpms/thunderbird/c/0a585f45242a8fc024dfc1761a… -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1212683] New: Intermittent Freezes with Mozilla Firefox 114.0.2
by bugzilla_noreply＠suse.com 15 Jul '23

15 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212683 Bug ID: 1212683 Summary: Intermittent Freezes with Mozilla Firefox 114.0.2 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: jshand2013(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- since latest release of opensuse tumbleweed: Operating System: openSUSE Tumbleweed 20230623 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 Kernel Version: 6.3.9-1.g0df701d-default (64-bit) Graphics Platform: X11 Processors: 2 × AMD A9-9420e RADEON R5, 5 COMPUTE CORES 2C+3G Memory: 7.2 GiB of RAM Graphics Processor: AMD Radeon R5 Graphics Manufacturer: Acer Product Name: Aspire A315-21G System Version: V1.12 i have only been able to get logs relating to this freezing issue from journalctl. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1212101] New: Firefox 1114.0-2.1 immediately crashes at startup.
by bugzilla_noreply＠suse.com 10 Jul '23

10 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212101 Bug ID: 1212101 Summary: Firefox 1114.0-2.1 immediately crashes at startup. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: paul.pgp-7(a)gmx.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Just updated Firefox 113.0.2 -> 114.0 (from https://download.opensuse.org/repositories/mozilla/openSUSE_Tumbleweed/) on a TW system (20230605). Firefox now consistently crashes at startup, no GUI is shown it just immediately brings up the Firefox Crash Reporter dialogue. Tested with a new user and new default Firefox profile, same result, immediate crash. FF 114.o is working OK on Leap 15.4, this appears restricted only to TW. -- You are receiving this mail because: You are the assignee for the bug.

1 53

[Bug 1212650] New: SeaMonkey 2.53.16 won't build due to Python 2/3 issues
by bugzilla_noreply＠suse.com 23 Jun '23

23 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1212650 Bug ID: 1212650 Summary: SeaMonkey 2.53.16 won't build due to Python 2/3 issues Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: psychonaut(a)nothingisreal.com QA Contact: qa-bugs(a)suse.de CC: wolfgang(a)rosenauer.org Target Milestone: --- Found By: --- Blocker: --- Created attachment 867764 --> https://bugzilla.suse.com/attachment.cgi?id=867764&action=edit Patch for the "invalid mode" error when building SeaMonkey Recently the SeaMonkey 2.53.16 package stopped compiling for Tumbleweed: ``` [ 75s] ./mach --log-no-times configure [ 75s] Error running mach: [ 75s] [ 75s] ['--log-no-times', 'configure'] [ 75s] [ 75s] The error occurred in code that was called by the mach command. This is either [ 75s] a bug in the called code itself or in the way that mach is calling it. [ 75s] [ 75s] You should consider filing a bug for this issue. [ 75s] [ 75s] If filing a bug, please include the full output of mach, including this error [ 75s] message. [ 75s] [ 75s] The details of the failure are as follows: [ 75s] [ 75s] ValueError: invalid mode: 'rU' [ 75s] [ 75s] File "/home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/python/mozbuild/mozbuild/build_commands.py", line 98, in configure [ 75s] return driver.configure( [ 75s] ^^^^^^^^^^^^^^^^^ [ 75s] File "/home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/python/mozbuild/mozbuild/controller/building.py", line 1424, in configure [ 75s] self._write_mozconfig_json() [ 75s] File "/home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/python/mozbuild/mozbuild/controller/building.py", line 1505, in _write_mozconfig_json [ 75s] with FileAvoidWrite(mozconfig_json) as fh: [ 75s] File "/home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/python/mozbuild/mozbuild/util.py", line 345, in __exit__ [ 75s] self.close() [ 75s] File "/home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/python/mozbuild/mozbuild/util.py", line 268, in close [ 75s] existing = _open(self.name, self.mode) [ 75s] ^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 75s] File "/home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/python/mozbuild/mozbuild/util.py", line 66, in _open [ 75s] return io.open(path, mode, encoding='utf-8', newline='\n') [ 75s] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 75s] make: *** [GNUmakefile:71: /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/obj-x86_64-pc-linux-gnu/Makefile] Error 1 [ 75s] error: Bad exit status from /var/tmp/rpm-tmp.qjzAE2 (%build) ``` Applying the attached patch, which changes all instances of 'rU' to 'r' and all instances of "rU" to "r" in the Python source files, works around this "invalid mode" error, but then throws up a new one: ``` [ 33s] /usr/bin/gmake -f client.mk MOZ_PARALLEL_BUILD=12 -s configure [ 33s] cd /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/obj-x86_64-pc-linux-gnu [ 33s] /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/configure [ 33s] Creating Python 3 environment [ 33s] /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/third_party/python/virtualenv/virtualenv.py:24: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives [ 33s] import distutils.spawn [ 33s] /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/third_party/python/virtualenv/virtualenv.py:25: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead [ 33s] import distutils.sysconfig [ 33s] Using base prefix '/usr' [ 33s] New python executable in /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/obj-x86_64-pc-linux-gnu/_virtualenvs/init_py3/bin/python3 [ 33s] Also creating executable in /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/obj-x86_64-pc-linux-gnu/_virtualenvs/init_py3/bin/python [ 33s] ERROR: The executable /home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/obj-x86_64-pc-linux-gnu/_virtualenvs/init_py3/bin/python3 is not functioning [ 33s] ERROR: It thinks sys.prefix is '/usr' (should be '/home/abuild/rpmbuild/BUILD/seamonkey-2.53.16/mozilla/obj-x86_64-pc-linux-gnu/_virtualenvs/init_py3') [ 33s] ERROR: virtualenv is not compatible with this system or executable ``` I think the problem might be that the build system is now installing Python 3.x (in addition to Python 2.7) whereas before it was installing only Python 2.7. The spec file has `BuildRequires` only for `python-devel` and `python2-xml` which I think should pull in only Python 2.7, so there might be some other `BuildRequires` that now depends on Python 3.x. According to [the release notes of SeaMonkey 2.53.17beta1](https://www.seamonkey-project.org/releases/seamonkey2.53.17/), the build system in that version now uses Python 3 ([or maybe not](https://bugzilla.mozilla.org/show_bug.cgi?id=1840074)), so perhaps this problem can simply be ignored until the release of 2.53.17. I'm not really sure what else can be done to fix this issue for the 2.53.16 package -- perhaps some of the 2.53.17beta1 changes can be backported, but I don't know if this is sufficient, or if there is perhaps a quicker workaround. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1212101] Firefox 114.0 and 114.0.1 immediately crashes at startup.
by bugzilla_noreply＠suse.com 22 Jun '23

22 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1212101 https://bugzilla.suse.com/show_bug.cgi?id=1212101#c80 --- Comment #80 from Richard Biener <rguenther(a)suse.com> --- Oh, btw, removing all __attribute__((always_inline))s from the TU makes the inline heuristics work and we get everything optimized early. The alternative is to place __attribute__((flatten)) on memsetT and rect_memsetT -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1212101] Firefox 114.0 and 114.0.1 immediately crashes at startup.
by bugzilla_noreply＠suse.com 22 Jun '23

22 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1212101 https://bugzilla.suse.com/show_bug.cgi?id=1212101#c79 --- Comment #79 from Richard Biener <rguenther(a)suse.com> --- Btw, the code actually instantiates skvx::Vec<> stuff via namespace avx { template <typename T> static void memsetT(T buffer[], T value, int count) { static constexpr int N = 32 / sizeof(T); static_assert(N > 0, "T is too big for memsetT"); skvx::Vec<N,T> wideValue(value); while (count >= N) { wideValue.store(buffer); buffer += N; count -= N; } while (count --> 0) { *buffer++ = value; } } inline void memset16(uint16_t buffer[], uint16_t value, int count) { memsetT(buffer, value, count); } ... } and in SkOpts_avx.cpp: namespace SkOpts { void Init_avx() { memset16 = avx::memset16; ... and it expects everything to be fully optimized, eliminating all used template instantiations. But at the time we stream out for LTO that does not have happened. So I don't see how we can avoid this issue besides inventing some "DWIM" mechanism here. I would suggest to add -fno-lto to all TUs that are built with extra machine specific flags as workaround. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1212101] Firefox 114.0 and 114.0.1 immediately crashes at startup.
by bugzilla_noreply＠suse.com 21 Jun '23

21 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1212101 Richard Biener <rguenther(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=110334 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1212101] Firefox 114.0 and 114.0.1 immediately crashes at startup.
by bugzilla_noreply＠suse.com 21 Jun '23

21 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1212101 https://bugzilla.suse.com/show_bug.cgi?id=1212101#c75 --- Comment #75 from Richard Biener <rguenther(a)suse.com> --- (In reply to Martin Sirringhaus from comment #73) > Ok, using `gcc-nm -C {} | grep VecStorage` I get two hits: > > SkOpts_hsw.o > 00000000 W skvx::Vec<16, float>::VecStorage(float) > 00000000 W skvx::Vec<16, float>::VecStorage(float) > 00000000 W skvx::Vec<16, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<16, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<16, unsigned short>::VecStorage(unsigned short) > 00000000 W skvx::Vec<16, unsigned short>::VecStorage(unsigned short) > 00000000 W skvx::Vec<2, float>::VecStorage(float) > 00000000 W skvx::Vec<2, float>::VecStorage(float) > 00000000 W skvx::Vec<2, unsigned char>::VecStorage(unsigned char) > 00000000 W skvx::Vec<2, unsigned char>::VecStorage(unsigned char) > 00000000 W skvx::Vec<2, int>::VecStorage(int) > 00000000 W skvx::Vec<2, int>::VecStorage(int) > 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<2, unsigned long>::VecStorage(unsigned long) > 00000000 W skvx::Vec<2, unsigned long>::VecStorage(unsigned long) > 00000000 W skvx::Vec<2, unsigned short>::VecStorage(unsigned short) > 00000000 W skvx::Vec<2, unsigned short>::VecStorage(unsigned short) > 00000000 W skvx::Vec<32, int>::VecStorage(int) > 00000000 W skvx::Vec<32, int>::VecStorage(int) > 00000000 W skvx::Vec<4, float>::VecStorage(float) > 00000000 W skvx::Vec<4, float>::VecStorage(float) > 00000000 W skvx::Vec<4, unsigned char>::VecStorage(unsigned char) > 00000000 W skvx::Vec<4, unsigned char>::VecStorage(unsigned char) > 00000000 W skvx::Vec<4, int>::VecStorage(int) > 00000000 W skvx::Vec<4, int>::VecStorage(int) > 00000000 W skvx::Vec<4, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<4, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<4, unsigned long>::VecStorage(unsigned long) > 00000000 W skvx::Vec<4, unsigned long>::VecStorage(unsigned long) > 00000000 W skvx::Vec<4, unsigned short>::VecStorage(unsigned short) > 00000000 W skvx::Vec<4, unsigned short>::VecStorage(unsigned short) > 00000000 W skvx::Vec<8, unsigned char>::VecStorage(unsigned char) > 00000000 W skvx::Vec<8, unsigned char>::VecStorage(unsigned char) > 00000000 W skvx::Vec<8, int>::VecStorage(int) > 00000000 W skvx::Vec<8, int>::VecStorage(int) > 00000000 W skvx::Vec<8, unsigned short>::VecStorage(unsigned short) > 00000000 W skvx::Vec<8, unsigned short>::VecStorage(unsigned short) > SkOpts_skx.o > 00000000 W skvx::Vec<16, int>::VecStorage(int) > 00000000 W skvx::Vec<16, int>::VecStorage(int) > 00000000 W skvx::Vec<2, int>::VecStorage(int) > 00000000 W skvx::Vec<2, int>::VecStorage(int) > 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) > 00000000 W skvx::Vec<4, int>::VecStorage(int) > 00000000 W skvx::Vec<4, int>::VecStorage(int) > 00000000 W skvx::Vec<8, int>::VecStorage(int) > 00000000 W skvx::Vec<8, int>::VecStorage(int) > > But why would upstreams binary work, while ours crashes? Shouldn't that be a > general problem, then? It's a problem that's somewhat specific to LTO as with LTO the linker is involved before these symbols are removed as unneeded and it gets the chance to pick up the "wrong" one as prevailing. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1212548] New: Firefox 114.0.2 released (new version)
by bugzilla_noreply＠suse.com 20 Jun '23

20 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1212548 Bug ID: 1212548 Summary: Firefox 114.0.2 released (new version) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All URL: https://www.mozilla.org/en-US/firefox/114.0.2/releasen otes/ OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: jayjayjazz(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: Community User Blocker: --- Firefox Version 114.0.2, first offered to Release channel users on June 20, 2023. Fixed - Several crash fixes [1] - Web Extensions: Fixes for 114 regressions in our Native Messaging support [2] Remark: Please do not forget the additional package repository [3]. [1] https://bugzilla.mozilla.org/buglist.cgi?bug_id=1828073,1837408,1833793 [2] https://bugzilla.mozilla.org/buglist.cgi?bug_id=1837830,1835790 [3] https://en.opensuse.org/Additional_package_repositories#Mozilla -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1212101] Firefox 114.0 and 114.0.1 immediately crashes at startup.
by bugzilla_noreply＠suse.com 20 Jun '23

20 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1212101 https://bugzilla.suse.com/show_bug.cgi?id=1212101#c73 --- Comment #73 from Martin Sirringhaus <martin.sirringhaus(a)suse.com> --- Ok, using `gcc-nm -C {} | grep VecStorage` I get two hits: SkOpts_hsw.o 00000000 W skvx::Vec<16, float>::VecStorage(float) 00000000 W skvx::Vec<16, float>::VecStorage(float) 00000000 W skvx::Vec<16, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<16, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<16, unsigned short>::VecStorage(unsigned short) 00000000 W skvx::Vec<16, unsigned short>::VecStorage(unsigned short) 00000000 W skvx::Vec<2, float>::VecStorage(float) 00000000 W skvx::Vec<2, float>::VecStorage(float) 00000000 W skvx::Vec<2, unsigned char>::VecStorage(unsigned char) 00000000 W skvx::Vec<2, unsigned char>::VecStorage(unsigned char) 00000000 W skvx::Vec<2, int>::VecStorage(int) 00000000 W skvx::Vec<2, int>::VecStorage(int) 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<2, unsigned long>::VecStorage(unsigned long) 00000000 W skvx::Vec<2, unsigned long>::VecStorage(unsigned long) 00000000 W skvx::Vec<2, unsigned short>::VecStorage(unsigned short) 00000000 W skvx::Vec<2, unsigned short>::VecStorage(unsigned short) 00000000 W skvx::Vec<32, int>::VecStorage(int) 00000000 W skvx::Vec<32, int>::VecStorage(int) 00000000 W skvx::Vec<4, float>::VecStorage(float) 00000000 W skvx::Vec<4, float>::VecStorage(float) 00000000 W skvx::Vec<4, unsigned char>::VecStorage(unsigned char) 00000000 W skvx::Vec<4, unsigned char>::VecStorage(unsigned char) 00000000 W skvx::Vec<4, int>::VecStorage(int) 00000000 W skvx::Vec<4, int>::VecStorage(int) 00000000 W skvx::Vec<4, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<4, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<4, unsigned long>::VecStorage(unsigned long) 00000000 W skvx::Vec<4, unsigned long>::VecStorage(unsigned long) 00000000 W skvx::Vec<4, unsigned short>::VecStorage(unsigned short) 00000000 W skvx::Vec<4, unsigned short>::VecStorage(unsigned short) 00000000 W skvx::Vec<8, unsigned char>::VecStorage(unsigned char) 00000000 W skvx::Vec<8, unsigned char>::VecStorage(unsigned char) 00000000 W skvx::Vec<8, int>::VecStorage(int) 00000000 W skvx::Vec<8, int>::VecStorage(int) 00000000 W skvx::Vec<8, unsigned short>::VecStorage(unsigned short) 00000000 W skvx::Vec<8, unsigned short>::VecStorage(unsigned short) SkOpts_skx.o 00000000 W skvx::Vec<16, int>::VecStorage(int) 00000000 W skvx::Vec<16, int>::VecStorage(int) 00000000 W skvx::Vec<2, int>::VecStorage(int) 00000000 W skvx::Vec<2, int>::VecStorage(int) 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<2, unsigned int>::VecStorage(unsigned int) 00000000 W skvx::Vec<4, int>::VecStorage(int) 00000000 W skvx::Vec<4, int>::VecStorage(int) 00000000 W skvx::Vec<8, int>::VecStorage(int) 00000000 W skvx::Vec<8, int>::VecStorage(int) But why would upstreams binary work, while ours crashes? Shouldn't that be a general problem, then? -- You are receiving this mail because: You are the assignee for the bug.

1 0