On 6/5/20 11:43 PM, John M. Harris Jr wrote:
Completely agreed, going about it this way would also address most of my
concerns with this change, as it would mean it's easy for people like myself
to opt out.
If you don't want it, then disable the generator or uninstall it. I
don't understand w
On Friday, June 5, 2020 5:19:55 PM MST Kevin Kofler wrote:
> 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 p
-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]
> > > == Documentatio
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 t
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 all
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,
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 implementation
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 zram-swap.s
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
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 as
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 user
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 t
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 -1
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 o
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 presenti
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 r
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. And
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 reas
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 wan
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 w
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. This
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 a
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 t
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
> > d
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 random
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. This
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 betw
-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 b
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 ge
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, C
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 a
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
> normall
-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 wr
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 cou
-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 "ups
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
> > caus
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 <
joh...@splenti
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 G
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 c
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 (maintain
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 (choos
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 zr
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 a
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* com
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 clien
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 othe
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 cr
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
t
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 i
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, othe
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
> > are
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 w
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 load
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 o
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 su
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.
>
> H
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
'apply_visitor(boo
* 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.
> Ultimate
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 w
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: S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 11:08 -0700, John M. Harris Jr wrote:
> On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
> > wrote:
> >
> > >
> > >
> > > On 04.06.2020 22:30, Ben Cotton
On Friday, June 5, 2020 11:12:10 AM MST Neal Gompa wrote:
> On Fri, Jun 5, 2020 at 2:09 PM John M. Harris Jr
> wrote:
> >
> >
> > On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
> >
> > > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
> > > wrote:
> > >
> > >
> > >
> > > >
>
On Fri, Jun 5, 2020 at 2:09 PM John M. Harris Jr wrote:
>
> On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
> > wrote:
> >
> > >
> > >
> > > On 04.06.2020 22:30, Ben Cotton wrote:
> > >
> > > > Swap is useful, except when it'
On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
> On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
> wrote:
>
> >
> >
> > On 04.06.2020 22:30, Ben Cotton wrote:
> >
> > > Swap is useful, except when it's slow. zram is a RAM drive that uses
> > > compression. Create a swap-on-z
On Friday, June 5, 2020 3:20:30 AM MST Kamil Paral wrote:
> On Thu, Jun 4, 2020 at 10:32 PM Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/SwapOnZRAM
> >
> > == Summary ==
> >
> > Swap is useful, except when it's slow. zram is a RAM drive that uses
> > compression. Create a swap-on
On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
wrote:
>
> On 04.06.2020 22:30, Ben Cotton wrote:
> > Swap is useful, except when it's slow. zram is a RAM drive that uses
> > compression. Create a swap-on-zram during start-up. And no longer use
> > swap partitions by default.
>
> I'm stron
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2020-06-05 at 12:36 -0500, Richard Shaw wrote:
> On Fri, Jun 5, 2020 at 10:33 AM Igor Raits <
> ignatenkobr...@fedoraproject.org>
> wrote:
>
> > It is slightly different, you need to use `%global toolchain
> > clang`,
> > but otherwise yes.
On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote:
> Ben Cotton wrote:
>
> > Swap is useful, except when it's slow. zram is a RAM drive that uses
> > compression. Create a swap-on-zram during start-up. And no longer use
> > swap partitions by default.
> >
> > == Owner ==
> > * Name: [[
On Fri, Jun 5, 2020 at 10:33 AM Igor Raits
wrote:
> It is slightly different, you need to use `%global toolchain clang`,
> but otherwise yes.
>
Is this documented somewhere? I've been manually sed'ing out the
incompatible flags for PySide2 since it uses some clang only features.
Thanks,
Richard
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. This
On Fri, 2020-06-05 at 19:23 +0200, Florian Weimer wrote:
> * Jeff Law:
>
> > I'm not suggesting switching the default. I'm suggesting the compiler
> > choice be made by the upstream projects. Some prefer LLVM, others
> > prefer GCC. Fedora should get out of the way and use the same tools
> > th
* 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. This
> change proposal replaces that policy with one where compiler selectio
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: Steven Munroe
Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
Change
To: devel@lists.fedoraproject.org
Messag
* Jeff Law:
> I'm not suggesting switching the default. I'm suggesting the compiler
> choice be made by the upstream projects. Some prefer LLVM, others
> prefer GCC. Fedora should get out of the way and use the same tools
> that the upstream projects are using.
Do we know how many upstream pro
On Fri, 2020-06-05 at 07:58 +, devel-requ...@lists.fedoraproject.org wrote:
>
> Date: Fri, 05 Jun 2020 09:52:09 +0200
> From: Kevin Kofler
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
> Change
> To: devel@lists.fedoraproject.org
> Message-ID:
> Content-Type: tex
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
'apply_visitor(boost::geometry::index::detail::rtree::visitors::ins
On Fri, Jun 5, 2020 at 11:43 AM Jonathan Wakely
wrote:
> On 05/06/20 09:00 -0500, Richard Shaw wrote:
> The next error tells you the reason it couldn't be called:
>
> /usr/include/boost/variant/detail/apply_visitor_unary.hpp:46:1: error:
> 'typedef void boost::static_visitor::result_type' is inac
On Fri, 2020-06-05 at 14:11 +, devel-requ...@lists.fedoraproject.org wrote:
> Date: Fri, 5 Jun 2020 14:16:58 +0100
>
> From: Ian McInerney
>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
>
> Change
>
> To: Development discussions related to Fedora
>
>
On Fri, 2020-06-05 at 14:57 +, devel-requ...@lists.fedoraproject.org wrote:
> Date: Fri, 5 Jun 2020 07:56:57 -0700
>
> From: Tom Stellard
>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
>
> Change
>
> To: Development discussions related to Fedora
>
>
Missing expected images:
Iot dvd aarch64
Iot dvd x86_64
Failed openQA tests: 1/13 (x86_64)
Old failures (same test failed in Fedora-IoT-33-20200604.0):
ID: 612411 Test: x86_64 IoT-dvd_ostree-iso iot_greenboot
URL: https://openqa.fedoraproject.org/tests/612411
Passed openQA tests: 12/13 (x
On Fri, 2020-06-05 at 10:22 +, devel-requ...@lists.fedoraproject.org wrote:
> Date: Fri, 5 Jun 2020 11:42:36 +0200
>
> From: Vít Ondruch
>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
>
> Change
>
> To: devel@lists.fedoraproject.org
>
> Message-ID: <0f69dde
1 - 100 of 188 matches
Mail list logo
