Re: Chromium security bugs remain unfixed for > 1 month
Demi Marie Obenour wrote: > On 3/2/22 10:09, Tom Callaway wrote: >> Additionally, Fedora uses GCC (intentionally) which requires patch work >> for each release, but improves the quality of the resulting package. > > Would it be possible to make a one-off exception for Chromium? There is actually already a blanket allowance (it is not even an exception anymore) for packages to use Clang where upstream prefers it. The decision is ultimately up to the maintainer. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
Demi Marie Obenour wrote: > Arch uses the upstream *source* code, but not the binaries, if I > understand correctly. They just don’t have anywhere near as many > patches as Fedora does. I suspect this is a combination of factors. > First, Arch builds use clang and more bundled libraries, so they are > more similar to what Google itself uses and break less often. Second, > Arch has zero problems with shipping patent-encumbered media codecs, as > (if I recall correctly) Arch is based in a nation where such patents > simply are not enforceable. So they can just use the codecs that > Chromium comes with already. Arch also has the AUR where there are plenty of "packages" that just repackage somebody else's binaries. They are a lot less strict about packaging only verifiably Free Software. But building from source is the only way to ensure that the binaries are actually compiled from that exact source code. (Then of course you also have to trust the compiler, but that is another story.) As for the issue of Chromium patches, well, they are all there for a reason: some due to legal requirements, some because Fedora (especially Rawhide) tends to ship a newer glibc than what upstream Google tested with, which tends to break their seccomp sandbox every so often, etc. (Note that QtWebEngine tends to have fewer patches than Chromium, also because Qt applies some of those patches in their bundled Chromium.) > Electron is going to be a nightmare for all sorts of other reasons, > starting with the need to rebuild all of the minified JavaScript, > CSS, and HTML from unminified source code. Electron is a pain in the neck and I do not want to spend my time packaging it, but it looks like we have a volunteer attempting it now. > Can Fedora just reuse the upstream QtWebEngine build scripts? What build scripts do you want to reuse? Of course we use the qmake (in Qt 5, CMake in Qt 6, but we do not have QtWebEngine 6 packaged yet) build system that they wrote. There are not really any upstream build scripts we can use beyond that. > What would it take to get tall of the users of QtWebEngine onto 6.2? I > don’t think Fedora should ship any version of QtWebEngine except the > latest, since only the latest version appears to get regular patches. Well, even 6.2 does not get patches as regularly as you expect. As I said, the CVEs you listed will be fixed in Qt 6.2.4, which is still not released yet. QtWebEngine 5.15 does also still get LTS releases with security fixes (and the LTS branches of QtWebEngine and its qtwebengine-chromium submodule are public and LGPL-licensed). Just not as frequently. Only when they release a Qt 5.15.x commercial LTS. And moving all the users to QtWebEngine 6 is not going to happen overnight, because it means moving them completely to Qt 6. In particular, if they use KF5 libraries, they will also need to move to the KF6 equivalents, and there is no KF6 release yet at all that they could move to. > Yeah, but for QtWebEngine I imagine much of the work is handled by The > Qt Company and Fedora can just reuse their build scripts. If you think a turnaround time of > 1 month for security fixes is too long, then we would have to do our own backports though, because 1+ month(s) is quite normal for the latest Qt branch, LTS branches are even slower. And rebasing QtWebEngine to a newer Chromium is even harder than backporting security fixes to the existing branch. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On Wed, Mar 02, 2022 at 04:07:43PM -, Leigh Scott wrote: > > Fedora cannot use the default tarball due to legal restrictions. > > Additionally, Fedora uses > > GCC (intentionally) which requires patch work for each release, but > > improves the quality > > of the resulting package. > > So GCC needs 125Gb of Ram to build chromium? > https://koji.fedoraproject.org/koji/taskinfo?taskID=83529675 > > What makes the GCC build better than clang build? GCC was "the" Fedora compiler that everyone had to use, but in Fedora 35 the policy changed: https://fedoraproject.org/wiki/Changes/CompilerPolicy However Tom may have his own reasons to use GCC, he's the packager so it's up to him. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On Wed, Mar 2, 2022 at 5:06 AM Demi Marie Obenour wrote: > What would it take to get tall of the users of QtWebEngine onto 6.2? I > don’t think Fedora should ship any version of QtWebEngine except the > latest, since only the latest version appears to get regular patches. Well, it is slightly more complicated, as there is a process to get patches backported (for all of the Qt 5 modules), and it does happen, but that process can be somewhat convoluted due to "reasons". As I recall (and I could easily be wrong about the current status), qt6-qtwebengine has not yet been packaged/built for Fedora, which I suspect is at least partially due to the same reasons that it can be hard to package chromium (stripping, debundling, etc.), and AFAIK no project yet requires it (and as it requires resources to maintain once made available, I suspect there is negative motivation to make it available until it is actually needed). Even when qt6-qtwebeingine is packaged, moving to Qt 6.x from Qt 5.y for a project can be easy or hard, depending on what the project is doing, but that is a question for those upstream projects that are using Qt. I would suggest you directly ask those projects what their intentions and schedules are. I suspect most have a plan for moving forward to Qt 6,x, but it may not be sufficiently resourced to happen in the near term. Perhaps the largest project (that I am aware of) would be KDE, and they have a plan, and are working on it, but AFAIK have no specific targets for completion (and for that project, there is a lot of work to accomplish). Realistically, all of qt5 (including the webengine) is likely to be part of Fedora for quite some time, just as qt4 libraries are still available, as some package still uses them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 3/2/22 10:09, Tom Callaway wrote: > Apologies for the delays. My wife has been rather ill for a while, so my open > source time has been greatly minimized lately. I am so sorry. > Fedora cannot use the default tarball due to legal restrictions. Unfortunate but understandable. How much recurring work is this? > Additionally, Fedora uses GCC (intentionally) which requires patch work for > each release, but improves the quality of the resulting package. Would it be possible to make a one-off exception for Chromium? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
Thanks, and thank you for maintaining chromium-freeworld in rpmfusion. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
> Fedora cannot use the default tarball due to legal restrictions. > Additionally, Fedora uses > GCC (intentionally) which requires patch work for each release, but improves > the quality > of the resulting package. So GCC needs 125Gb of Ram to build chromium? https://koji.fedoraproject.org/koji/taskinfo?taskID=83529675 What makes the GCC build better than clang build? > > Chromium was also breaking koji due to the large amount of memory it needs to > build > exceeding the available memory in VMs. The helpful Fedora Infra team has > created a > baremetal group for Chromium to work around this. If the rpmfusion builder VM requirement increases (currently 16Gb) it's likely to be orphaned unless someone donates more RAM for my builder. > > ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
> VAAPI hasn't worked for a long time on chromium. In "chrome://gpu" it shows > "Video Decode: Software only. Hardware acceleration disabled" and it cannot be > changed in "chrome://flags" either. This is the case for Fedora's packaged > chromium and rpmfusion's chromium-freeworld. I encourage you to verify this > yourself > using intel or amd graphics. > vaapi is disabled by google as default since chrome 93/94, you need to enable it with --enable-features=VaapiVideoDecoder https://wiki.archlinux.org/title/chromium#Hardware_video_acceleration ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
> We ship VA-API integration, which Google doesn't offer. VAAPI hasn't worked for a long time on chromium. In "chrome://gpu" it shows "Video Decode: Software only. Hardware acceleration disabled" and it cannot be changed in "chrome://flags" either. This is the case for Fedora's packaged chromium and rpmfusion's chromium-freeworld. I encourage you to verify this yourself using intel or amd graphics. > Those features provide tangible benefits to the community at large > that we would lose by "sloppy packaging" An outdated browser that has many known vulnerabilities is a huge security problem and provides tangible drawbacks. If it's too much work to keep current then it should be removed from the repository. We do not want users to be under the illusion that the provided package is secure and maintained when it's not. > The same goes for everyone else on this thread so far. I'm > disappointed by the OP and everyone else in this thread who thinks > it's okay to do less than a good job on shipping software. I would argue that providing secure packages takes priority over most other packaging issues. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On Wed, Mar 2, 2022 at 9:19 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Mar 02, 2022 at 07:08:07AM -0500, Neal Gompa wrote: > > Those features provide tangible benefits to the community at large > > that we would lose by "sloppy packaging". Instead of kvetching, why > > not try helping? Maybe *ask* Tom what you could do to help him ship > > newer versions? > > Neal, > > please reign in your rhetoric a bit. This is a discussion about > packaging, not the people involved. > My apologies, this thread was combined with some off-list conversations that were considerably less charitable around this topic, which led to a more drastic response than I would have normally given. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
Apologies for the delays. My wife has been rather ill for a while, so my open source time has been greatly minimized lately. Fedora cannot use the default tarball due to legal restrictions. Additionally, Fedora uses GCC (intentionally) which requires patch work for each release, but improves the quality of the resulting package. Chromium was also breaking koji due to the large amount of memory it needs to build exceeding the available memory in VMs. The helpful Fedora Infra team has created a baremetal group for Chromium to work around this. Finally, I had been working on trying to resolve the build failures with Fedora 36, but they should now be fixed (as of last night). Of course, Google released a new major version this morning, so the terrifying carousel spins anew. Your patience is appreciated. ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On Wed, Mar 02, 2022 at 07:08:07AM -0500, Neal Gompa wrote: > Those features provide tangible benefits to the community at large > that we would lose by "sloppy packaging". Instead of kvetching, why > not try helping? Maybe *ask* Tom what you could do to help him ship > newer versions? Neal, please reign in your rhetoric a bit. This is a discussion about packaging, not the people involved. BTW, the first email asked: > Tom Callaway, what is the hardest part for you? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 02/03/2022 12:44, Demi Marie Obenour wrote: That doesn’t explain why RPM Fusion gets updates so much more quickly. RPM Fusion don't need to manually strip ffmpeg, apply some specific patches, etc. In the case of something like Chromium, a sloppy package that gets timely updates is better than a fully conforming package that does not. It depends. As for me, I prefer a well-packaged Fedora package than using a proprietary build. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On Wed, Mar 2, 2022 at 6:44 AM Demi Marie Obenour wrote: > > On 3/2/22 04:05, Vitaly Zaitsev via devel wrote: > > On 02/03/2022 01:21, Demi Marie Obenour wrote: > >> What are the differences between the RPMFusion SRPM and the > >> Fedora SRPM? > > > > RPM Fusion version includes all available multimedia codecs. > > That doesn’t explain why RPM Fusion gets updates so much more > quickly. > > >> Tom Callaway, what is the hardest part for you? > > > > Packaging of Google's software is a nightmare. They do their best to > > make packaging as difficult as possible by using dozens of bundled > > libraries, their own build system, etc. > > In the case of something like Chromium, a sloppy package that gets > timely updates is better than a fully conforming package that does not. You do not know what you're asking for. You're asking for packaging where we may wind up having things of questionable legality, questionable licensing, and questionable integration that can cause serious issues for Fedora users and downstreams. As a security person, you should be ashamed that you thought this was a good idea. Maximizing reuse across the Fedora ecosystem provides significant benefits because we are able to leverage our quality components, our hardening capabilities, and provide additional capabilities to benefit consumption within the Fedora ecosystem. For example, Fedora's Chromium will attempt to use Wayland by default on a Wayland desktop. Upstream Chrom(e|ium) is not ready for that yet. We ship VA-API integration, which Google doesn't offer. We have working screencasting on Wayland, which upstream doesn't have right now by default. We can enable security features that upstream refuses to (CaBLE, for example). And so on. Those features provide tangible benefits to the community at large that we would lose by "sloppy packaging". Instead of kvetching, why not try helping? Maybe *ask* Tom what you could do to help him ship newer versions? The same goes for everyone else on this thread so far. I'm disappointed by the OP and everyone else in this thread who thinks it's okay to do less than a good job on shipping software. The only complaint I could probably see is that the patches he's got haven't been submitted upstream, but submitting to Chromium upstream is *hard* (I've made contributions to Chromium and it's really not easy to do) and I assume he's working on it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 3/2/22 04:05, Vitaly Zaitsev via devel wrote: > On 02/03/2022 01:21, Demi Marie Obenour wrote: >> What are the differences between the RPMFusion SRPM and the >> Fedora SRPM? > > RPM Fusion version includes all available multimedia codecs. That doesn’t explain why RPM Fusion gets updates so much more quickly. >> Tom Callaway, what is the hardest part for you? > > Packaging of Google's software is a nightmare. They do their best to > make packaging as difficult as possible by using dozens of bundled > libraries, their own build system, etc. In the case of something like Chromium, a sloppy package that gets timely updates is better than a fully conforming package that does not. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 02/03/2022 02:45, Demi Marie Obenour wrote: I am surprised that the answer is not to automatically download and install Canonical’s Snap package Absolutely no way. Everything must be built from sources on trusted infra. No exceptions. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 02/03/2022 01:21, Demi Marie Obenour wrote: What are the differences between the RPMFusion SRPM and the Fedora SRPM? RPM Fusion version includes all available multimedia codecs. Tom Callaway, what is the hardest part for you? Packaging of Google's software is a nightmare. They do their best to make packaging as difficult as possible by using dozens of bundled libraries, their own build system, etc. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 3/1/22 22:44, Kevin Kofler via devel wrote: > Demi Marie Obenour wrote: >> Me too. I am surprised that the answer is not to automatically >> download and install Canonical’s Snap package; they seem to have >> figured out everything already. Arch manages to do it by having very >> few patches and using the upstream source tarball. > > If you think that just using the binary blobs provided by upstream or some > third party (e.g., Canonical) is a solution for anything, you clearly have > not understood how distribution packaging works. Arch uses the upstream *source* code, but not the binaries, if I understand correctly. They just don’t have anywhere near as many patches as Fedora does. I suspect this is a combination of factors. First, Arch builds use clang and more bundled libraries, so they are more similar to what Google itself uses and break less often. Second, Arch has zero problems with shipping patent-encumbered media codecs, as (if I recall correctly) Arch is based in a nation where such patents simply are not enforceable. So they can just use the codecs that Chromium comes with already. > At most, that approach can work for leaf applications such as the Chromium > browser, but the Chromium code is also used in QtWebEngine and in Electron, > both of which are used to build many desktop applications. QtWebEngine is > used in browsers (Falkon, Angelfish), mail clients (KMail, Kontact), etc. Electron is going to be a nightmare for all sorts of other reasons, starting with the need to rebuild all of the minified JavaScript, CSS, and HTML from unminified source code. Can Fedora just reuse the upstream QtWebEngine build scripts? > As far as qt5-qtwebengine is concerned, there is no way I can issue a > security update at this time because the security fixes have not been > backported by Qt upstream yet: > https://code.qt.io/cgit/qt/qtwebengine-chromium.git/log/?h=87-based > The fixes up to CVE-2021-4102 are included in the 5.15.8 security update > that I pushed, CVE-2022-* are not backported upstream yet. > > (Well, technically, I suppose I could attempt to backport them from 90- > based, i.e., from QtWebengine 6.2: > https://code.qt.io/cgit/qt/qtwebengine-chromium.git/log/?h=90-based > or even directly from Chromium upstream, but that is extremely time- > consuming and not something I can do on a regular basis.) What would it take to get tall of the users of QtWebEngine onto 6.2? I don’t think Fedora should ship any version of QtWebEngine except the latest, since only the latest version appears to get regular patches. > And for a library such as QtWebEngine, Snap or Flatpak do not work at all. Yeah, but for QtWebEngine I imagine much of the work is handled by The Qt Company and Fedora can just reuse their build scripts. > Even if you only care about the standalone Chromium, using a third-party > blob will lose you the benefits of distribution packaging. For standalone Chromium, a blob that gets regular security updates is better than a proper package that does not. The first is at least safe to use, the second isn’t. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 3/1/22 23:14, Adam Williamson wrote: > On Tue, 2022-03-01 at 19:21 -0500, Demi Marie Obenour wrote: >> On 3/1/22 16:02, Jonathan Schleifer wrote: >>> Hi! >>> >>> It looks like Chromium on Fedora is not receiving timely updates. It >>> hasn't been updated in over a month and there were many bugs fixed >>> upstream. At the very least, Chromium on Fedora is vulnerable to the >>> following: >>> >>> CVE-2022-0452: Use after free in Safe Browsing. >>> CVE-2022-0453: Use after free in Reader Mode. >>> CVE-2022-0454: Heap buffer overflow in ANGLE. >>> CVE-2022-0455: Inappropriate implementation in Full Screen Mode. >>> CVE-2022-0456: Use after free in Web Search. >>> CVE-2022-0457: Type Confusion in V8. >>> CVE-2022-0458: Use after free in Thumbnail Tab Strip. >>> CVE-2022-0459 Use after free in Screen Capture. >>> CVE-2022-0603: Use after free in File Manager. >>> CVE-2022-0604: Heap buffer overflow in Tab Groups. >>> CVE-2022-0605: Use after free in Webstore API. >>> CVE-2022-0606: Use after free in ANGLE. >>> CVE-2022-0607: Use after free in GPU. >>> CVE-2022-0608: Integer overflow in Mojo. >>> CVE-2022-0609: Use after free in Animation. >>> >>> Google reports these as being actively exploited in the wild, which means: >>> >>> ** If you use Chromium on Fedora, stop using it NOW ** >>> >>> Can we fix this situation somehow? Browsers are the most critical thing >>> to get security updates as fast as possible. Having bugs unfixed for a >>> month that are exploited in the wild is *bad* and puts our users at >>> serious risk. >>> >>> RPMFusion seems to push timely updates - can we reuse that? Should users >>> be pointed towards RPMFusion instead in the meantime? >> >> What are the differences between the RPMFusion SRPM and the >> Fedora SRPM? > > There is no need to guess about this. You can read both spec files. > These are open projects. The Fedora spec is heavily commented, with > explanations of what all the patches etc. are for. > > Fedora spec: > https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium.spec > > RPMFusion spec: > https://github.com/rpmfusion/chromium-freeworld/blob/master/chromium-freeworld.spec > > As you can see, the Fedora spec is doing more work to fit in with the > letter and spirit of Fedora guidelines, especially around stopping > Chromium bundling and doing weird things to libraries. The RPMFusion > spec does some, but not as much. > > If Chromium didn't do so much messy stuff with libraries and > proprietary blobs that the package has to work around, I imagine > maintaining it would be much easier. I sure wouldn't want the job. Is trying to prevent Chromium from bundling libraries even worthwhile? I think the first priority should be to come up with a spec that (a) allows shipping new versions quickly and (b) doesn’t create any legal problems. The rest can come later. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On Tue, 2022-03-01 at 19:21 -0500, Demi Marie Obenour wrote: > On 3/1/22 16:02, Jonathan Schleifer wrote: > > Hi! > > > > It looks like Chromium on Fedora is not receiving timely updates. It > > hasn't been updated in over a month and there were many bugs fixed > > upstream. At the very least, Chromium on Fedora is vulnerable to the > > following: > > > > CVE-2022-0452: Use after free in Safe Browsing. > > CVE-2022-0453: Use after free in Reader Mode. > > CVE-2022-0454: Heap buffer overflow in ANGLE. > > CVE-2022-0455: Inappropriate implementation in Full Screen Mode. > > CVE-2022-0456: Use after free in Web Search. > > CVE-2022-0457: Type Confusion in V8. > > CVE-2022-0458: Use after free in Thumbnail Tab Strip. > > CVE-2022-0459 Use after free in Screen Capture. > > CVE-2022-0603: Use after free in File Manager. > > CVE-2022-0604: Heap buffer overflow in Tab Groups. > > CVE-2022-0605: Use after free in Webstore API. > > CVE-2022-0606: Use after free in ANGLE. > > CVE-2022-0607: Use after free in GPU. > > CVE-2022-0608: Integer overflow in Mojo. > > CVE-2022-0609: Use after free in Animation. > > > > Google reports these as being actively exploited in the wild, which means: > > > > ** If you use Chromium on Fedora, stop using it NOW ** > > > > Can we fix this situation somehow? Browsers are the most critical thing > > to get security updates as fast as possible. Having bugs unfixed for a > > month that are exploited in the wild is *bad* and puts our users at > > serious risk. > > > > RPMFusion seems to push timely updates - can we reuse that? Should users > > be pointed towards RPMFusion instead in the meantime? > > What are the differences between the RPMFusion SRPM and the > Fedora SRPM? There is no need to guess about this. You can read both spec files. These are open projects. The Fedora spec is heavily commented, with explanations of what all the patches etc. are for. Fedora spec: https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium.spec RPMFusion spec: https://github.com/rpmfusion/chromium-freeworld/blob/master/chromium-freeworld.spec As you can see, the Fedora spec is doing more work to fit in with the letter and spirit of Fedora guidelines, especially around stopping Chromium bundling and doing weird things to libraries. The RPMFusion spec does some, but not as much. If Chromium didn't do so much messy stuff with libraries and proprietary blobs that the package has to work around, I imagine maintaining it would be much easier. I sure wouldn't want the job. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
Kevin Kofler via devel wrote: > (Well, technically, I suppose I could attempt to backport them from 90- > based, i.e., from QtWebengine 6.2: > https://code.qt.io/cgit/qt/qtwebengine-chromium.git/log/?h=90-based > or even directly from Chromium upstream, but that is extremely time- > consuming and not something I can do on a regular basis.) PS: Note that even for 6.2, the fixes were backported only between 12 and 2 days ago, and have not yet been released in a QtWebEngine release. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
Demi Marie Obenour wrote: > Me too. I am surprised that the answer is not to automatically > download and install Canonical’s Snap package; they seem to have > figured out everything already. Arch manages to do it by having very > few patches and using the upstream source tarball. If you think that just using the binary blobs provided by upstream or some third party (e.g., Canonical) is a solution for anything, you clearly have not understood how distribution packaging works. At most, that approach can work for leaf applications such as the Chromium browser, but the Chromium code is also used in QtWebEngine and in Electron, both of which are used to build many desktop applications. QtWebEngine is used in browsers (Falkon, Angelfish), mail clients (KMail, Kontact), etc. As far as qt5-qtwebengine is concerned, there is no way I can issue a security update at this time because the security fixes have not been backported by Qt upstream yet: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/log/?h=87-based The fixes up to CVE-2021-4102 are included in the 5.15.8 security update that I pushed, CVE-2022-* are not backported upstream yet. (Well, technically, I suppose I could attempt to backport them from 90- based, i.e., from QtWebengine 6.2: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/log/?h=90-based or even directly from Chromium upstream, but that is extremely time- consuming and not something I can do on a regular basis.) And for a library such as QtWebEngine, Snap or Flatpak do not work at all. Even if you only care about the standalone Chromium, using a third-party blob will lose you the benefits of distribution packaging. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 3/1/22 19:42, Michael Catanzaro wrote: > On Tue, Mar 1 2022 at 07:21:14 PM -0500, Demi Marie Obenour > wrote: >> Tom Callaway, what is the hardest part for you? > > Keep in mind Tom is a volunteer and Chromium packaging is not fun. I'm > impressed that anybody is willing to attempt it tbh. Me too. I am surprised that the answer is not to automatically download and install Canonical’s Snap package; they seem to have figured out everything already. Arch manages to do it by having very few patches and using the upstream source tarball. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On Tue, Mar 1 2022 at 07:21:14 PM -0500, Demi Marie Obenour wrote: Tom Callaway, what is the hardest part for you? Keep in mind Tom is a volunteer and Chromium packaging is not fun. I'm impressed that anybody is willing to attempt it tbh. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium security bugs remain unfixed for > 1 month
On 3/1/22 16:02, Jonathan Schleifer wrote: > Hi! > > It looks like Chromium on Fedora is not receiving timely updates. It > hasn't been updated in over a month and there were many bugs fixed > upstream. At the very least, Chromium on Fedora is vulnerable to the > following: > > CVE-2022-0452: Use after free in Safe Browsing. > CVE-2022-0453: Use after free in Reader Mode. > CVE-2022-0454: Heap buffer overflow in ANGLE. > CVE-2022-0455: Inappropriate implementation in Full Screen Mode. > CVE-2022-0456: Use after free in Web Search. > CVE-2022-0457: Type Confusion in V8. > CVE-2022-0458: Use after free in Thumbnail Tab Strip. > CVE-2022-0459 Use after free in Screen Capture. > CVE-2022-0603: Use after free in File Manager. > CVE-2022-0604: Heap buffer overflow in Tab Groups. > CVE-2022-0605: Use after free in Webstore API. > CVE-2022-0606: Use after free in ANGLE. > CVE-2022-0607: Use after free in GPU. > CVE-2022-0608: Integer overflow in Mojo. > CVE-2022-0609: Use after free in Animation. > > Google reports these as being actively exploited in the wild, which means: > > ** If you use Chromium on Fedora, stop using it NOW ** > > Can we fix this situation somehow? Browsers are the most critical thing > to get security updates as fast as possible. Having bugs unfixed for a > month that are exploited in the wild is *bad* and puts our users at > serious risk. > > RPMFusion seems to push timely updates - can we reuse that? Should users > be pointed towards RPMFusion instead in the meantime? What are the differences between the RPMFusion SRPM and the Fedora SRPM? > Thoughts? I wound up using proprietary Google Chrome on Debian for this reason. I use Qubes OS so using different OSs for different tasks is trivial. The only distribution I know of that seems to promptly ship updates to Chromium is Arch, which does not insist on only shipping free software. Could the difference be that Arch and RPMFusion can directly use the tarball provided by upstream, whereas Fedora and Debian cannot? Tom Callaway, what is the hardest part for you? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Chromium security bugs remain unfixed for > 1 month
Hi! It looks like Chromium on Fedora is not receiving timely updates. It hasn't been updated in over a month and there were many bugs fixed upstream. At the very least, Chromium on Fedora is vulnerable to the following: CVE-2022-0452: Use after free in Safe Browsing. CVE-2022-0453: Use after free in Reader Mode. CVE-2022-0454: Heap buffer overflow in ANGLE. CVE-2022-0455: Inappropriate implementation in Full Screen Mode. CVE-2022-0456: Use after free in Web Search. CVE-2022-0457: Type Confusion in V8. CVE-2022-0458: Use after free in Thumbnail Tab Strip. CVE-2022-0459 Use after free in Screen Capture. CVE-2022-0603: Use after free in File Manager. CVE-2022-0604: Heap buffer overflow in Tab Groups. CVE-2022-0605: Use after free in Webstore API. CVE-2022-0606: Use after free in ANGLE. CVE-2022-0607: Use after free in GPU. CVE-2022-0608: Integer overflow in Mojo. CVE-2022-0609: Use after free in Animation. Google reports these as being actively exploited in the wild, which means: ** If you use Chromium on Fedora, stop using it NOW ** Can we fix this situation somehow? Browsers are the most critical thing to get security updates as fast as possible. Having bugs unfixed for a month that are exploited in the wild is *bad* and puts our users at serious risk. RPMFusion seems to push timely updates - can we reuse that? Should users be pointed towards RPMFusion instead in the meantime? Thoughts? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is the chromium debuginfo package exists?
Samuel Sieb writes:
> On 2021-07-25 2:38 p.m., Mikhail Gavrilov wrote:
>> Is the chromium debuginfo package exists?
>> Quick searching in repos didn't find any debuginfo packages for chromium.
>
> There haven't been any debuginfo packages for chromium for at least a
> very long time. I assume it's disabled for some reason.
chromium.spec sez:
# Debuginfo packages aren't very useful here. If you need to debug
# you should do a proper debug build (not implemented in this spec yet)
%global debug_package %{nil}
People calling for it suggests the assertion of being "not very useful"
may be mistaken.
- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Is the chromium debuginfo package exists?
On 2021-07-25 2:38 p.m., Mikhail Gavrilov wrote: Is the chromium debuginfo package exists? Quick searching in repos didn't find any debuginfo packages for chromium. There haven't been any debuginfo packages for chromium for at least a very long time. I assume it's disabled for some reason. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Is the chromium debuginfo package exists?
Hi folks! Is the chromium debuginfo package exists? Quick searching in repos didn't find any debuginfo packages for chromium. # dnf search chromium | grep debuginfo Last metadata expiration check: 0:08:12 ago on Mon 26 Jul 2021 02:25:19 AM +05. chromium-bsu-debuginfo.x86_64 : Debug information for package chromium-bsu lightspark-chromium-plugin-debuginfo.x86_64 : Debug information for package lightspark-chromium-plugin And of course I enabled "rawhide-debuginfo" repo. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Chromium built in rawhide does not render most strings
* Kevin Kofler via devel: > Florian Weimer wrote: >> This is currently not a major consideration for system call design. We >> can't add this downstream from the kernel if support just isn't there. >> You have to solve these issues for porting to other architectures >> anyway. > > So the upstream Linux kernel does not care about security? Sad! I don't think that's a correct characterization of the situation. Unfortunately, seccomp filters also block system calls that are necessary to avoid bugs (see faccessat2). And developers that usually subscribe to the Move Fast, Break Things motto need many months to fix broken seccomp filters. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Florian Weimer wrote: > This is currently not a major consideration for system call design. We > can't add this downstream from the kernel if support just isn't there. > You have to solve these issues for porting to other architectures > anyway. So the upstream Linux kernel does not care about security? Sad! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
* Kevin Kofler via devel:
> But the thing is, fstatat is not really a newer version of fstat, it
> unfortunately has very different security properties. fstat allows
> retrieving the stat metadata only of already open files (if you know or
> guess the fd). On the other hand, fstatat allows retrieving the stat
> metadata of ANY file on the file system. It even accepts an absolute path as
> the relative pathspec, in which case the fd is ignored entirely. (And I
> guess it also allows directory traversal using "..", but that does not
> matter anyway since it also accepts absolute paths to begin with.) And the
> only way to distinguish the fstat case ("" pathspec) from the stat case
> (absolute pathspec) is to actually look at the string, which cannot be done
> in BPF.
This is currently not a major consideration for system call design. We
can't add this downstream from the kernel if support just isn't there.
You have to solve these issues for porting to other architectures
anyway.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Kevin Kofler via devel wrote:
> But the thing is, fstatat is not really a newer version of fstat, it
> unfortunately has very different security properties. fstat allows
> retrieving the stat metadata only of already open files (if you know or
> guess the fd). On the other hand, fstatat allows retrieving the stat
> metadata of ANY file on the file system. It even accepts an absolute path
> as the relative pathspec, in which case the fd is ignored entirely. (And I
> guess it also allows directory traversal using "..", but that does not
> matter anyway since it also accepts absolute paths to begin with.) And the
> only way to distinguish the fstat case ("" pathspec) from the stat case
> (absolute pathspec) is to actually look at the string, which cannot be
> done in BPF.
Actually, there is one way the SIGSYS handler could call back into fstatat
without triggering another SIGSYS: instead of passing the original empty
string, it could pass a global empty string constant, which has a known
address that could be whitelisted in BPF.
So the BPF would look like:
if (args[3] == AT_EMPTY_PATH) {
if (args[1] == global_empty_string) { // pointer comparison
allow();
} else {
trap(); // to the SIGSYS handler checking that the string is empty
}
} else {
error(EACCES);
}
But all this is just papering over the fact that the fstatat syscall is just
too flexible for sandboxing.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Florian Weimer wrote:
> The fstat/fstat64 system call does not exist on arc and riscv/rv32.
> glibc tries to consolidate the implementations as far as possible, so if
> the kernel deprecates a system call and the replacement is already
> supported by all architectures, glibc uses that, rather than maintaing
> architecture-specific code to call the earliest possible implemented
> system call.
That explains it. So my patch calling the fstat64 syscall (fstat on 64-bit
platforms) in the fstatat handler should be fine on those platforms that
support the fstat(64) syscall.
But the thing is, fstatat is not really a newer version of fstat, it
unfortunately has very different security properties. fstat allows
retrieving the stat metadata only of already open files (if you know or
guess the fd). On the other hand, fstatat allows retrieving the stat
metadata of ANY file on the file system. It even accepts an absolute path as
the relative pathspec, in which case the fd is ignored entirely. (And I
guess it also allows directory traversal using "..", but that does not
matter anyway since it also accepts absolute paths to begin with.) And the
only way to distinguish the fstat case ("" pathspec) from the stat case
(absolute pathspec) is to actually look at the string, which cannot be done
in BPF.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
* Kevin Kofler via devel: > Unfortunately, the fix is more complicated than that. It is really not > helpful behavior from glibc to use the fstatat syscall to implement fstat. > (What is the benefit of doing that?) The fstat/fstat64 system call does not exist on arc and riscv/rv32. glibc tries to consolidate the implementations as far as possible, so if the kernel deprecates a system call and the replacement is already supported by all architectures, glibc uses that, rather than maintaing architecture-specific code to call the earliest possible implemented system call. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Florian Weimer wrote: > I suspect some of the preprocessor conditionals in > SyscallSets::IsFileSystem in > > <https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc> > > need fixing. Unfortunately, the fix is more complicated than that. It is really not helpful behavior from glibc to use the fstatat syscall to implement fstat. (What is the benefit of doing that?) It is particularly hard to detect that an fstatat call is really an fstat in a seccomp sandbox because BPF does not support validating string arguments, but the path being an empty string is a necessary condition to check. I have come up with this fix: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/master/f/qtwebengine-everywhere-src-5.15.2-%231904652.patch that works for me (and it actually ends up calling the fstat syscall as the old glibc did, because that is the only safe way to prevent retriggering another SIGSYS from the SIGSYS handler). So far, it has not yet been applied to the chromium package, only to qt5-qtwebengine. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Tom Callaway wrote: > https://bugs.chromium.org/p/chromium/issues/detail?id=1164975 > > Please add in this info, it was on my TODO list, but clearly hasn't > happened yet. https://bugs.chromium.org/p/chromium/issues/detail?id=1164975#c8 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
https://bugs.chromium.org/p/chromium/issues/detail?id=1164975 Please add in this info, it was on my TODO list, but clearly hasn't happened yet. ~spot On Wed, Jan 13, 2021 at 8:33 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Wednesday, 13 January 2021 at 03:14, Kevin Kofler via devel wrote: > > Florian Weimer wrote: > > > Right, and the glibc 2.33 versions all call fstatat64 in the end > (system > > > call number 0x106). > > > > That would be: > > > > #if !defined(__NR_newfstatat) > > #define __NR_newfstatat 262 > > #endif > > > > from: > > > > > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h > > > > > The older x versions call the earlier system calls > > > (numbers 4, 5, 6) > > > > And these are defined as: > > > > #if !defined(__NR_stat) > > #define __NR_stat 4 > > #endif > > > > #if !defined(__NR_fstat) > > #define __NR_fstat 5 > > #endif > > > > #if !defined(__NR_lstat) > > #define __NR_lstat 6 > > #endif > > > > I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like > > __NR_stat and __NR_lstat, whereas __NR_fstat is under > > IsAllowedFileSystemAccessViaFd. So the issue is that everything now > calls > > the same syscall under the hood, so the sandbox can no longer > distinguish > > the two access types just by looking at the syscall ID. > > > > The baseline policy disallows everything under IsFileSystem and allows > only > > IsAllowedFileSystemAccessViaFd: > > > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc > > (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and > > __NR_newfstatat are not). > > I think you wanted to link > > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc > here instead. > __NR_newfstatat is at line 116 and __NR_fstat is at line 170. Note that > plain __NR_stat and __NR_lstat are also rejected (lines 101 and 94). > > > It looks like it needs to restrict the arguments to __NR_newfstatat (to > an > > empty path and the AT_EMPTYPATH flag) instead of rejecting it outright, > so > > that fstat keeps working, see: > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD > > Is there an upstream bug open for this already? > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
On Wednesday, 13 January 2021 at 03:14, Kevin Kofler via devel wrote: > Florian Weimer wrote: > > Right, and the glibc 2.33 versions all call fstatat64 in the end (system > > call number 0x106). > > That would be: > > #if !defined(__NR_newfstatat) > #define __NR_newfstatat 262 > #endif > > from: > > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h > > > The older x versions call the earlier system calls > > (numbers 4, 5, 6) > > And these are defined as: > > #if !defined(__NR_stat) > #define __NR_stat 4 > #endif > > #if !defined(__NR_fstat) > #define __NR_fstat 5 > #endif > > #if !defined(__NR_lstat) > #define __NR_lstat 6 > #endif > > I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like > __NR_stat and __NR_lstat, whereas __NR_fstat is under > IsAllowedFileSystemAccessViaFd. So the issue is that everything now calls > the same syscall under the hood, so the sandbox can no longer distinguish > the two access types just by looking at the syscall ID. > > The baseline policy disallows everything under IsFileSystem and allows only > IsAllowedFileSystemAccessViaFd: > https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc > (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and > __NR_newfstatat are not). I think you wanted to link https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc here instead. __NR_newfstatat is at line 116 and __NR_fstat is at line 170. Note that plain __NR_stat and __NR_lstat are also rejected (lines 101 and 94). > It looks like it needs to restrict the arguments to __NR_newfstatat (to an > empty path and the AT_EMPTYPATH flag) instead of rejecting it outright, so > that fstat keeps working, see: > https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD Is there an upstream bug open for this already? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Florian Weimer wrote: > Right, and the glibc 2.33 versions all call fstatat64 in the end (system > call number 0x106). That would be: #if !defined(__NR_newfstatat) #define __NR_newfstatat 262 #endif from: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h > The older x versions call the earlier system calls > (numbers 4, 5, 6) And these are defined as: #if !defined(__NR_stat) #define __NR_stat 4 #endif #if !defined(__NR_fstat) #define __NR_fstat 5 #endif #if !defined(__NR_lstat) #define __NR_lstat 6 #endif I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like __NR_stat and __NR_lstat, whereas __NR_fstat is under IsAllowedFileSystemAccessViaFd. So the issue is that everything now calls the same syscall under the hood, so the sandbox can no longer distinguish the two access types just by looking at the syscall ID. The baseline policy disallows everything under IsFileSystem and allows only IsAllowedFileSystemAccessViaFd: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and __NR_newfstatat are not). It looks like it needs to restrict the arguments to __NR_newfstatat (to an empty path and the AT_EMPTYPATH flag) instead of rejecting it outright, so that fstat keeps working, see: https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
* Kevin Kofler via devel: > Florian Weimer wrote: >> It's not. It may be a completely different system call. > > So now I had a new idea how to figure out what difference the version of > glibc we are compiling against can make: track down the symbol version: > nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 | grep > '@GLIBC_2\.33' > U fstat64@GLIBC_2.33 > U fstatat64@GLIBC_2.33 > U lstat64@GLIBC_2.33 > U stat64@GLIBC_2.33 > > So we are getting new symbol versions of the above 4 functions. So now we > only need to know what is different between the above and the syscalls > presumably used previously: > nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.1 | grep > 'stat\(at\)\?64' > U __fxstat64@GLIBC_2.2.5 > U __fxstatat64@GLIBC_2.4 > U __lxstat64@GLIBC_2.2.5 > U __xstat64@GLIBC_2.2.5 > (That's the version from F33 GA, definitely built against an older glibc.) Right, and the glibc 2.33 versions all call fstatat64 in the end (system call number 0x106). The older x versions call the earlier system calls (numbers 4, 5, 6). Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Kevin Kofler via devel wrote: > So now I had a new idea how to figure out what difference the version of > glibc we are compiling against can make: track down the symbol version: > nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 | > grep '@GLIBC_2\.33' > U fstat64@GLIBC_2.33 > U fstatat64@GLIBC_2.33 > U lstat64@GLIBC_2.33 > U stat64@GLIBC_2.33 > > So we are getting new symbol versions of the above 4 functions. So now we > only need to know what is different between the above and the syscalls > presumably used previously: > nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.1 | > grep 'stat\(at\)\?64' > U __fxstat64@GLIBC_2.2.5 > U __fxstatat64@GLIBC_2.4 > U __lxstat64@GLIBC_2.2.5 > U __xstat64@GLIBC_2.2.5 > (That's the version from F33 GA, definitely built against an older glibc.) PS: This commit: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e is why the version of glibc used at compile time makes a difference. Until glibc 2.32, stat64 etc. were redirected to __xstat64 etc. by inline functions or macros; glibc 2.33 changed them to true functions. As a result, code compiled against glibc 2.32 or older will get the old __xstat64 etc. implementation that is still present, whereas code compiled against glibc 2.33 will get the new stat64 etc. implementation. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Florian Weimer wrote: > It's not. It may be a completely different system call. So now I had a new idea how to figure out what difference the version of glibc we are compiling against can make: track down the symbol version: nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 | grep '@GLIBC_2\.33' U fstat64@GLIBC_2.33 U fstatat64@GLIBC_2.33 U lstat64@GLIBC_2.33 U stat64@GLIBC_2.33 So we are getting new symbol versions of the above 4 functions. So now we only need to know what is different between the above and the syscalls presumably used previously: nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.1 | grep 'stat\(at\)\?64' U __fxstat64@GLIBC_2.2.5 U __fxstatat64@GLIBC_2.4 U __lxstat64@GLIBC_2.2.5 U __xstat64@GLIBC_2.2.5 (That's the version from F33 GA, definitely built against an older glibc.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Florian Weimer wrote: > It's not. It may be a completely different system call. > > Is there a way to get logging of filtered system calls from the sandbox? What I'd suggest doing is strace-ing the rendering process in the version built against glibc 2.32 vs. the version built against glibc 2.33/2.32.9x and compare the syscalls it uses, to see what changed. I see a few syscall use changes in glibc, but they are in .c files, not in .h files, so I am surprised that the version of glibc used at build time apparently matters. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
* Tom Callaway: > Based on my (admittedly extremely limited) understanding of things, this > seems correct as > is: > > #if defined(__x86_64__) || defined(__aarch64__) > case __NR_newfstatat: // fstatat(). EPERM not a valid errno. > #elif defined(__i386__) || defined(__arm__) || \ > (defined(ARCH_CPU_MIPS_FAMILY) && defined(ARCH_CPU_32_BITS)) > case __NR_fstatat64: > #endif > > Is fstatat64 actually implemented on x86_64 now? It's not. It may be a completely different system call. Is there a way to get logging of filtered system calls from the sandbox? > Alternately, if you'd prefer to simply open an upstream bug with > Google, just let me know. :) I want to be helpful here, but not waste > your time. It makes sense to do that anyway, to share information across distributions. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Based on my (admittedly extremely limited) understanding of things, this seems correct as is: #if defined(__x86_64__) || defined(__aarch64__) case __NR_newfstatat: // fstatat(). EPERM not a valid errno. #elif defined(__i386__) || defined(__arm__) || \ (defined(ARCH_CPU_MIPS_FAMILY) && defined(ARCH_CPU_32_BITS)) case __NR_fstatat64: #endif Is fstatat64 actually implemented on x86_64 now? Alternately, if you'd prefer to simply open an upstream bug with Google, just let me know. :) I want to be helpful here, but not waste your time. Thanks, ~spot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
* Tom Callaway: > Looks like this might be it. Running with --no-sandbox brings back the > strings. Is there a reference to how the stat calls should now be > done? I suspect some of the preprocessor conditionals in SyscallSets::IsFileSystem in <https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc> need fixing. I expect more fstatat/fstatat64 usage in current glibc. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Looks like this might be it. Running with --no-sandbox brings back the strings. Is there a reference to how the stat calls should now be done? Thanks, ~spot On Fri, Jan 8, 2021 at 8:58 AM Florian Weimer wrote: > * Tom Callaway: > > > This makes me very suspicious of something in glibc between 2.32 > > (Fedora 33) and 2.32.9000 (rawhide), but I'm not sure where to look > > from here. Any ideas? > > Does the issue go away if you disable the Chromium sandbox? > > One difference is that the stat functions are called in a different way, > and perhaps the sandbox isn't ready for that. > > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
* Daniel P. Berrangé: > On Fri, Jan 08, 2021 at 02:58:02PM +0100, Florian Weimer wrote: >> * Tom Callaway: >> >> > This makes me very suspicious of something in glibc between 2.32 >> > (Fedora 33) and 2.32.9000 (rawhide), but I'm not sure where to look >> > from here. Any ideas? >> >> Does the issue go away if you disable the Chromium sandbox? >> >> One difference is that the stat functions are called in a different way, >> and perhaps the sandbox isn't ready for that. > > Or another case of the faccessat -> faccessat2 problem ? That issue would be visible with just a glibc upgrade, without a rebuild. The initial test (Fedora 33 on rawhide) seems to show that this is not happening. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
On Fri, Jan 08, 2021 at 02:58:02PM +0100, Florian Weimer wrote: > * Tom Callaway: > > > This makes me very suspicious of something in glibc between 2.32 > > (Fedora 33) and 2.32.9000 (rawhide), but I'm not sure where to look > > from here. Any ideas? > > Does the issue go away if you disable the Chromium sandbox? > > One difference is that the stat functions are called in a different way, > and perhaps the sandbox isn't ready for that. Or another case of the faccessat -> faccessat2 problem ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
* Tom Callaway: > This makes me very suspicious of something in glibc between 2.32 > (Fedora 33) and 2.32.9000 (rawhide), but I'm not sure where to look > from here. Any ideas? Does the issue go away if you disable the Chromium sandbox? One difference is that the stat functions are called in a different way, and perhaps the sandbox isn't ready for that. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Okay, to try to narrow this down a bit, I setup a very large AWS Fedora 33 instance and built chromium packages, then installed them into a second Fedora Rawhide instance. As before, these packages work fine. (This is our baseline) Next, I updated glibc (and JUST glibc, glibc-common, glibc-devel, glibc-headers, glibc-langpack-en) from Rawhide on the Fedora 33 instance and built the chromium package again. This build, when installed into Fedora Rawhide, exhibits the text rendering issue. This makes me very suspicious of something in glibc between 2.32 (Fedora 33) and 2.32.9000 (rawhide), but I'm not sure where to look from here. Any ideas? ~spot On Sun, Jan 3, 2021 at 4:49 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 02/01/21 22:57, Kevin Kofler via devel ha scritto: > > Tom Callaway wrote: > >> I rebuilt chromium, but it did not resolve the issue. > > So what can we do to resolve the issue? Surely we cannot leave both > Chromium > > and Falkon unable to render text forever. > > > > Kevin Kofler > > ___ > > The problem seems to be qt5-qtwebengine is unable to use system fonts. > It doesn't render text using default fonts (i.e. 'serif' or 'sans-serif' > css styles), but it does render text using custom css fonts. In fact, it > renders most of qt.io homepage (using 'Titillium Web' custom css font) > and also some text on Bodhi homepage (using 'Open Sans' custom css font). > > However, opening, for example, Falkon settings, I can get the fonts > under the Character settings and the preview works. > > Mattia > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Il 02/01/21 22:57, Kevin Kofler via devel ha scritto: > Tom Callaway wrote: >> I rebuilt chromium, but it did not resolve the issue. > So what can we do to resolve the issue? Surely we cannot leave both Chromium > and Falkon unable to render text forever. > > Kevin Kofler > ___ The problem seems to be qt5-qtwebengine is unable to use system fonts. It doesn't render text using default fonts (i.e. 'serif' or 'sans-serif' css styles), but it does render text using custom css fonts. In fact, it renders most of qt.io homepage (using 'Titillium Web' custom css font) and also some text on Bodhi homepage (using 'Open Sans' custom css font). However, opening, for example, Falkon settings, I can get the fonts under the Character settings and the preview works. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Tom Callaway wrote: > I rebuilt chromium, but it did not resolve the issue. So what can we do to resolve the issue? Surely we cannot leave both Chromium and Falkon unable to render text forever. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
I rebuilt chromium, but it did not resolve the issue. ~spot On Wed, Dec 30, 2020 at 5:35 PM Marius Schwarz wrote: > Am 30.12.20 um 14:07 schrieb Mattia Verga via devel: > > Il 30/12/20 10:14, Marius Schwarz ha scritto: > >> Don't you need to recompile stuff first to have an effect? :) > >> > >> > > I've just pushed a rebuild for qt5-qtwebengine, let's see if that's > enough. > > > > I had a chromium 85 build running instead of the 87er, that had no > problems rendering texts. My guerss is, that chromium needs a rebuild too. > > Best regards, > Marius > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Am 30.12.20 um 14:07 schrieb Mattia Verga via devel: Il 30/12/20 10:14, Marius Schwarz ha scritto: Don't you need to recompile stuff first to have an effect? :) I've just pushed a rebuild for qt5-qtwebengine, let's see if that's enough. I had a chromium 85 build running instead of the 87er, that had no problems rendering texts. My guerss is, that chromium needs a rebuild too. Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Il 30/12/20 10:14, Marius Schwarz ha scritto: > > Don't you need to recompile stuff first to have an effect? :) > > I've just pushed a rebuild for qt5-qtwebengine, let's see if that's enough. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Am 30.12.20 um 04:53 schrieb Jeff Law: To be clear (and I know you know this, but your readers might not know), QtWebEngine (qt5-qtwebengine) and Chromium (chromium) are distinct packages (none of them depends on each other), each containing a slightly different copy of essentially the same source code (plus some higher-layer code that is entirely different: Qt wrapper libraries vs. a browser application). But since the source code is largely the same, things such as miscompilations by the compiler are likely to affect both the same way. And the symptoms in the 2 screenshots definitely look identical. I think this has been fixed with the latest gcc drop into rawhide. jeff Don't you need to recompile stuff first to have an effect? :) Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
On 12/20/20 7:45 PM, Kevin Kofler via devel wrote: > Neal Gompa wrote: >> QtWebEngine *is* Chromium, so it would make sense that it exhibits the >> same problem. > To be clear (and I know you know this, but your readers might not know), > QtWebEngine (qt5-qtwebengine) and Chromium (chromium) are distinct packages > (none of them depends on each other), each containing a slightly different > copy of essentially the same source code (plus some higher-layer code that > is entirely different: Qt wrapper libraries vs. a browser application). But > since the source code is largely the same, things such as miscompilations by > the compiler are likely to affect both the same way. And the symptoms in the > 2 screenshots definitely look identical. I think this has been fixed with the latest gcc drop into rawhide. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Am 17.12.20 um 17:12 schrieb Tom Callaway: Okay, this one has me stumped. Any chromium package I build through rawhide refuses to render most of the strings. Any updates on this? Best regards, Marius Schwarz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Neal Gompa wrote: > QtWebEngine *is* Chromium, so it would make sense that it exhibits the > same problem. To be clear (and I know you know this, but your readers might not know), QtWebEngine (qt5-qtwebengine) and Chromium (chromium) are distinct packages (none of them depends on each other), each containing a slightly different copy of essentially the same source code (plus some higher-layer code that is entirely different: Qt wrapper libraries vs. a browser application). But since the source code is largely the same, things such as miscompilations by the compiler are likely to affect both the same way. And the symptoms in the 2 screenshots definitely look identical. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Am 17.12.20 um 17:12 schrieb Tom Callaway: Okay, this one has me stumped. Any chromium package I build through rawhide refuses to render most of the strings. Afaik chromium can't access libva anymore. On the pinephone, where i noticed this bug, it said so itself. Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
I downgraded cairo to 1.16.0-9.fc33 and it had no effect, the bug remained. Thanks, ~spot On Thu, Dec 17, 2020 at 11:19 AM Kalev Lember wrote: > On Thu, Dec 17, 2020 at 5:12 PM Tom Callaway wrote: > >> Okay, this one has me stumped. Any chromium package I build through >> rawhide refuses to render most of the strings. >> >> At first, I thought this was gcc 11, but then I noticed that the first >> build with this problem was built before GCC 11 landed in rawhide (the >> compiler was the same n-v-r as the one in Fedora 33). Next, I thought it >> must be due to a newer system component that Chromium uses dynamically, but >> I was able to disprove that by installing the Fedora 33 build (same >> version-release) into a Rawhide VM, and it works fine. Google Chrome also >> works fine in rawhide. >> >> It seems that this must be something that is contained within chromium, >> that when built in rawhide, builds broken. >> >> Here's a screenshot of what it looks like: >> https://twitter.com/spotfoss/status/1338918235719299072/photo/1 >> >> Note that some text strings are rendering (in the UI, in the "search >> box"), but most of them are not (the "HTML5Test" text below the icon, all >> of the strings in the developer console). >> > > Can you try downgrading cairo to the f33 version (1.16.0), just to rule > that out? We updated it to the 1.17.4 development version in rawhide and I > think we're the first distro to ship it, so it could possibly have issues. > > -- > Kalev > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Certainly not ruling out glibc as the problem here, but if it was glibc, I would think the problem would arise when I install the Fedora 33 build in rawhide, and it does not... ~spot On Thu, Dec 17, 2020 at 12:10 PM Robbie Harwood wrote: > Tom Callaway writes: > > > I cannot install the rawhide-built chromium into F33 without bringing > glibc > > from rawhide with me: > > > > [spot@localhost ~]$ sudo rpm -Uvh > > chromium-common-87.0.4280.88-1.fc34.x86_64.rpm > > chromium-87.0.4280.88-1.fc34.x86_64.rpm > > error: Failed dependencies: > > libc.so.6(GLIBC_2.33)(64bit) is needed by > > chromium-common-87.0.4280.88-1.fc34.x86_64 > > libc.so.6(GLIBC_2.33)(64bit) is needed by > > chromium-87.0.4280.88-1.fc34.x86_64 > > > > When I _just_ update glibc from rawhide on an otherwise Fedora 33 > instance > > (glibc, glibc-all-langpacks, glibc-common, glibc-devel, > glibc-headers-x86, > > glibc-langpack-en), then install the rawhide built chromium, it exhibits > > the same missing strings bug. > > Interesting. Seems like that points at the problem being > glibc-adjacent, no? That's still really wide though... > > Thanks, > --Robbie > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Tom Callaway writes: > I cannot install the rawhide-built chromium into F33 without bringing glibc > from rawhide with me: > > [spot@localhost ~]$ sudo rpm -Uvh > chromium-common-87.0.4280.88-1.fc34.x86_64.rpm > chromium-87.0.4280.88-1.fc34.x86_64.rpm > error: Failed dependencies: > libc.so.6(GLIBC_2.33)(64bit) is needed by > chromium-common-87.0.4280.88-1.fc34.x86_64 > libc.so.6(GLIBC_2.33)(64bit) is needed by > chromium-87.0.4280.88-1.fc34.x86_64 > > When I _just_ update glibc from rawhide on an otherwise Fedora 33 instance > (glibc, glibc-all-langpacks, glibc-common, glibc-devel, glibc-headers-x86, > glibc-langpack-en), then install the rawhide built chromium, it exhibits > the same missing strings bug. Interesting. Seems like that points at the problem being glibc-adjacent, no? That's still really wide though... Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
On Thu, Dec 17, 2020 at 12:02 PM Mattia Verga via devel wrote: > > Il 17/12/20 17:12, Tom Callaway ha scritto: > > Okay, this one has me stumped. Any chromium package I build through > > rawhide refuses to render most of the strings. > > Seems similar to what I reported for Falkon: > > https://bugzilla.redhat.com/show_bug.cgi?id=1904652 > > Does Chromium uses qt5-qtwebengine? > QtWebEngine *is* Chromium, so it would make sense that it exhibits the same problem. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Il 17/12/20 17:12, Tom Callaway ha scritto: > Okay, this one has me stumped. Any chromium package I build through > rawhide refuses to render most of the strings. Seems similar to what I reported for Falkon: https://bugzilla.redhat.com/show_bug.cgi?id=1904652 Does Chromium uses qt5-qtwebengine? Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
I cannot install the rawhide-built chromium into F33 without bringing glibc
from rawhide with me:
[spot@localhost ~]$ sudo rpm -Uvh
chromium-common-87.0.4280.88-1.fc34.x86_64.rpm
chromium-87.0.4280.88-1.fc34.x86_64.rpm
error: Failed dependencies:
libc.so.6(GLIBC_2.33)(64bit) is needed by
chromium-common-87.0.4280.88-1.fc34.x86_64
libc.so.6(GLIBC_2.33)(64bit) is needed by
chromium-87.0.4280.88-1.fc34.x86_64
When I _just_ update glibc from rawhide on an otherwise Fedora 33 instance
(glibc, glibc-all-langpacks, glibc-common, glibc-devel, glibc-headers-x86,
glibc-langpack-en), then install the rawhide built chromium, it exhibits
the same missing strings bug.
~spot
On Thu, Dec 17, 2020 at 11:29 AM Robbie Harwood wrote:
> Tom Callaway writes:
>
> > Okay, this one has me stumped. Any chromium package I build through
> rawhide
> > refuses to render most of the strings.
> >
> > At first, I thought this was gcc 11, but then I noticed that the first
> > build with this problem was built before GCC 11 landed in rawhide (the
> > compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
> > must be due to a newer system component that Chromium uses dynamically,
> but
> > I was able to disprove that by installing the Fedora 33 build (same
> > version-release) into a Rawhide VM, and it works fine. Google Chrome also
> > works fine in rawhide.
> >
> > Chromium has a lot of bundled components, so it is usually fairly
> resistant
> > to system changes. There are no differences between how Chromium builds
> > (within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
> > %{optflags}, so the compiler flags are equivalent.
> >
> > Could this be due to some quirk of binutils in the way chromium gets
> linked
> > in rawhide? Is there something else unique to how packages are built in
> > rawhide right now? Are any other rawhide packages having similar string
> > issues?
>
> Have you tried the reverse? rawhide-built chromium into fc33?
>
> Thanks,
> --Robbie
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Tom Callaway writes:
> Okay, this one has me stumped. Any chromium package I build through rawhide
> refuses to render most of the strings.
>
> At first, I thought this was gcc 11, but then I noticed that the first
> build with this problem was built before GCC 11 landed in rawhide (the
> compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
> must be due to a newer system component that Chromium uses dynamically, but
> I was able to disprove that by installing the Fedora 33 build (same
> version-release) into a Rawhide VM, and it works fine. Google Chrome also
> works fine in rawhide.
>
> Chromium has a lot of bundled components, so it is usually fairly resistant
> to system changes. There are no differences between how Chromium builds
> (within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
> %{optflags}, so the compiler flags are equivalent.
>
> Could this be due to some quirk of binutils in the way chromium gets linked
> in rawhide? Is there something else unique to how packages are built in
> rawhide right now? Are any other rawhide packages having similar string
> issues?
Have you tried the reverse? rawhide-built chromium into fc33?
Thanks,
--Robbie
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
On Thu, Dec 17, 2020 at 5:12 PM Tom Callaway wrote: > Okay, this one has me stumped. Any chromium package I build through > rawhide refuses to render most of the strings. > > At first, I thought this was gcc 11, but then I noticed that the first > build with this problem was built before GCC 11 landed in rawhide (the > compiler was the same n-v-r as the one in Fedora 33). Next, I thought it > must be due to a newer system component that Chromium uses dynamically, but > I was able to disprove that by installing the Fedora 33 build (same > version-release) into a Rawhide VM, and it works fine. Google Chrome also > works fine in rawhide. > > It seems that this must be something that is contained within chromium, > that when built in rawhide, builds broken. > > Here's a screenshot of what it looks like: > https://twitter.com/spotfoss/status/1338918235719299072/photo/1 > > Note that some text strings are rendering (in the UI, in the "search > box"), but most of them are not (the "HTML5Test" text below the icon, all > of the strings in the developer console). > Can you try downgrading cairo to the f33 version (1.16.0), just to rule that out? We updated it to the 1.17.4 development version in rawhide and I think we're the first distro to ship it, so it could possibly have issues. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Chromium built in rawhide does not render most strings
Okay, this one has me stumped. Any chromium package I build through rawhide
refuses to render most of the strings.
At first, I thought this was gcc 11, but then I noticed that the first
build with this problem was built before GCC 11 landed in rawhide (the
compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
must be due to a newer system component that Chromium uses dynamically, but
I was able to disprove that by installing the Fedora 33 build (same
version-release) into a Rawhide VM, and it works fine. Google Chrome also
works fine in rawhide.
It seems that this must be something that is contained within chromium,
that when built in rawhide, builds broken.
Here's a screenshot of what it looks like:
https://twitter.com/spotfoss/status/1338918235719299072/photo/1
Note that some text strings are rendering (in the UI, in the "search box"),
but most of them are not (the "HTML5Test" text below the icon, all of the
strings in the developer console).
Chromium has a lot of bundled components, so it is usually fairly resistant
to system changes. There are no differences between how Chromium builds
(within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
%{optflags}, so the compiler flags are equivalent.
Could this be due to some quirk of binutils in the way chromium gets linked
in rawhide? Is there something else unique to how packages are built in
rawhide right now? Are any other rawhide packages having similar string
issues?
Here are some builds for comparison:
Fedora 34: Chromium 87.0.4280.88 (built against GCC 11):
https://koji.fedoraproject.org/koji/taskinfo?taskID=57595738
Fedora 34: Chromium 87.0.4280.88 (built against GCC 10, same as Fedora 33):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 33: Chromium 87.0.4280.88 (build against GCC 10, but actually works
in rawhide):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 34: Chromium 88.0.4324.27 (beta version of chromium, also broken)
https://koji.fedoraproject.org/koji/taskinfo?taskID=56977476
Thanks in advance,
~spot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Conflicting build-ids in chromium and chromium-freeworld
On 2020-09-21 12:08, Mark Wielaard wrote: > Hi, > > On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: >> On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: >>> Hi. There is an ongoing problem with conflicting build-ids in chromium >>> and chromium-freeworld [1][2]: >>>> Error: Transaction test error: >>>>file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>> >>> There is no clear idea why it happens, but my assumption is that due to >>> the fact of building with the same source code (with similar patches), >>> some generated shared libraries are the same which generates conflict(s). > > The error message could probably be improved. > You might want to look at where the /usr/lib/.build-id/xx/ symlinks > are pointing at to get a better idea which binaries are identical > between the packages. > >>> The quick look at the algorithm for build-id generation [3] doesn't >>> answer my question what exactly is taken into account for their >>> generation and more precisely is there is way to add some "fuzz" (having >>> different buildroots doesn't help) to distinguish those libraries. > > The build-id is calculated over all relevant build environment bits (by > the linker, not rpm). This includes the debuginfo in the original (not > split) ELF file. The debuginfo contains the build paths (which should > be different for different NVRs and include the compiler version and > flags). This really should prevent identical build-ids whenever > something is really build from source. Normally you only get identical > build-ids when building the same source code in the same package with > the same compiler flags. Identical build-ids between packages are > really very rare and are often caused by some binary blob simply being > copied between packages (is there a blob in the upstream tar ball that > isn't build from source?) or if debuginfo (-g) is missing. > >>> To wrap up: >>> 1. Is there a better way to deal with the aforementioned build-id >>> conflicts than disable their generation on one side (with "%global >>> _build_id_links none")? >> >> Instead of disabling entirely, you could tell rpm to put it all into >> -debuginfo packages (ie the original debuginfo layout). Which would >> still conflict, but fewer people are affected: >> >> %global _build_id_links alldebug > > Yes, that is a much better workaround than using none. It sounds very sensible :). Especially, as a workaround, in the situation that solving issues with duplicated shared libraries between packages was problematic. Thanks you guys for suggestions. Marcin > >>> 2. Maybe my assumption about the same generated shared libraries is >>> wrong and there is something else what can be done to fix the root problem? >> >> That's exactly the cause, build-id's are engineered to reproducably >> identify identical built objects, regardless of their location. Which >> causes conflicts when the house rules of not shipping multiple idental >> copies is broken (one might call this a feature). > > Yes, I would call this a feature :) > >> Short of unbundling the shared libraries, I guess a reasonable >> workaround would be patching them to include some identifier string >> based on the containing package name, which would cause them to have >> different build_ids. > > If build from source and building with debuginfo that should already be > the case because the
Re: Conflicting build-ids in chromium and chromium-freeworld
Le lun. 21 sept. 2020 à 12:08, Mark Wielaard a écrit : > > Hi, > > On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: > > On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: > > > Hi. There is an ongoing problem with conflicting build-ids in chromium > > > and chromium-freeworld [1][2]: > > > > Error: Transaction test error: > > > >file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > > > > There is no clear idea why it happens, but my assumption is that due to > > > the fact of building with the same source code (with similar patches), > > > some generated shared libraries are the same which generates conflict(s). > > The error message could probably be improved. > You might want to look at where the /usr/lib/.build-id/xx/ symlinks > are pointing at to get a better idea which binaries are identical > between the packages. > > > > The quick look at the algorithm for build-id generation [3] doesn't > > > answer my question what exactly is taken into account for their > > > generation and more precisely is there is way to add some "fuzz" (having > > > different buildroots doesn't help) to distinguish those libraries. > > The build-id is calculated over all relevant build environment bits (by > the linker, not rpm). This includes the debuginfo in the original (not > split) ELF file. The debuginfo contains the build paths (which should > be different for different NVRs and include the compiler version and > flags). This really should prevent identical build-ids whenever > something is really build from source. Normally you only get identical > build-ids when building the same source code in the same package with > the same compiler flags. Identical build-ids between packages are > really very rare and are often caused by some binary blob simply being > copied between packages (is there a blob in the upstream tar ball that > isn't build from source?) or if debuginfo (-g) is missing. Hello Mark, thanks for confirming that case. (buildID conflict might be caused by binaries not built from sources) The suspected files are the following: (same for the fedora version). lrwxrwxrwx. 1 root root 55 11 sept. 18:54 /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b -> ../../../../usr/lib64/chromium-freeworld/chrome-sandbox lrwxrwxrwx. 1 root root 65 11 sept. 18:54 /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee -> ../../../../usr/lib64/chromium-freeworld/swiftshader/libGLESv2.so lrwxrwxrwx. 1 root root 53 11 sept. 18:54 /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 -> ../../../../usr/lib64/chromium-freeworld/libGLESv2.so lrwxrwxrwx. 1 root root 62 11 sept. 18:54 /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 -> ../../../../usr/lib64/chromium-freeworld/swiftshader/libEGL.so lrwxrwxrwx. 1 root root 50 11 sept. 18:54 /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea -> ../../../../usr/lib64/chromium-freeworld/libEGL.so There is indeed a need to fix this on both sides. Thanks for your input. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Conflicting build-ids in chromium and chromium-freeworld
Hi, On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: > On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: > > Hi. There is an ongoing problem with conflicting build-ids in chromium > > and chromium-freeworld [1][2]: > > > Error: Transaction test error: > > >file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > > There is no clear idea why it happens, but my assumption is that due to > > the fact of building with the same source code (with similar patches), > > some generated shared libraries are the same which generates conflict(s). The error message could probably be improved. You might want to look at where the /usr/lib/.build-id/xx/ symlinks are pointing at to get a better idea which binaries are identical between the packages. > > The quick look at the algorithm for build-id generation [3] doesn't > > answer my question what exactly is taken into account for their > > generation and more precisely is there is way to add some "fuzz" (having > > different buildroots doesn't help) to distinguish those libraries. The build-id is calculated over all relevant build environment bits (by the linker, not rpm). This includes the debuginfo in the original (not split) ELF file. The debuginfo contains the build paths (which should be different for different NVRs and include the compiler version and flags). This really should prevent identical build-ids whenever something is really build from source. Normally you only get identical build-ids when building the same source code in the same package with the same compiler flags. Identical build-ids between packages are really very rare and are often caused by some binary blob simply being copied between packages (is there a blob in the upstream tar ball that isn't build from source?) or if debuginfo (-g) is missing. > > To wrap up: > > 1. Is there a better way to deal with the aforementioned build-id > > conflicts than disable their generation on one side (with "%global > > _build_id_links none")? > > Instead of disabling entirely, you could tell rpm to put it all into > -debuginfo packages (ie the original debuginfo layout). Which would > still conflict, but fewer people are affected: > > %global _build_id_links alldebug Yes, that is a much better workaround than using none. > > 2. Maybe my assumption about the same generated shared libraries is > > wrong and there is something else what can be done to fix the root problem? > > That's exactly the cause, build-id's are engineered to reproducably > identify identical built objects, regardless of their location. Which > causes conflicts when the house rules of not shipping multiple idental > copies is broken (one might call this a feature). Yes, I would call this a feature :) > Short of unbundling the shared libraries, I guess a reasonable > workaround would be patching them to include some identifier string > based on the containing package name, which would cause them to have > different build_ids. If build from source and building with debuginfo that should already be the case because the build-id is calculated over the original debuginfo which contains the original (pre-debugedit) build paths, which should contain the package nvr in their name. So double check that things are build with -g. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Conflicting build-ids in chromium and chromium-freeworld
On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: Hi. There is an ongoing problem with conflicting build-ids in chromium and chromium-freeworld [1][2]: Error: Transaction test error: file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 There is no clear idea why it happens, but my assumption is that due to the fact of building with the same source code (with similar patches), some generated shared libraries are the same which generates conflict(s). The quick look at the algorithm for build-id generation [3] doesn't answer my question what exactly is taken into account for their generation and more precisely is there is way to add some "fuzz" (having different buildroots doesn't help) to distinguish those libraries. To wrap up: 1. Is there a better way to deal with the aforementioned build-id conflicts than disable their generation on one side (with "%global _build_id_links none")? Instead of disabling entirely, you could tell rpm to put it all into -debuginfo packages (ie the original debuginfo layout). Which would still conflict, but fewer people are affected: %global _build_id_links alldebug 2. Maybe my assumption about the same generated shared libraries is wrong and there is something else what can be done to fix the root problem? That's exactly the cause, build-id's are engineered to reproducably identify identical built objects, regardless of their location. Which causes conflicts when the house rules of not shipping multiple idental copies is broken (one might call this a feature). Short of unbundling the shared libraries, I guess a reasonable workaround would be patching them to include some identifier string based on the containing package name, which would cause them to have different build_ids. - Panu - [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037 [2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743 [3] - https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803 [4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758 Marcin P.S. There are cases where it would be best to have those two packages installed simultaneously [4]. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Conflicting build-ids in chromium and chromium-freeworld
Hi. There is an ongoing problem with conflicting build-ids in chromium and chromium-freeworld [1][2]: > Error: Transaction test error: > file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 There is no clear idea why it happens, but my assumption is that due to the fact of building with the same source code (with similar patches), some generated shared libraries are the same which generates conflict(s). The quick look at the algorithm for build-id generation [3] doesn't answer my question what exactly is taken into account for their generation and more precisely is there is way to add some "fuzz" (having different buildroots doesn't help) to distinguish those libraries. To wrap up: 1. Is there a better way to deal with the aforementioned build-id conflicts than disable their generation on one side (with "%global _build_id_links none")? 2. Maybe my assumption about the same generated shared libraries is wrong and there is something else what can be done to fix the root problem? [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037 [2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743 [3] - https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803 [4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758 Marcin P.S. There are cases where it would be best to have those two packages installed simultaneously [4]. -- https://blog.solidsoft.pl/ - Working code is not enough ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: chromium/ffmpeg fails on aarch64 in F33+
Filed as 1869884. ~tom On Tue, Aug 18, 2020 at 5:38 PM Jeff Law wrote: > On Tue, 2020-08-18 at 17:26 -0400, Tom Callaway wrote: > > I don't know aarch64 assembly, but chromium (or more specifically, the > ffmpeg part of chromium) is failing on aarch64 on F33+ (everywhere else it > is fine): > > > > obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function > `ff_prefetch_aarch64': > > (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against > symbol `ff_prefetch_aarch64' defined in .text section in > obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o > > > > The relevant asm is short and has not seen any change in a while, so I'm > suspicious of the toolchain. > > > > Any help is appreciated so we can get chromium security updates into > F33+. > I would guess that there's either a conditional jump to an undefined label > or to > a label that is too far away. > > Toolchain? Likely. GCC is probably the most appropriate component. > > jeff > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: chromium/ffmpeg fails on aarch64 in F33+
On Tue, 2020-08-18 at 17:26 -0400, Tom Callaway wrote: > I don't know aarch64 assembly, but chromium (or more specifically, the ffmpeg > part of chromium) is failing on aarch64 on F33+ (everywhere else it is fine): > > obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function > `ff_prefetch_aarch64': > (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol > `ff_prefetch_aarch64' defined in .text section in > obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o > > The relevant asm is short and has not seen any change in a while, so I'm > suspicious of the toolchain. > > Any help is appreciated so we can get chromium security updates into F33+. I would guess that there's either a conditional jump to an undefined label or to a label that is too far away. Toolchain? Likely. GCC is probably the most appropriate component. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
chromium/ffmpeg fails on aarch64 in F33+
I don't know aarch64 assembly, but chromium (or more specifically, the ffmpeg part of chromium) is failing on aarch64 on F33+ (everywhere else it is fine): obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function `ff_prefetch_aarch64': (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol `ff_prefetch_aarch64' defined in .text section in obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o The relevant asm is short and has not seen any change in a while, so I'm suspicious of the toolchain. Any help is appreciated so we can get chromium security updates into F33+. Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium failing on aarch64 in rawhide
On Fri, 2020-07-31 at 13:26 -0400, Tom Callaway wrote:
> This one is odd. Chromium is failing on aarch64 in rawhide, on a bit of
> ffmpeg code that has not changed in _years_.
>
> [clear_key_cdm:13/13] g++ -shared -Wl,--fatal-warnings -fPIC
> -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed
> -Wl,-O2 -Wl,--gc-sections -rdynamic -o "./libclearkeycdm.so"
> -Wl,-soname="libclearkeycdm.so" @"./libclearkeycdm.so.rsp"
> FAILED: libclearkeycdm.so
> g++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro
> -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic -o
> "./libclearkeycdm.so" -Wl,-soname="libclearkeycdm.so"
> @"./libclearkeycdm.so.rsp"
> obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function
> `ff_prefetch_aarch64':
> (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol
> `ff_prefetch_aarch64' defined in .text section in
> obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o
> collect2: error: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
> error: Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build)
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build)
> Child return code was: 1
> EXCEPTION: [Error()]
>
> The function it references is defined in libavcodec/aarch64/videodsp.S:
>
> function ff_prefetch_aarch64, export=1
> subsw2, w2, #2
> prfmpldl1strm, [x0]
> prfmpldl1strm, [x0, x1]
> add x0, x0, x1, lsl #1
> b.gtX(ff_prefetch_aarch64)
> ret
> endfunc
>
> Did something change in rawhide that might be breaking this?
Lots has changed ;-) What's weird is this looks like conditional self recursion
and I don't see how we'd be getting an out of range branch. But then again,
it's
not clear what macro magic might be happening to turn that into actual assembler
code and how that might also be interacting with the compiler.
More seriously though, this could be LTO, or the branch tracking bits for
aarch64
or something else entirely.
I'd try a non-LTO build first to see if that helps. The standard way to turn
LTO
off is
%define _lto_cflags %{nil}
Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Chromium failing on aarch64 in rawhide
This one is odd. Chromium is failing on aarch64 in rawhide, on a bit of ffmpeg code that has not changed in _years_. [clear_key_cdm:13/13] g++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic -o "./libclearkeycdm.so" -Wl,-soname="libclearkeycdm.so" @"./libclearkeycdm.so.rsp" FAILED: libclearkeycdm.so g++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic -o "./libclearkeycdm.so" -Wl,-soname="libclearkeycdm.so" @"./libclearkeycdm.so.rsp" obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function `ff_prefetch_aarch64': (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol `ff_prefetch_aarch64' defined in .text section in obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. error: Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build) Child return code was: 1 EXCEPTION: [Error()] The function it references is defined in libavcodec/aarch64/videodsp.S: function ff_prefetch_aarch64, export=1 subsw2, w2, #2 prfmpldl1strm, [x0] prfmpldl1strm, [x0, x1] add x0, x0, x1, lsl #1 b.gtX(ff_prefetch_aarch64) ret endfunc Did something change in rawhide that might be breaking this? Thanks in advance, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
On Mi, 15.04.20 09:33, Florian Weimer (fwei...@redhat.com) wrote: > * Omair Majid: > > > (I was secretly hoping there was a way to bump rlim_cur past > > the current value of rlim_max...) > > Current Fedora seems to set the hard limit to at least 4096 for all > processes. Isn't that enough? See my earlier comments about this in this thread. systemd will nowadays set the hard limit for RLIMIT_NOFILE to 512K for all services, and that'll be inherited down to all sessions. Hence, any program that during its startup phase bumps the RLIMIT_NOFILE soft limit to the hard limit should have no issues with numbers of fds anymore, it may allocate a whipping 512K of them just like that. (But should still take care to reset the soft limit to 1024 again when forking off foreign code.) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
* Omair Majid: > (I was secretly hoping there was a way to bump rlim_cur past > the current value of rlim_max...) Current Fedora seems to set the hard limit to at least 4096 for all processes. Isn't that enough? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
Florian Weimer writes:
> * Omair Majid:
>
>> Florian Weimer writes:
>>
>>> * Jan Kratochvil:
>>>
gold is also limited by 'ulimit -S -n', I had to raise it while building
LLDB
(using -DLLVM_USE_LINKER=gold).
>>>
>>> gold should either do this upon start (like OpenJDK does),
>>
>> Do you have any pointers to source or docs that explain the OpenJDK
>> technique for this?
>
> Uhm, now I have to look. I hope it really does that, I noticed it only
> because it was possible to open more than 1024 files, contrary to what I
> expected based on the system configuration.
>
> The responsible code is os::init_2(), in
> src/hotspot/os/linux/os_linux.cpp:
>
> if (MaxFDLimit) {
> // set the number of file descriptors to max. print out error
> // if getrlimit/setrlimit fails but continue regardless.
> struct rlimit nbr_files;
> int status = getrlimit(RLIMIT_NOFILE, &nbr_files);
> if (status != 0) {
> log_info(os)("os::init_2 getrlimit failed: %s", os::strerror(errno));
> } else {
> nbr_files.rlim_cur = nbr_files.rlim_max;
> status = setrlimit(RLIMIT_NOFILE, &nbr_files);
> if (status != 0) {
> log_info(os)("os::init_2 setrlimit failed: %s", os::strerror(errno));
> }
> }
> }
>
> rlim_max is what is sometimes called the hard limit, rlim_cur the soft
> limit. It is the difference between “ulimit -S -n” and “ulimit -H -n”.
> The quoted code fragment raises the soft limit up to the hard limit,
> which is as far as you can go without additional privileges.
>
> Does this answer your question?
Yes, it does. Thanks.
(I was secretly hoping there was a way to bump rlim_cur past
the current value of rlim_max...)
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
* Omair Majid:
> Florian Weimer writes:
>
>> * Jan Kratochvil:
>>
>>> gold is also limited by 'ulimit -S -n', I had to raise it while building
>>> LLDB
>>> (using -DLLVM_USE_LINKER=gold).
>>
>> gold should either do this upon start (like OpenJDK does),
>
> Do you have any pointers to source or docs that explain the OpenJDK
> technique for this?
Uhm, now I have to look. I hope it really does that, I noticed it only
because it was possible to open more than 1024 files, contrary to what I
expected based on the system configuration.
The responsible code is os::init_2(), in
src/hotspot/os/linux/os_linux.cpp:
if (MaxFDLimit) {
// set the number of file descriptors to max. print out error
// if getrlimit/setrlimit fails but continue regardless.
struct rlimit nbr_files;
int status = getrlimit(RLIMIT_NOFILE, &nbr_files);
if (status != 0) {
log_info(os)("os::init_2 getrlimit failed: %s", os::strerror(errno));
} else {
nbr_files.rlim_cur = nbr_files.rlim_max;
status = setrlimit(RLIMIT_NOFILE, &nbr_files);
if (status != 0) {
log_info(os)("os::init_2 setrlimit failed: %s", os::strerror(errno));
}
}
}
rlim_max is what is sometimes called the hard limit, rlim_cur the soft
limit. It is the difference between “ulimit -S -n” and “ulimit -H -n”.
The quoted code fragment raises the soft limit up to the hard limit,
which is as far as you can go without additional privileges.
Does this answer your question?
There is some risk in doing this, if the JVM uses JNI with some library
that still uses the select system call (with the risk of memory
corruption due to the use of FD_SET/FD_CLR with out-of-range
descriptors), but for the JVM, this is likely the right trade-off.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
Hi, Florian Weimer writes: > * Jan Kratochvil: > >> gold is also limited by 'ulimit -S -n', I had to raise it while building LLDB >> (using -DLLVM_USE_LINKER=gold). > > gold should either do this upon start (like OpenJDK does), Do you have any pointers to source or docs that explain the OpenJDK technique for this? Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
Tom Callaway writes: > Recently, someone filed a bug against chromium, noting that it was > benchmarking notably slower than Google Chrome or chromium-freeworld > (from rpmfusion). I tested locally and confirmed it. They suspected > that Fedora's optflags were to blame, but since chromium doesn't use > them anymore, that wasn't it. chromium-freeworld enables some media > codecs we cannot, but this shouldn't affect javascript benchmark > tests. VAAPI is turned on in both builds, but not in Google Chrome. > > Ultimately, the culprit was in how chromium is built for Fedora. There > are two ways to build chromium: as a giant static binary (which is how > Google Chrome and chromium-freeworld are built) and as a collection of > shared libraries (which is how Fedora's chromium is built). I did a > test build of a static version of Fedora's chromium and the benchmark > performance went up to expected levels. It's worth noting that IMHO, > the performance loss is noticeable, but the browser is still usable. > > So, you might be asking, why does Fedora build in shared mode? There are > two main reasons: > > 1) To enable users to be able to swap out the media components from > Fedora with a "freeworld" version. > > 2) To keep the size down on the chrome-remote-desktop subpackage > (since it can share the "internal libs" from chromium). > > Switching to static mode gives us: > > 1) Fully working krb5 (because it would resolve the symbol clash > caused by the use of chromium's boringssl fork). This bug has been > outstanding for a few years now. Biased of course, but this fix is really attractive to me. (For those who haven't experienced the issue, Kerberized browser login using FEDORAPROJECT.ORG is more likely to crash chromium than log in.) It sounds like from downthread that rpmfusion/freeworld isn't a concern anymore. That I think leaves chrome-remote-desktop, which doesn't seem a huge concern (but correct me if that's not right). So much as it pains me to suggest static linking, that would be my preference. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
Tom Callaway wrote:
> I would also be interested in seeing the patches where you set a specific
> component to be shared while the others were static.
See what I did to v8/BUILD.gn and v8/gni/v8.gni:
https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/f27/f/qtwebengine-everywhere-src-5.10.1-no-sse2.patch#_2647
(and the "shared_library("v8")" section that I added is mostly just copied
from the "v8_component("v8")" section with "v8_component" changed to
"shared_library"), though I am not sure how easily that works for more core
components. (V8 is a bit of a special case.)
Also note that this is a quite old Chromium. The patch was abandoned with
QtWebEngine 5.11. I already had to forward-port the V8 x87 backend to 5.10
(it was removed from Chromium), which is why the patch had become so huge.
Getting it to work with later versions was too much effort, and Fedora has
dropped non-SSE2 x86 support systemwide around that time anyway. So I do not
have a version of this patch for the current Chromium.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
> Peter Robinson wrote: > > People that want the Fedora version of the build, even without the > > extra bits, would get rpmfusion if they happen to have rpmfusion > > enabled for another reason. > > That's exactly why RPM Fusion does NOT Obsolete Fedora packages, but uses > Conflicts or parallel installability instead. If you read the email I was replying to that's what they were proposing and hence why I made the comment. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
Peter Robinson wrote: > People that want the Fedora version of the build, even without the > extra bits, would get rpmfusion if they happen to have rpmfusion > enabled for another reason. That's exactly why RPM Fusion does NOT Obsolete Fedora packages, but uses Conflicts or parallel installability instead. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
* Jan Kratochvil: > On Mon, 13 Apr 2020 18:43:07 +0200, Tom Callaway wrote: >> The linker said: error adding symbols: Malformed archive. Searching leads >> me to translate that error to "too many open files". See: >> https://github.com/OSSystems/meta-browser/issues/194 >> >> Apparently, gold does not have this issue, but I have not tested. > > gold is also limited by 'ulimit -S -n', I had to raise it while building LLDB > (using -DLLVM_USE_LINKER=gold). gold should either do this upon start (like OpenJDK does), or degrade gracefully if running out of descriptors (perhaps resulting in less parallelism, or additional open/close system calls, like databases handle this). Raising ulimit -n is just a kludge. We can't do it globally because it introduces memory corruption in some select-using programs. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
On Mon, 13 Apr 2020 18:43:07 +0200, Tom Callaway wrote: > The linker said: error adding symbols: Malformed archive. Searching leads > me to translate that error to "too many open files". See: > https://github.com/OSSystems/meta-browser/issues/194 > > Apparently, gold does not have this issue, but I have not tested. gold is also limited by 'ulimit -S -n', I had to raise it while building LLDB (using -DLLVM_USE_LINKER=gold). Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
On 13.04.2020 18:58, Michael Catanzaro wrote: > I guess that solves the problem, doesn't it? There is zero reason for > Fedora to be doing a component build anymore if it's no longer of > benefit to rpmfusion. Yes? I think so. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
On Mon, Apr 13, 2020 at 6:33 pm, Vitaly Zaitsev via devel wrote: Due to major synchronization problems between Fedora and RPM Fusion repositories. Fedora updates chromium -> RPM fusion need need 1-3 days to push this update to rpmfusion-free-updates and users complains about broken updates. Everyone is tired of this. That's why chromium-freeworld package was created. I guess that solves the problem, doesn't it? There is zero reason for Fedora to be doing a component build anymore if it's no longer of benefit to rpmfusion. Yes? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
The linker said: error adding symbols: Malformed archive. Searching leads me to translate that error to "too many open files". See: https://github.com/OSSystems/meta-browser/issues/194 Apparently, gold does not have this issue, but I have not tested. Tom On Mon, Apr 13, 2020 at 12:05 PM Lennart Poettering wrote: > On Mo, 13.04.20 09:56, Tom Callaway (tcall...@redhat.com) wrote: > > > C) Chromium's build process gets...angrier. Still doable, but you have to > > do things like set ulimit -n 4096. (Fun fact: the man page section for > > ulimit says that for -n, "most systems do not allow this value to be > set". > > Guess modern Linux isn't most systems.) > > Hmm what precisely fails? > > Note that in systemd we took the liberty to bump RLIMIT_NOFILE's hard > limit to 512K a while back, which one can effectively understand as > "there's no limit on fds anymore" (this was on suggestion of some > kernel folks, because fds are these days tracked like memory and hence > are accounted like that too and are not as expensive as hey used to > be). We would have liked to bump the matching soft limit too (i.e. the > one you tweak with ulimit -n), but that's something what we can't do > without breaking compability a litte bit too agressively: fds above > 1023 are not compatible with select(), and plenty software still uses > select() (they really shouldn't, it's a terrible interface), and it's > a silent failure. > > Long story short: If there are programs that are likely to deal with > large numbers of fds (like in your case, the linker I presume?) they > should probably just bump the soft limit to the hard limit early on in > their C code, and thus just get as many fds they want. Raising the > soft limit up to the hard limit is an unprivileged operation and can > be done by regular users. Programs that do that should reset the soft > limit back to 1K before forking off foreign programs again though, > again for compatibility with any such programs that use select(). > > Very short version: consider filing a bug against your linker tool (or > whichever other tool needed the ulimit -n above), and ask them to set > RLIMIT_NOFILE's soft value to the hard value. And then they will just > work without any manual limit bumping for regular people on modern > distros. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
On 13.04.2020 18:01, Tom Callaway wrote: > What I don't understand is _why_ RPM Fusion made that change. Not saying > it is without merit, just that I don't understand why a total rebuild is > preferred. Due to major synchronization problems between Fedora and RPM Fusion repositories. Fedora updates chromium -> RPM fusion need need 1-3 days to push this update to rpmfusion-free-updates and users complains about broken updates. Everyone is tired of this. That's why chromium-freeworld package was created. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
Le 13/04/2020 à 16:27, Peter Robinson a écrit : People that want the Fedora version of the build, even without the extra bits, would get rpmfusion if they happen to have rpmfusion enabled for another reason. Maybe a special repository only for chromium? I mean, chromium is important enough for an exception like that. Or, distributing two different .repo files, one of them with: exclude=chromium That could do the trick while keeping user's freedom. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
On Mo, 13.04.20 09:56, Tom Callaway (tcall...@redhat.com) wrote: > C) Chromium's build process gets...angrier. Still doable, but you have to > do things like set ulimit -n 4096. (Fun fact: the man page section for > ulimit says that for -n, "most systems do not allow this value to be set". > Guess modern Linux isn't most systems.) Hmm what precisely fails? Note that in systemd we took the liberty to bump RLIMIT_NOFILE's hard limit to 512K a while back, which one can effectively understand as "there's no limit on fds anymore" (this was on suggestion of some kernel folks, because fds are these days tracked like memory and hence are accounted like that too and are not as expensive as hey used to be). We would have liked to bump the matching soft limit too (i.e. the one you tweak with ulimit -n), but that's something what we can't do without breaking compability a litte bit too agressively: fds above 1023 are not compatible with select(), and plenty software still uses select() (they really shouldn't, it's a terrible interface), and it's a silent failure. Long story short: If there are programs that are likely to deal with large numbers of fds (like in your case, the linker I presume?) they should probably just bump the soft limit to the hard limit early on in their C code, and thus just get as many fds they want. Raising the soft limit up to the hard limit is an unprivileged operation and can be done by regular users. Programs that do that should reset the soft limit back to 1K before forking off foreign programs again though, again for compatibility with any such programs that use select(). Very short version: consider filing a bug against your linker tool (or whichever other tool needed the ulimit -n above), and ask them to set RLIMIT_NOFILE's soft value to the hard value. And then they will just work without any manual limit bumping for regular people on modern distros. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
What I don't understand is _why_ RPM Fusion made that change. Not saying it is without merit, just that I don't understand why a total rebuild is preferred. I would also be interested in seeing the patches where you set a specific component to be shared while the others were static. Thanks, Tom On Mon, Apr 13, 2020 at 11:54 AM Kevin Kofler wrote: > Tom Callaway wrote: > > So, you might be asking, why does Fedora build in shared mode? There are > > two main reasons: > > 1) To enable users to be able to swap out the media components from > Fedora > > with a "freeworld" version. > > That reason is obsolete. RPM Fusion replaced chromium-libs-media-freeworld > with a full chromium-freeworld rebuild. > > > 2) To keep the size down on the chrome-remote-desktop subpackage (since > it > > can share the "internal libs" from chromium). > > That sounds valid, but is it worth the performance issues? > > I would recommend abandoning the component mode build. QtWebEngine has > never > been built that way. > > By the way, it is also possible to hack up the GN setup so that only some > specific component is built as a component (which could solve point 1 if > it > were still needed). For QtWebEngine, I used to do that with V8 on 32-bit > x86 > when I still had an x87 build and an SSE2 build of it. But that of course > requires patching. And RPM Fusion no longer tries to replace the media > component anyway (making point 1 moot). > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Chromium Dilemma
Tom Callaway wrote: > So, you might be asking, why does Fedora build in shared mode? There are > two main reasons: > 1) To enable users to be able to swap out the media components from Fedora > with a "freeworld" version. That reason is obsolete. RPM Fusion replaced chromium-libs-media-freeworld with a full chromium-freeworld rebuild. > 2) To keep the size down on the chrome-remote-desktop subpackage (since it > can share the "internal libs" from chromium). That sounds valid, but is it worth the performance issues? I would recommend abandoning the component mode build. QtWebEngine has never been built that way. By the way, it is also possible to hack up the GN setup so that only some specific component is built as a component (which could solve point 1 if it were still needed). For QtWebEngine, I used to do that with V8 on 32-bit x86 when I still had an x87 build and an SSE2 build of it. But that of course requires patching. And RPM Fusion no longer tries to replace the media component anyway (making point 1 moot). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
