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?
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?
On Tue, Mar 1 2022 at 07:21:14 PM -0500, Demi Marie Obenour demiobenour@gmail.com 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
On 3/1/22 19:42, Michael Catanzaro wrote:
On Tue, Mar 1 2022 at 07:21:14 PM -0500, Demi Marie Obenour demiobenour@gmail.com 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.
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
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
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.
On Wed, Mar 2, 2022 at 5:06 AM Demi Marie Obenour demiobenour@gmail.com 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.
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
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.
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-freewor...
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.
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-freewor...
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.
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.
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.
On Wed, Mar 2, 2022 at 6:44 AM Demi Marie Obenour demiobenour@gmail.com 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.
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
On Wed, Mar 2, 2022 at 9:19 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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.
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.
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
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.
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
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
On Wed, Mar 02, 2022 at 04:07:43PM -0000, 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.
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?
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
-
Adam Williamson -
Demi Marie Obenour -
Gary Buhrmaster -
Jonathan Schleifer -
Kevin Kofler -
Leigh Scott -
Michael Catanzaro -
Neal Gompa -
Richard W.M. Jones -
Tom Callaway -
Tom Seewald -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek