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, but since chromium doesn't
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
> 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
updates. Eve
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
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 upda
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
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
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
On 4/13/20 6:56 AM, Tom Callaway wrote:
I did a test build of a static version of Fedora's chromium and the
benchmark performance went up to expected levels.
This sounds similar to a discussion on this list in November, regarding
python performance. I think developers settled on the use of
> Honestly, degraded performance is an expected result of doing component
> build, so I would say that's just not a bug at all, it's just how
> Chromium works. Our hand is forced here by upstream's strange and
> unusual packaging decisions. Other distros do it this way too.
>
> But you say the diff
https://browserbench.org/Speedometer2.0/ is the benchmark in the bug.
Tom
On Mon, Apr 13, 2020 at 10:34 AM Benson Muite
wrote:
>
>
> On Mon, Apr 13, 2020, at 5:21 PM, Michael Catanzaro wrote:
> > Honestly, degraded performance is an expected result of doing component
> > build, so I would say t
On Mon, Apr 13, 2020, at 5:21 PM, Michael Catanzaro wrote:
> Honestly, degraded performance is an expected result of doing component
> build, so I would say that's just not a bug at all, it's just how
> Chromium works. Our hand is forced here by upstream's strange and
> unusual packaging decis
Honestly, degraded performance is an expected result of doing component
build, so I would say that's just not a bug at all, it's just how
Chromium works. Our hand is forced here by upstream's strange and
unusual packaging decisions. Other distros do it this way too.
But you say the difference
Hi Fedorans,
Here's the situation:
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 d
25 matches
Mail list logo
