-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 23:11 -0600, Jeff Law wrote:
> On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote:
> > On 04/06/20 16:30 -0400, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/CompilerPolicy
> > [snip]
> > > ==
On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote:
> On 04/06/20 16:30 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CompilerPolicy
> [snip]
> > == Documentation ==
> > Several years ago Red Hat's tools team championed for Fedora policy to
> > strongly
> > discourage
On Fri, 2020-06-05 at 16:47 -0500, Steven Munroe wrote:
> Jeff Law wrote:
> > I'd respectfully disagree. There are certain features that GCC supports
> > that Clang does not
> > and vice-versa. But broadly they are comparable. What this means is some
> > projects that are
> > using bleeding edge
On Fri, Jun 5, 2020 at 8:33 PM Chris Murphy wrote:
>
> On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb wrote:
> >
> > >> # swapon
> > >> NAME TYPE SIZE USED PRIO
> > >> /dev/sda3 partition 16G 1.9G-2
> > >> /zram0partition 4G 4G 32767
> > >>
> > >> This looks like I'm using
On 6/5/20 7:33 PM, Chris Murphy wrote:
On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb wrote:
All three of those listed provide competing configurations for swap on
zram. Just to make a fine point, zram is generic, it is not swap
specific. It's just a compressed ram disk. Zswap is a different thing,
https://fedorapeople.org/groups/389ds/ci/nightly/2020/06/06/report-389-ds-base-1.4.4.3-20200605git05e3407.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb wrote:
>
> On 6/5/20 6:59 PM, Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb wrote:
> >>
> >> I installed the zram package and noticed the systemd-swap package, so
> >> installed that also.
> >
> > There are conflicting
On 6/5/20 6:59 PM, Chris Murphy wrote:
On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb wrote:
I installed the zram package and noticed the systemd-swap package, so
installed that also.
There are conflicting implementations:
anaconda package provides zram.service
zram package provides
On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb wrote:
>
> I installed the zram package and noticed the systemd-swap package, so
> installed that also.
There are conflicting implementations:
anaconda package provides zram.service
zram package provides zram-swap.service
systemd-swap package provides
https://bugzilla.redhat.com/show_bug.cgi?id=1837975
--- Comment #15 from msidd...@redhat.com ---
The fixes are now published in Perl versions 5.28.3 and 5.30.3.
https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod
https://bugzilla.redhat.com/show_bug.cgi?id=1837988
--- Comment #17 from msidd...@redhat.com ---
The fixes are now published in Perl versions 5.28.3 and 5.30.3.
https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod
https://bugzilla.redhat.com/show_bug.cgi?id=1838000
--- Comment #14 from msidd...@redhat.com ---
The fixes are now published in Perl versions 5.28.3 and 5.30.3.
https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod
https://bugzilla.redhat.com/show_bug.cgi?id=1838000
msidd...@redhat.com changed:
What|Removed |Added
Group|security, qe_staff |
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1844664
--- Comment #1 from msidd...@redhat.com ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug. This will ensure that all
https://bugzilla.redhat.com/show_bug.cgi?id=1844664
Bug ID: 1844664
Summary: CVE-2020-12723 perl: corruption of intermediate
language state of compiled regular expression due to
recursive S_study_chunk() calls leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1838000
msidd...@redhat.com changed:
What|Removed |Added
Depends On||1844664
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1844664
msidd...@redhat.com changed:
What|Removed |Added
Blocks||1838000 (CVE-2020-12723)
https://bugzilla.redhat.com/show_bug.cgi?id=1838000
--- Comment #13 from msidd...@redhat.com ---
Created perl tracking bugs for this issue:
Affects: fedora-all [bug 1844664]
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1844663
Bug ID: 1844663
Summary: CVE-2020-10878 perl: corruption of intermediate
language state of compiled regular expression due to
integer overflow leads to DoS [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1837988
msidd...@redhat.com changed:
What|Removed |Added
Depends On||1844663
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1844663
msidd...@redhat.com changed:
What|Removed |Added
Blocks||1837988 (CVE-2020-10878)
https://bugzilla.redhat.com/show_bug.cgi?id=1837988
--- Comment #16 from msidd...@redhat.com ---
Created perl tracking bugs for this issue:
Affects: fedora-all [bug 1844663]
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1837988
msidd...@redhat.com changed:
What|Removed |Added
Group|security, qe_staff |
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1844663
--- Comment #1 from msidd...@redhat.com ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug. This will ensure that all
https://bugzilla.redhat.com/show_bug.cgi?id=1844662
msidd...@redhat.com changed:
What|Removed |Added
Blocks||1837975 (CVE-2020-10543)
https://bugzilla.redhat.com/show_bug.cgi?id=1837975
msidd...@redhat.com changed:
What|Removed |Added
Depends On||1844662
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1837975
--- Comment #14 from msidd...@redhat.com ---
Created perl tracking bugs for this issue:
Affects: fedora-all [bug 1844662]
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1844662
Bug ID: 1844662
Summary: CVE-2020-10543 perl: heap-based buffer overflow in
regular expression compiler leads to DoS [fedora-all]
Product: Fedora
Version: 32
Status:
https://bugzilla.redhat.com/show_bug.cgi?id=1844662
--- Comment #1 from msidd...@redhat.com ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug. This will ensure that all
https://bugzilla.redhat.com/show_bug.cgi?id=1837975
msidd...@redhat.com changed:
What|Removed |Added
Group|security, qe_staff |
CC|
Steven Munroe wrote:
> And while you allow that some packages have good reasons to stick with
> GCC. Several others on this list have demanded that clang/LLVM replace
> GCC as the default compiler.
Just to clear up any potential misunderstandings: I do NOT support replacing
GCC with Clang/LLVM
Frantisek Zatloukal wrote:
> I don't think we should force Fedora Contributors (Packagers) to
> change/fix their packages to compile with GCC if upstream decides,
> supports and tests GCC.
While that sentence parses, it fails the semantic analysis in my brain. ;-)
I think that either the second
I installed the zram package and noticed the systemd-swap package, so
installed that also. I adjusted the zram setting to 4G and reduced
zswap a bit. I have no idea what that is doing, it doesn't seem to
affect anything I can measure. The overall improvement in
responsiveness is very nice.
Chris Murphy wrote:
> So yes it's well suited for these cases and the proposal does include
> them. If they wish to be left out, that's up to those working groups.
> It's possible to make sure /etc/systemd/zram-generator is not present.
Also, why does this have to be a systemd generator? As a
Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't
have anything urgent new this week, we have the CoreOS Test Day and
the onboarding call coming up, but I don't think those need a meeting :)
If you're aware of anything important we have to discuss this week,
please do reply to
Igor Raits wrote:
> The change says it will use 50% of user’s RAM size, but not more than
> 4G.
But if the machine has only, say, 4 GiB of RAM, then the amount of extra RAM
you get that way might not be sufficient to avoid OOM.
> On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote:
>> Also
On Friday, June 5, 2020 4:32:55 PM MST Przemek Klosowski via devel wrote:
> On 6/4/20 1:36 AM, John M. Harris Jr wrote:
>
> > On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote:
> >
> >> UEFI Secure Boot doesn't prevent you from gaining access to firmware
> >> setup. It can cause some
On 6/4/20 1:36 AM, John M. Harris Jr wrote:
On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote:
UEFI Secure Boot doesn't prevent you from gaining access to firmware
setup. It can cause some options in firmware setup to become
unavailable, e.g. compatibility support modules for
This laptop with 8GiB RAM is running two VMs at the same time: Windows
10 and Fedora Workstation 32. The host is Fedora Workstation 32. And
there is only swap-on-zram sized to 50% RAM. At this compression
ratio, it wouldn't ever end up using more than 25% RAM. I don't expect
to hold a compression
Jeff Law wrote:
> I'd respectfully disagree. There are certain features that GCC supports that
> Clang does not
> and vice-versa. But broadly they are comparable. What this means is some
> projects that are
> using bleeding edge features may have a hard need for one toolchain or the
> other.
On Fri, 2020-06-05 at 21:49 +0200, Jakub Jelinek wrote:
> On Fri, Jun 05, 2020 at 01:36:37PM -0600, Jeff Law wrote:
> > > On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote:
> > > ...
> > >
> > > Sadly some upstreams insist on clang just because they like it more,
> > > without any technical
On 6/5/20 2:14 PM, Zbigniew Jędrzejewski-Szmek wrote:
This has been bothering me for a while, it occurs quite often for
certain posters to the list, and since Jeff's replies reproduce this
issue, let me ask:
Why is the threading broken with Jeff's replies to this thread?
Looking at the headers,
Daniel Mach wrote:
> This is nothing that can be fixed in DNF directly.
> DNF passes packages to libsolv to resolve the transaction and it can
> only cherry-pick packages for the transaction or set transaction flags.
Yes, I also think that this needs to be fixed at the libsolv level.
> If you
Igor Raits wrote:
> On Fri, 2020-06-05 at 08:38 +0200, Kevin Kofler wrote:
>> The correct solution is to actually fix DNF. It MUST NOT take
>> Obsoletes from
>> outdated versions of packages (i.e., when there is a newer version in
>> the
>> repository which removes the Obsoletes) into account.
>
On Fri, 2020-06-05 at 09:59 +0100, Jonathan Wakely wrote:
> On 05/06/20 10:23 +0200, Tomáš Popela wrote:
> > On Fri, Jun 5, 2020 at 9:56 AM Kevin Kofler
> > wrote:
> >
> > > I am opposed to this change. Chromium and Firefox build fine with GCC. I
> > > think that a distribution should be built
On Friday, June 5, 2020 5:42:36 AM EDT Vít Ondruch wrote:
> Dne 05. 06. 20 v 9:52 Kevin Kofler napsal(a):
>
> > Ben Cotton wrote:
> >
> >> == Summary ==
> >> Fedora has historically forced packages to build with GCC unless the
> >> upstream project for the package only supported Clang/LLVM.
On Fri, Jun 05, 2020 at 03:03:18PM -0600, Jeff Law wrote:
> Clang/LLVM and GCC are ABI compatible (with the known exception of the
> alignment
> issue for atomics) and one should be able to mix and match libraries compiled
> by
> one with code compiled by the other just fine.
They are known not
This has been bothering me for a while, it occurs quite often for
certain posters to the list, and since Jeff's replies reproduce this
issue, let me ask:
Why is the threading broken with Jeff's replies to this thread?
Looking at the headers, there is no In-reply-to: header.
Is this caused by the
On Fri, Jun 5, 2020 at 1:58 PM Jonathan Wakely
wrote:
> boost-1.73.0-4.fc33 is building now:
>
> Building boost-1.73.0-4.fc33 for rawhide
> Created task: 45462220
> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=45462220
>
> I've also pushed one extra fix to freecad (just adding
On Fri, Jun 5, 2020, 4:15 PM Neal Gompa wrote:
> On Fri, Jun 5, 2020 at 3:50 PM Simo Sorce wrote:
> >
> > On Fri, 2020-06-05 at 11:50 -0400, Josh Boyer wrote:
> > > On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa wrote:
> > > > On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
> > > > wrote:
Hi Jeff,
On Fri, 2020-06-05 at 10:07 -0600, Jeff Law wrote:
> On Fri, 2020-06-05 at 15:56 +, devel-requ...@lists.fedoraproject.org
> wrote:
> > One issue I am concerned about here is debuginfo quality. GCC produced
> > pretty bad debuginfo with LTO in older versions. The EarlyDebug work
> >
On Fri, 2020-06-05 at 15:04 +0200, Mark Wielaard wrote:
> On Fri, 2020-06-05 at 11:19 +0200, Jakub Jelinek wrote:
> > On Fri, Jun 05, 2020 at 09:52:09AM +0200, Kevin Kofler wrote:
> > > I do not see why we should allow yet another special case for Firefox,
> > > nor
> > > why we should let
On Fri, 2020-06-05 at 19:31 +0200, Florian Weimer wrote:
> * Ben Cotton:
>
> > https://fedoraproject.org/wiki/Changes/CompilerPolicy
> >
> > == Summary ==
> > Fedora has historically forced packages to build with GCC unless the
> > upstream project for the package only supported Clang/LLVM.
On Fri, 2020-06-05 at 21:51 +0200, Igor Raits wrote:
> On Fri, 2020-06-05 at 13:36 -0600, Jeff Law wrote:
> > > On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote:
> > > ...
> > >
> > > Sadly some upstreams insist on clang just because they like it
> > > more,
> > > without any technical reason.
On Fri, 2020-06-05 at 22:22 +0200, Igor Raits wrote:
> On Fri, 2020-06-05 at 14:16 -0600, Jeff Law wrote:
> > On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote:
> > > Just curious, how is it done in RHEL? Just some kind of CI that
> > > analyses all builds or?
> > So we have a step that sits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 14:16 -0600, Jeff Law wrote:
> On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote:
> >
> > Just curious, how is it done in RHEL? Just some kind of CI that
> > analyses all builds or?
> So we have a step that sits between the
On Fri, 2020-06-05 at 16:09 -0400, Simo Sorce wrote:
> On Fri, 2020-06-05 at 13:58 -0600, Jeff Law wrote:
> > On Fri, 2020-06-05 at 21:18 +0200, Fabio Valentini wrote:
> > > On Fri, Jun 5, 2020 at 9:11 PM Jeff Law wrote:
> > > > Yes. I thought we bumped up that bug in the database so that it'd
On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote:
>
> Just curious, how is it done in RHEL? Just some kind of CI that
> analyses all builds or?
So we have a step that sits between the build phase and when the resultant
packages land in the distro which runs annocheck to validate options used,
On Fri, Jun 5, 2020 at 3:50 PM Simo Sorce wrote:
>
> On Fri, 2020-06-05 at 11:50 -0400, Josh Boyer wrote:
> > On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa wrote:
> > > On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
> > > wrote:
> > > > On 05.06.2020 09:52, Kevin Kofler wrote:
> > > > > I
On Fri, Jun 5, 2020 at 1:44 PM John M. Harris Jr wrote:
>
> How in the world would I end up with 9G of memory? That's not how this tech
> works, at all. Compression doesn't magically mean you get 2x the amount of
> memory as you reserve for it. Compression rates even for plaintext aren't
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 12:58 -0700, John M. Harris Jr wrote:
> On Friday, June 5, 2020 12:39:05 PM MST Igor Raits wrote:
> > On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote:
> >
> > > On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy
On Fri, 2020-06-05 at 13:58 -0600, Jeff Law wrote:
> On Fri, 2020-06-05 at 21:18 +0200, Fabio Valentini wrote:
> > On Fri, Jun 5, 2020 at 9:11 PM Jeff Law wrote:
> > > Yes. I thought we bumped up that bug in the database so that it'd get
> > > some
> > > attention in the gcc-10 cycle. But I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 13:53 -0600, Jeff Law wrote:
> > On 05/06/20 10:26 +0200, Igor Raits wrote:
> > ...
> > > Well, upstreams are not necessarily enabling many security
> > > features
> > > or
> > > optimizations. So you are effectively saying
On Fri, Jun 5, 2020 at 1:38 PM Igor Raits
wrote:
> On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
>I'm
> > writing this
> > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where
> > giving half of
> > my RAM to zram would kill my system's performance, if not quickly
> >
Hi,
On 6/5/20 9:43 PM, John M. Harris Jr wrote:
On Friday, June 5, 2020 12:38:01 PM MST Igor Raits wrote:
On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <
On Fri, 2020-06-05 at 21:18 +0200, Fabio Valentini wrote:
> On Fri, Jun 5, 2020 at 9:11 PM Jeff Law wrote:
> > Yes. I thought we bumped up that bug in the database so that it'd get some
> > attention in the gcc-10 cycle. But I couldn't follow it myself, so I don't
> > know
> > what happened.
>
On Friday, June 5, 2020 12:39:05 PM MST Igor Raits wrote:
> On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote:
>
> > On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote:
> >
> > > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr <
> > > joh...@splentity.com>
> > > wrote:
> > >
>
> On 05/06/20 10:26 +0200, Igor Raits wrote:
> ...
> > Well, upstreams are not necessarily enabling many security features
> > or
> > optimizations. So you are effectively saying "upstream knows better"
> > where I would have to disagree with you.
>
> Yes, this is a very good point.
>
> Many of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 13:36 -0600, Jeff Law wrote:
> > On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote:
> > ...
> >
> > Sadly some upstreams insist on clang just because they like it
> > more,
> > without any technical reason. The question that
Igor Raits wrote on Fri, Jun 05, 2020:
> zramctl shows ALGORITHM
>
> NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
> /dev/zram0 lzo-rle 11.7G 4K 74B 12K 8 [SWAP]
>
> So it is lzo-rle by default, but it should be possible to override this
> algorithm. There is
On Fri, 2020-06-05 at 11:50 -0400, Josh Boyer wrote:
> On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa wrote:
> > On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
> > wrote:
> > > On 05.06.2020 09:52, Kevin Kofler wrote:
> > > > I am opposed to this change. Chromium and Firefox build fine with
On Fri, Jun 05, 2020 at 01:36:37PM -0600, Jeff Law wrote:
> > On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote:
> > ...
> >
> > Sadly some upstreams insist on clang just because they like it more,
> > without any technical reason. The question that comes to my mind:
> > Should we still try to
OLD: Fedora-Rawhide-20200604.n.0
NEW: Fedora-Rawhide-20200605.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 11
Dropped packages:1
Upgraded packages: 141
Downgraded packages: 1
Size of added packages: 6.35 MiB
Size of dropped packages
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Fri, 2020-06-05 at 09:52 +0200, Kevin Kofler wrote:
> ...
>
> Since I was not sure if clang is supported by Red Hat Toolchain team in
> the same way as GCC, I've asked this in my reply. If they are supported
> in the same manner
On Friday, June 5, 2020 12:38:01 PM MST Igor Raits wrote:
> On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
>
> > On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
> >
> > > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <
> > > joh...@splentity.com>
> > > wrote:
> > >
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote:
> On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr <
> > joh...@splentity.com>
> > wrote:
> > >
> > >
> > > On Friday, June
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
> On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <
> > joh...@splentity.com>
> > wrote:
> > >
> > >
> > > On Friday, June
> On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote:
> ...
>
> Sadly some upstreams insist on clang just because they like it more,
> without any technical reason. The question that comes to my mind:
> Should we still try to convince upstreams to use GCC in such cases or
> not?
It happens
On 6/5/20 12:18 PM, John M. Harris Jr wrote:
Well, that's for the GNOME stuff. This is a system-wide change proposal, is it
not? Additionally, you could still be meeting that requirement here, as a new
install with the same options selected, that is, to have a swap partition,
would disable the
On Fri, Jun 5, 2020 at 1:18 PM John M. Harris Jr wrote:
>
> On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr
> > wrote:
> > >
> > >
> > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
> > >
> > > > On Fri, Jun 5, 2020
On 6/5/20 5:27 AM, Neal Gompa wrote:
>> Note that having stuff mix compilers is also a bad idea because LTO is
>> compatible across the two compilers. If you want to use LTO, you need
>> to use the same compiler across the chain, or stuff will break.
>>
> Yay thinkos... I mean that LTO is *not*
Fabio Valentini wrote on Fri, Jun 05, 2020:
> Sorry for being off-topic, but can you (Jeff) please not respond to
> the mailing list digest and amend the Subject line manually?
> I think it screws up the In-Reply-To (?) header in emails, so every
> new email from you creates a new thread (for
https://bugzilla.redhat.com/show_bug.cgi?id=1844622
Bug ID: 1844622
Summary: perl-DBD-Pg-3.12.3 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-DBD-Pg
Keywords: FutureFeature, Triaged
On Fri, Jun 5, 2020 at 12:09 PM John M. Harris Jr wrote:
> > Most laptops today have UEFI Secure Boot enabled by default and
> > therefore hibernation isn't possible. And even when the laptop doesn't
> > have Secure Boot enabled, there's a forest of bugs. It works for some
> > people and not
On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote:
> On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr
> wrote:
> >
> >
> > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote:
>
>
>
> > > In discussions with both cloud and server folks, their use cases often
> > > do not even
On Fri, Jun 5, 2020 at 9:11 PM Jeff Law wrote:
> Yes. I thought we bumped up that bug in the database so that it'd get some
> attention in the gcc-10 cycle. But I couldn't follow it myself, so I don't
> know
> what happened.
Sorry for being off-topic, but can you (Jeff) please not respond to
On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
> On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr
> wrote:
> >
> >
> > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
> >
> > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro
> > > wrote:
> > >
> > > >
> > > >
> > > >
On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr wrote:
>
> On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote:
> > In discussions with both cloud and server folks, their use cases often
> > do not even create disk-based swap at all. A small swap-on-zram
> > provides all the benefits of
On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr wrote:
>
> On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro
> > wrote:
> > >
> > >
> > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
> > > wrote:
> > >
> > > > That is the plan,
On Fri, 2020-06-05 at 20:51 +0200, Florian Weimer wrote:
> * Jeff Law:
>
> > As we both know, GCC has had ABI bugs as well. Both compilers strive
> > to be ABI compatible with each other and we should continue to work
> > together to find and address such issues. SImilarly both compilers
> >
On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote:
> On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr
> wrote:
> >
> >
> > On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote:
>
>
>
> > > Also -1 to adding something to the core system that is written in a
> > > language for
On Fri, Jun 5, 2020 at 12:19 PM John M. Harris Jr wrote:
>
> > The *only* case where Secure Boot must be disabled for the proper
> > functioning of a PC today is if you use the NVIDIA proprietary
> > drivers, because nobody is helping RPM Fusion set up a mechanism to
> > sign their driver and
On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
> On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro
> wrote:
> >
> >
> > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
> > wrote:
> >
> > > That is the plan, otherwise the swap-on-zram device probably never
> > > gets used. And then its
On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr wrote:
>
> On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote:
> > Also -1 to adding something to the core system that is written in a language
> > for which we do not even have dynamic linking support. Or even real
> > static linking
On Fri, Jun 5, 2020 at 7:09 AM Peter Robinson wrote:
>
> > On 05.06.2020 12:50, Igor Raits wrote:
> > > It does not work in some cases even today anyway.
> >
> > Okay, then the second point - zram will will cause a huge memory
> > fragmentation and significantly decrease overall performance.
>
>
On 05/06/20 17:59 +0100, Jonathan Wakely wrote:
On 05/06/20 17:42 +0100, Jonathan Wakely wrote:
On 05/06/20 09:00 -0500, Richard Shaw wrote:
Next problem...
/usr/include/boost/geometry/index/detail/rtree/node/variant_visitor.hpp:51:25:
error: no matching function for call to
* Jeff Law:
> As we both know, GCC has had ABI bugs as well. Both compilers strive
> to be ABI compatible with each other and we should continue to work
> together to find and address such issues. SImilarly both compilers
> are going to have codegen issues, or rejects-valid-code bugs.
>
On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro wrote:
>
> On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
> wrote:
> > That is the plan, otherwise the swap-on-zram device probably never
> > gets used. And then its overhead, which is small but not zero, is just
> > a waste.
>
> I thought the plan
On 05/06/20 20:30 +0200, Igor Raits wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 13:25 -0400, Robert Marcano via devel wrote:
On 6/5/20 12:31 PM, Jeff Law wrote:
> On Fri, 2020-06-05 at 16:23 +,
> devel-requ...@lists.fedoraproject.org wrote:
> > Date: Fri, 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 13:25 -0400, Robert Marcano via devel wrote:
> On 6/5/20 12:31 PM, Jeff Law wrote:
> > On Fri, 2020-06-05 at 16:23 +,
> > devel-requ...@lists.fedoraproject.org wrote:
> > > Date: Fri, 5 Jun 2020 11:15:39 -0500
> > > From:
1 - 100 of 250 matches
Mail list logo
