Do we have contacts among the Chromium developers? I would appreciate
if someone could give this thread a nudge and bring it to the attention
of the right people.
Reducing dependencies on glibc internals in
sandbox/linux/services/namespace_sandbox.cc, ForkWithFlags
<ht
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 Chromiu
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 th
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
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
t
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 Obenou
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
> 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.fe
> 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
> 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" eit
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? Mayb
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
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,
plea
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 updat
r 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 d
usion 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
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)
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 b
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
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'
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
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-
>
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 Chro
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
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.
Mi
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
> follow
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
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 leas
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
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 inform
* 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
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 se
* 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 retr
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 retr
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
* 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
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
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
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 Janu
fstatat 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
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
* 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 Downl
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 fsta
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 |
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.3
* 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__) || \
> (def
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) && def
* 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.
libc 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,
>
> > 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
he 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
* 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 a
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
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.
>
> Ke
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 -- de
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
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 ru
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.o
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
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) a
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
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
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,
M
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
>>
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 dependen
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 depe
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 report
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-qtweb
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
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
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 buil
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
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-freeworl
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
> &g
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:
> > &
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
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 fil
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
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/videod
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 trunca
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 -W
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
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
* 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
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),
>>
>>
* 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 d
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
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, b
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 wor
> 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 i
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 installabilit
* 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
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
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)
__
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
upda
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
positories.
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 Zai
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
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
gt; 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 "int
1 - 100 of 218 matches
Mail list logo
