https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: www-client/seamonkey-2.53.9.1 fails to compile. Discovered on: amd64 (internal ref: tinderbox) NOTE: If you think this is a GCC-11 related issue, please block bug 732706.
Created attachment 751726 [details] build.log.xz build log and emerge --info (compressed because it exceeds attachment limit, use 'xzless' to read it)
Not sure if the attached build log shows exactly that error but no current seamonkey release can be built against >=dev-lang/rust-1.56.0. I have a patchset for seamonkey-2.53.10 ready that fixes compilation with rust-1.56 but the 2.53.10 release also requires sqlite-3.36.0 (bug #808258) which still hasn't made it into portage yet.
*** Bug 827885 has been marked as a duplicate of this bug. ***
seamonkey-2.53.10 is available from poly-c overlay and can be compiled with >=rust-1.56
(In reply to Lars Wendler (Polynomial-C) from comment #4) > seamonkey-2.53.10 is available from poly-c overlay and can be compiled with > >=rust-1.56 How is that in any way useful for our users?
*** Bug 828138 has been marked as a duplicate of this bug. ***
(In reply to David Seifert from comment #5) > (In reply to Lars Wendler (Polynomial-C) from comment #4) > > seamonkey-2.53.10 is available from poly-c overlay and can be compiled with > > >=rust-1.56 > > How is that in any way useful for our users? Helps for me, until it will show up in portage officially. Thanks Poly-C!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=29353ae55f5aa9408748be2278c41b880b96d124 commit 29353ae55f5aa9408748be2278c41b880b96d124 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-12 23:02:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-12 23:02:44 +0000 www-client/seamonkey: add upper bound on Rust Especially important given otherwise Harfbuzz subslot rebuilds can't be completed. Bug: https://bugs.gentoo.org/824066 Signed-off-by: Sam James <sam@gentoo.org> www-client/seamonkey/seamonkey-2.53.8.1.ebuild | 2 +- www-client/seamonkey/seamonkey-2.53.9.1.ebuild | 2 +- www-client/seamonkey/seamonkey-2.53.9.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
(In reply to Lars Wendler (Polynomial-C) from comment #2) > Not sure if the attached build log shows exactly that error but no current > seamonkey release can be built against >=dev-lang/rust-1.56.0. I have a > patchset for seamonkey-2.53.10 ready that fixes compilation with rust-1.56 > but the 2.53.10 release also requires sqlite-3.36.0 (bug #808258) which > still hasn't made it into portage yet. Now in tree.
ci has reproduced this issue with version 2.53.9.1-r1 - Updating summary.
sqlite bump happened, can the patchset be added now? this bug blocks old rust cleanup.
(In reply to Lars Wendler (Polynomial-C) from comment #4) > seamonkey-2.53.10 is available from poly-c overlay and can be compiled with > >=rust-1.56 Your overlay ebuild works for me, thanks a lot!
another friendly ping. as I understand a version that supports newer rust exists in overlay? why not copy it to ::gentoo?
Will probably drop seamonkey to m-n in few weeks if no one from the team has interest to maintain it.
dropping to m-n does not let us cleanup old rust. this smells like hardmask mask and security last-rites. I see a recent overlay update https://github.com/gentoo-mirror/poly-c/commit/cb7fa89d7418664c7f81373613a39b64d8fe848b overlay is rsync, but at least mirror allows seeing history. seeing overlay-specific ecclass removed makes me hope it's going to be copied into ::gentoo soon. otherwise it has to go. there has been plenty of time to sort this bug out. I hope delay has nothing to do with >=media-libs/libpng-1.6.31:0=[apng] dep though.
(In reply to Georgy Yakovlev from comment #15) > dropping to m-n does not let us cleanup old rust. > > this smells like hardmask mask and security last-rites. > You're right. I have an impression that this package would have takers, but we can use last-riting as a callout too.
it now blocks CVE-2022-21658 too
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e3b84dd5e01c54a20d60954fc29ccff9abe0871 commit 2e3b84dd5e01c54a20d60954fc29ccff9abe0871 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2022-01-22 01:21:48 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2022-01-22 01:22:32 +0000 profiles: mask vulnerable rust versions (and seamonkey) Bug: https://bugs.gentoo.org/831638 Bug: https://bugs.gentoo.org/821157 Bug: https://bugs.gentoo.org/824066 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> profiles/package.mask | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Very happy to merge a PR from someone happy to look after this. I've talked through someone who was interested a few days ago on IRC but not heard anything since. Really don't have more time to do it myself sadly. Would like to see it remain in tree but need a volunteer (a user! No need to be a developer, just willing to learn) to help.
(In reply to Lars Wendler (Polynomial-C) from comment #2) > Not sure if the attached build log shows exactly that error but no current > seamonkey release can be built against >=dev-lang/rust-1.56.0. I have a > patchset for seamonkey-2.53.10 ready that fixes compilation with rust-1.56 > but the 2.53.10 release also requires sqlite-3.36.0 (bug #808258) which > still hasn't made it into portage yet. USE=-system-sqlite is not solution for portage?
(In reply to Denis Kaganovich from comment #20) > (In reply to Lars Wendler (Polynomial-C) from comment #2) > > Not sure if the attached build log shows exactly that error but no current > > seamonkey release can be built against >=dev-lang/rust-1.56.0. I have a > > patchset for seamonkey-2.53.10 ready that fixes compilation with rust-1.56 > > but the 2.53.10 release also requires sqlite-3.36.0 (bug #808258) which > > still hasn't made it into portage yet. > > USE=-system-sqlite is not solution for portage? There's slready a newer SQLite in Gentoo anyway, so that's not a blocker anymore (see https://bugs.gentoo.org/824066#c9 and https://bugs.gentoo.org/824066#c11). I don't know why the old maintainer has stopped replying to this bug or updating it.
(In reply to Sam James from comment #21) > (In reply to Denis Kaganovich from comment #20) > > (In reply to Lars Wendler (Polynomial-C) from comment #2) > > > Not sure if the attached build log shows exactly that error but no current > > > seamonkey release can be built against >=dev-lang/rust-1.56.0. I have a > > > patchset for seamonkey-2.53.10 ready that fixes compilation with rust-1.56 > > > but the 2.53.10 release also requires sqlite-3.36.0 (bug #808258) which > > > still hasn't made it into portage yet. > > > > USE=-system-sqlite is not solution for portage? > > There's slready a newer SQLite in Gentoo anyway, so that's not a blocker > anymore (see https://bugs.gentoo.org/824066#c9 and > https://bugs.gentoo.org/824066#c11). > > I don't know why the old maintainer has stopped replying to this bug or > updating it. Just side-stepping a bit. The whole "-system-*" USE flags are a bit bogus apparently, unclear at best: # ldd /usr/bin/seamonkey linux-vdso.so.1 (0x00007fffda394000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8636ea6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8636ea0000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 (0x00007f8636c8b000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 (0x00007f8636c71000) libc.so.6 => /lib64/libc.so.6 (0x00007f8636ab8000) /lib64/ld-linux-x86-64.so.2 (0x00007f8636f29000) libm.so.6 => /lib64/libm.so.6 (0x00007f863697f000) There is no dynamic linking on any of these "system" libs (which I assumed with those USE flags). This also shows why Seamonkey needs a minimal system-library version, because it is checked against headers with the upstream in-tree version. IMHO this renders the whole argument of using system libraries invalid. It could be that the system version of these libraries are packed into the seamonkey binary (haven't checked that), but that also defeats the purpose of using system libraries. When this package gets out of the mud (Lars steps back in or someone else) I think it would be good to have a closer look at how functional all these patches are and maybe look at how the firefox ebuild does this (does it?). The whole -system-sqlite removal came from the Firefox devs, the Seamonkey devs seem to have just copied it over.
(In reply to Myckel Habets from comment #22) > (In reply to Sam James from comment #21) > > (In reply to Denis Kaganovich from comment #20) > > > (In reply to Lars Wendler (Polynomial-C) from comment #2) > > > > Not sure if the attached build log shows exactly that error but no current > > > > seamonkey release can be built against >=dev-lang/rust-1.56.0. I have a > > > > patchset for seamonkey-2.53.10 ready that fixes compilation with rust-1.56 > > > > but the 2.53.10 release also requires sqlite-3.36.0 (bug #808258) which > > > > still hasn't made it into portage yet. > > > > > > USE=-system-sqlite is not solution for portage? > > > > There's slready a newer SQLite in Gentoo anyway, so that's not a blocker > > anymore (see https://bugs.gentoo.org/824066#c9 and > > https://bugs.gentoo.org/824066#c11). > > > > I don't know why the old maintainer has stopped replying to this bug or > > updating it. > > Just side-stepping a bit. > > The whole "-system-*" USE flags are a bit bogus apparently, unclear at best: > > # ldd /usr/bin/seamonkey > linux-vdso.so.1 (0x00007fffda394000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8636ea6000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f8636ea0000) > libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 > (0x00007f8636c8b000) > libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 > (0x00007f8636c71000) > libc.so.6 => /lib64/libc.so.6 (0x00007f8636ab8000) > /lib64/ld-linux-x86-64.so.2 (0x00007f8636f29000) > libm.so.6 => /lib64/libm.so.6 (0x00007f863697f000) > > There is no dynamic linking on any of these "system" libs (which I assumed > with those USE flags). This also shows why Seamonkey needs a minimal > system-library version, because it is checked against headers with the > upstream in-tree version. IMHO this renders the whole argument of using > system libraries invalid. You're looking at the wrong file. Check the .so files in /usr/lib*/seamonkey as well. All the system-* USE flags are functional and have their right to exist. > It could be that the system version of these libraries are packed into the > seamonkey binary (haven't checked that), but that also defeats the purpose > of using system libraries. No, it's just not the seamonkey binary itself that links to those system-libs.
(In reply to Lars Wendler (Polynomial-C) from comment #23) (cut) > > > You're looking at the wrong file. Check the .so files in /usr/lib*/seamonkey > as well. All the system-* USE flags are functional and have their right to > exist. > > > > It could be that the system version of these libraries are packed into the > > seamonkey binary (haven't checked that), but that also defeats the purpose > > of using system libraries. > > No, it's just not the seamonkey binary itself that links to those > system-libs. Yes, I see now, it seems it's packed into libxul.so. Still, with a system-library update one would have to rebuild seamonkey as well, right? I guess else you keep using the old version, or am I missing something?
(In reply to Myckel Habets from comment #24) > (In reply to Lars Wendler (Polynomial-C) from comment #23) > > (cut) > > > > > > You're looking at the wrong file. Check the .so files in /usr/lib*/seamonkey > > as well. All the system-* USE flags are functional and have their right to > > exist. > > > > > > > It could be that the system version of these libraries are packed into the > > > seamonkey binary (haven't checked that), but that also defeats the purpose > > > of using system libraries. > > > > No, it's just not the seamonkey binary itself that links to those > > system-libs. > > > Yes, I see now, it seems it's packed into libxul.so. Still, with a > system-library update one would have to rebuild seamonkey as well, right? I > guess else you keep using the old version, or am I missing something? Usually you only need to rebuild seamonkey if the .so version of a system-lib changes.
@Polynomial-C, any chance of getting the latest ebuild and files from your repo into the main tree any time soon?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee81f36292d2116e67467a336df2bf706fe2b716 commit ee81f36292d2116e67467a336df2bf706fe2b716 Author: Myckel Habets <myckel@sdf.org> AuthorDate: 2022-01-27 15:50:45 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-29 05:49:00 +0000 www-client/seamonkey: add 2.53.10.2 Bug: https://bugs.gentoo.org/828479 Closes: https://bugs.gentoo.org/824066 Closes: https://bugs.gentoo.org/831977 Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Signed-off-by: Sam James <sam@gentoo.org> www-client/seamonkey/Manifest | 4 + .../files/seamonkey-2.53.10.2-ownertab.patch | 249 +++++++++ www-client/seamonkey/seamonkey-2.53.10.2.ebuild | 557 +++++++++++++++++++++ 3 files changed, 810 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7c373dd540306f0f2e4846f204bcd1a9a58b2d78 commit 7c373dd540306f0f2e4846f204bcd1a9a58b2d78 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-29 05:51:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-29 05:53:08 +0000 profiles: drop seamonkey mask now it's been bumped Bug: https://bugs.gentoo.org/831638 Bug: https://bugs.gentoo.org/821157 Bug: https://bugs.gentoo.org/824066 Bug: https://bugs.gentoo.org/831977 Bug: https://bugs.gentoo.org/828479 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef741792c06ad55d37e1477ad74f3d8fc3fcd64f commit ef741792c06ad55d37e1477ad74f3d8fc3fcd64f Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2022-02-19 13:40:28 +0000 Commit: Jakov Smolić <jsmolic@gentoo.org> CommitDate: 2022-02-19 13:44:49 +0000 www-client/seamonkey: drop 2.53.9.1-r1 Bug: https://bugs.gentoo.org/831638 Bug: https://bugs.gentoo.org/821157 Bug: https://bugs.gentoo.org/824066 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> profiles/package.mask | 12 - www-client/seamonkey/Manifest | 4 - www-client/seamonkey/seamonkey-2.53.9.1-r1.ebuild | 557 ---------------------- 3 files changed, 573 deletions(-)
