Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-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] > > > == Documentation == > > > Several years ago Red Hat's tools team championed for Fedora > > > policy to strongly > > > discourage the use of LLVM/Clang for package building. > > > Exceptions were made for > > > packages that could only be built with Clang/LLVM: > > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler > > > > > > > > > At that point in history Red Hat had no Clang/LLVM engineers or > > > expertise. In > > > fact, the LLVM packages were actually maintained by an engineer > > > on the desktop > > > team (they had a hard requirement for llvm-pipe, so they got to > > > own the > > > Clang/LLVM bits). The policy essentially was a risk management > > > strategy for > > > Fedora. > > > > > > Times have changed and as a result we should revisit that Fedora > > > policy. > > > > > > The Red Hat tools team believes that LLVM/Clang and GCC should be > > > considered equals from > > > a Fedora policy standpoint. Selection of one toolchain over the > > > should should be > > > > s/should should be/other should be/ > Fixed. > > > > > > driven by the upstream project's preferences not by Fedora > > > specific policy. > > > > I think this needs to be clear that we're talking about the > > compiler > > here, not the C++ standard library. Fedora has no libc++ expertise > > I'm > > aware of. > > > > I think we want to be a lot more cautious about using libc++, > > because > > it would potentially require large parts of the C++ stack to be > > built > > twice and installed in parallel (think Python 2 and Python 3). For > > example if your package depends on Boost and you want to use libc++ > > then you need Boost rebuilt. Similarly for any C++ library, Qt, > > gtkmm, > > etc. etc. > > > > And I do not intend to offer C++ support for people who decide to > > use > > Clang + libc++ but don't try to resolve their own build failures :) > Agreed 100%. Based on comments from others I've already updated the > proposal to > hopefully clarify this change is strictly the compiler and does not > include the > runtime. > > Trying to support libc++ would be a compatibility nightmare. I do > believe one > day we'll need to do something there, but now isn't the time to open > that > discussion. > > > > > > > > > What that means in practice is that if the project upstream > > > prefers Clang/LLVM, > > > then Fedora should in turn be using Clang/LLVM to build those > > > packages. As a > > > concrete example, let's consider Chromium. > > > > > > Chromium upstream has been building with Clang/LLVM for several > > > years. > > > Yet policy > > > has forced Fedora package owners to shoulder a significant burden > > > to make it > > > build with GCC. Furthermore, Fedora does not get as much benefit > > > at it could by > > > forcing Chromium to be built with GCC since most other instances > > > are built with > > > Clang/LLVM. > > > > > > By changing policy Fedora package maintainers no longer have to > > > waste > > > time trying > > > to make Chromium build/work with GCC and Fedora gains additional > > > "many eyes" and > > > "many users" benefits by relying on the same tools to build > > > Chrome as the > > > upstream developers and other distributions. > > > > > > Additionally, if an upstream project currently uses GCC, but > > > switches to > > > Clang/LLVM (or vice-versa), then the package in Fedora should > > > switch > > > in a similar > > > manner. The only policy restriction should be that the compiler > > > must > > > exist in Fedora. > > > > If upstream supports both compilers, that's probably not a good > > reason > > to change anything in Fedora. > If they're on equal footing upstream, then no I don't think changing > would be the > right thing to do. I don't think that's really the case for Firefox > or Chromium. > I'm less familiar with the LibreOffice situation, so I won't try to > give an > opinion there. > > Perhaps in this case we leave it up to the Fedora packager? > > > > > > In some ways this means there is no "default" compiler for > > > Fedora. The default > > > is whatever the upstream project supports/recommends. However, > > > there are > > > probably many packages with upstreams that are ambivalent about > > > their compiler > > > choice. For those packages I would recommend we keep the status > > > quo at the > > > current time. For a package with a dead upstream, the Fedora > > > packager should be > > > able to select the compiler they want to use for the package. > > > > I would prefer the policy to have a stronger preference for GCC > > when > > there is no good reason to change. Currently it's worded like > > keeping > > the status quo is Jeff's personal
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 the use of LLVM/Clang for package building. Exceptions were > > made for > > packages that could only be built with Clang/LLVM: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler > > > > > > At that point in history Red Hat had no Clang/LLVM engineers or expertise. > > In > > fact, the LLVM packages were actually maintained by an engineer on the > > desktop > > team (they had a hard requirement for llvm-pipe, so they got to own the > > Clang/LLVM bits). The policy essentially was a risk management strategy for > > Fedora. > > > > Times have changed and as a result we should revisit that Fedora policy. > > > > The Red Hat tools team believes that LLVM/Clang and GCC should be > > considered equals from > > a Fedora policy standpoint. Selection of one toolchain over the > > should should be > > s/should should be/other should be/ Fixed. > > > driven by the upstream project's preferences not by Fedora specific policy. > > I think this needs to be clear that we're talking about the compiler > here, not the C++ standard library. Fedora has no libc++ expertise I'm > aware of. > > I think we want to be a lot more cautious about using libc++, because > it would potentially require large parts of the C++ stack to be built > twice and installed in parallel (think Python 2 and Python 3). For > example if your package depends on Boost and you want to use libc++ > then you need Boost rebuilt. Similarly for any C++ library, Qt, gtkmm, > etc. etc. > > And I do not intend to offer C++ support for people who decide to use > Clang + libc++ but don't try to resolve their own build failures :) Agreed 100%. Based on comments from others I've already updated the proposal to hopefully clarify this change is strictly the compiler and does not include the runtime. Trying to support libc++ would be a compatibility nightmare. I do believe one day we'll need to do something there, but now isn't the time to open that discussion. > > > > What that means in practice is that if the project upstream prefers > > Clang/LLVM, > > then Fedora should in turn be using Clang/LLVM to build those packages. As > > a > > concrete example, let's consider Chromium. > > > > Chromium upstream has been building with Clang/LLVM for several years. > > Yet policy > > has forced Fedora package owners to shoulder a significant burden to make it > > build with GCC. Furthermore, Fedora does not get as much benefit at it > > could by > > forcing Chromium to be built with GCC since most other instances are built > > with > > Clang/LLVM. > > > > By changing policy Fedora package maintainers no longer have to waste > > time trying > > to make Chromium build/work with GCC and Fedora gains additional "many > > eyes" and > > "many users" benefits by relying on the same tools to build Chrome as the > > upstream developers and other distributions. > > > > Additionally, if an upstream project currently uses GCC, but switches to > > Clang/LLVM (or vice-versa), then the package in Fedora should switch > > in a similar > > manner. The only policy restriction should be that the compiler must > > exist in Fedora. > > If upstream supports both compilers, that's probably not a good reason > to change anything in Fedora. If they're on equal footing upstream, then no I don't think changing would be the right thing to do. I don't think that's really the case for Firefox or Chromium. I'm less familiar with the LibreOffice situation, so I won't try to give an opinion there. Perhaps in this case we leave it up to the Fedora packager? > > > In some ways this means there is no "default" compiler for Fedora. The > > default > > is whatever the upstream project supports/recommends. However, there are > > probably many packages with upstreams that are ambivalent about their > > compiler > > choice. For those packages I would recommend we keep the status quo at the > > current time. For a package with a dead upstream, the Fedora packager > > should be > > able to select the compiler they want to use for the package. > > I would prefer the policy to have a stronger preference for GCC when > there is no good reason to change. Currently it's worded like keeping > the status quo is Jeff's personal opinion. I would like it to be > policy. So that text was literally copy and pasted from internal discussions. So, yea, it's my opinion and I think it's one of the option questions this body needs to hammer out to more precisely define any updated policy. My preference would be to stick with GCC when upstream has no recommendations/support policy around supported compilers to avoid unnecessary churn. I would also be willing to
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 features may have a hard need for one toolchain or the > > other. And the > > proposal I've made accounts for that by allowing the upstream project to > > select the compiler. > > In your case it would be GCC. For others it could well be Clang/LLVM. > > I respectfully disagree with your definition of bleeding edge ... Perhaps that was a bad choice of words. > > 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. That's not what is being proposed. What's being proposed is far more narrowly scoped. > > I respectfully restate my position that clang/LLVM is incomplete and > not ready for that role. The proposal under debate is to change Fedora policy so that compiler selection comes from the upstream project. For your project clearly GCC is a better choice. Other projects Clang/LLVM is a better choice. Whether or not Clang/LLVM is ready to replace GCC as the default compiler is not on the table and thus isn't terribly interesting (to me) to debate. So I would ask that we keep the discussion to the proposal at hand. Jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 4G of allocated space in the zram swap, > > >> but: > > >> > > >> # zramctl > > >> NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > > >> /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 > > >> > > >> This suggests that it's only using 1.8G. Can you explain what this > > >> means? > > > > > > Yeah that's confusing. zramctl just gets info from sysfs, but you > > > could double check it by > > > > > > cat /sys/block/zram0/mm_stat > > > > > > The first value should match "DATA" column in zramctl (which reports in > > > MiB). > > > > > > While the kernel has long had support for using up to 32 swap devices > > > at the same time, this is seldom used in practice so it could be an > > > artifact of this? Indicating that all of this swap is "in use" from > > > the swap perspective, where zramctl is telling you the truth about > > > what the zram kernel module is actually using. Is it a cosmetic > > > reporting bug or intentional? Good question. I'll try to reproduce and > > > report it upstream and see what they say. But if you beat me to it > > > that would be great, and then I can just write the email for linux-mm > > > and cite your bug report. :D > > > > Part of my concern is that if it's not actually full, then why is it > > using so much of the disk swap? OK I can't explain what you're seeing because I'm not certain of the workload. Here's what I've got going on. F32, 5.7.0-fc33 kernel, 8G RAM, 4G swaponzram, 10G swapondrive. With swaponzram higher priority before doing any swapping. $ free -m totalusedfree shared buff/cache available Mem: 786413954251 6022166122 Swap: 14559 0 14559 $ swapon NAME TYPE SIZE USED PRIO /dev/sda5 partition 10.4G 0B -2 /dev/zram0 partition 3.9G 0B3 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 4K 74B 12K 8 [SWAP] Then build webkitgtk using 'ninja -j10' What happens? Only the swaponzram0 is used for a while. It fills up and then swaponsda5 starts being used. But also, the used on swapzram0 goes down and up and down and up. During this time, swaponsda5 mostly doesn't change. Sometimes it goes down. But it only goes back up again if swaponzram0 is already full. I think this is working as I expect because once anonymous pages are in either swap, they don't migrate between the swaps. But anonymous pages can always be deallocated from either swap at any time leading to the appearance that zram0 isn't being used to the max - well because it's not. Here is an example. $ free -m totalusedfree shared buff/cache available Mem: 786456131945 63 3051929 Swap: 1455947459814 $ swapon NAME TYPE SIZE USED PRIO /dev/sda5 partition 10.4G 1.9G -2 /dev/zram0 partition 3.9G 2.6G3 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 2.4G 582.1M 877.6M 8 [SWAP] $ The gap between COMPR and TOTAL might seem big. And in fact it might be fragmentation not metadata overhead, as was earlier suggested. But it changes a lot and fast with this workload. Just a couple minutes later. $ free -m totalusedfree shared buff/cache available Mem: 78647602 125 1 136 56 Swap: 1455973427216 $ swapon NAME TYPE SIZE USED PRIO /dev/sda5 partition 10.4G 3.4G -2 /dev/zram0 partition 3.9G 3.9G3 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 3.9G 913.1M 954M 8 [SWAP] $ I'm getting 4:1 compression ratio with this workload, by the way. It's so far not using more than 1GiB RAM to save me 4G. Or a net savings of 3G that is regular memory. But more importantly than the compression? The fact 4GiB did not need to page out and back in from SSD. And in fact as the workload progresses, it's saving quite a lot more than 4G of pageouts to disk - I just don't have a cumulative value. Also? The workload has a high wait state for CPU when it's IO bound, waiting on the drive, even though it's an SSD. The zram based swap is only as smart as the workload is at properly deallocating things that it no longer needs. If it's holding onto anonymous pages and they're in the swap-on-zram device, then that's it, back to disk swapping only. I haven't yet seen swapon claim swap was full but then zramctl say it wasn't.
Re: Fedora 33 System-Wide Change proposal: swap on zram
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, it is swap specific, providing a memory based writeback cache to a disk based swap. Ok, that makes sense about zram. It's a lot simpler than I was thinking it was. The generator does require a reboot to change configurations. You could absolutely say, but Chris, the other ones you can just systemctl restart! That is true, but except for testing, I don't see that as an advantage compared to the overall simplisticity of zram-generator and reusing the existing infrastructure in systemd that's already well tested and maintained. Sure, I'll set that up for the next time I reboot. But that is likely to still be a long time from now. Although really any value higher than the disk based swap is sufficient. The systemd-swap service appears to set the priority of zram to the maximum possible. No, it was quite clear that I was modifying the right config. It's the /etc/systemd/swap.conf as described in the man page and it was affecting the result. OK that is not for zram-generator. That's for one of the others. Off hand I don't know which one it's for, this is way too confusing because of all the competing implementations, which is part of the motivation of the feature -> buh bye, thank you for your service! Sorry, I guess that wasn't clear. That's the config file for systemd-swap which is what I was testing. Part of my concern is that if it's not actually full, then why is it using so much of the disk swap? Not sure. What should be true is if you swapoff on /dev/sda3 it'll move any referenced anon pages to /dev/zram0. And then if you swapon /dev/sda3 it will use 0 bytes until /dev/zram0 is full. What kernel version are you using? That is what I did do. kernel 5.5.17-200.fc31.x86_64 For upstream, do you mean the kernel? Yes. bugzilla.kernel.org - this goes to the linux-mm folks (memory management) but you can search for a zram bug and just see what component they use and post the bug here and I'll pick it up. I reset everything and now I can't reproduce it. I wonder if it was because I had zswap enabled as well. When I was going to file the bug report, I came across a comment that it's not beneficial to use them both at the same time. # swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 16G 0B-2 /zram0partition 5G 4.6G 32767 # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 5G 4.6G 1.5G 1.5G 4 It looks like it's working properly now. So it seems likely that it was user error. And for the little it matters, I approve of the change proposal. I will have to test it out on my other systems as well now. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-06-06 - 95% PASS
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 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 implementations: > > > > anaconda package provides zram.service > > zram package provides zram-swap.service > > systemd-swap package provides > > Did you leave something out? systemd-swap package provides systemd-swap.service > Are you saying that zram and systemd-swap both provide configuration for > zram? 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, it is swap specific, providing a memory based writeback cache to a disk based swap. > > > I've only casually tested systemd-swap package. Note this isn't an > > upstream systemd project. Where as the proposed rust zram-generator is > > "upstream" in that it's maintained by the same folks, but is not > > provided by systemd package I think because it's in rust. > > Ok, I was thinking the generator might require rebooting to get it to > work. And I saw the systemd-swap package and thought that sounded > useful to try. The generator does require a reboot to change configurations. You could absolutely say, but Chris, the other ones you can just systemctl restart! That is true, but except for testing, I don't see that as an advantage compared to the overall simplisticity of zram-generator and reusing the existing infrastructure in systemd that's already well tested and maintained. > > > There shouldn't be any weird/bad interactions between them, but it is > > possible for the user to become very confused which one is working. It > > *should* be zram-generator because it runs much earlier during boot > > than the others. But I have not thoroughly tested for conflicting > > interactions, mainly just sanity testing to make sure things don't > > blow up. > > I only started the one service, so I don't think there are any conflicts. So what you can do is disable all the above listed service units. And you'll be testing the zram-generator alone. The config file for that is /etc/systemd/zram-generator.conf Since there isn't yet an option to set swap priority, chances are it gets auto-assigned during boot by the kernel. Usually /dev/zram0 comes first and should get -2 priority and /dev/swapondisk will get a -3. In that case, zram is higher priority already. But if flipped, you can just: swapoff /dev/zram0 swapon -p 3000 /dev/zram0 Although really any value higher than the disk based swap is sufficient. > > >> 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. > > > > It might be you're modifying the configuration of a different > > implementation from the one that's actually setting up swaponzram. > > No, it was quite clear that I was modifying the right config. It's the > /etc/systemd/swap.conf as described in the man page and it was affecting > the result. OK that is not for zram-generator. That's for one of the others. Off hand I don't know which one it's for, this is way too confusing because of all the competing implementations, which is part of the motivation of the feature -> buh bye, thank you for your service! > > >> I don't understand the numbers I'm getting for these. I disabled my > >> swap partition to force as much to go to zram as possible and then > >> turned it back on. > >> > >> # swapon > >> NAME TYPE SIZE USED PRIO > >> /dev/sda3 partition 16G 1.9G-2 > >> /zram0partition 4G 4G 32767 > >> > >> This looks like I'm using all 4G of allocated space in the zram swap, but: > >> > >> # zramctl > >> NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > >> /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 > >> > >> This suggests that it's only using 1.8G. Can you explain what this means? > > > > Yeah that's confusing. zramctl just gets info from sysfs, but you > > could double check it by > > > > cat /sys/block/zram0/mm_stat > > > > The first value should match "DATA" column in zramctl (which reports in > > MiB). > > > > While the kernel has long had support for using up to 32 swap devices > > at the same time, this is seldom used in practice so it could be an > > artifact of this? Indicating that all of this swap is "in use" from > > the swap perspective, where zramctl is telling you the truth about > > what the zram kernel module is actually using. Is it a cosmetic > > reporting bug or intentional? Good question. I'll try to reproduce and > > report it upstream and see what they say. But if you beat me to it > > that would be great, and then I can just write the email for linux-mm > >
Re: Fedora 33 System-Wide Change proposal: swap on zram
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.service systemd-swap package provides Did you leave something out? Are you saying that zram and systemd-swap both provide configuration for zram? I've only casually tested systemd-swap package. Note this isn't an upstream systemd project. Where as the proposed rust zram-generator is "upstream" in that it's maintained by the same folks, but is not provided by systemd package I think because it's in rust. Ok, I was thinking the generator might require rebooting to get it to work. And I saw the systemd-swap package and thought that sounded useful to try. There shouldn't be any weird/bad interactions between them, but it is possible for the user to become very confused which one is working. It *should* be zram-generator because it runs much earlier during boot than the others. But I have not thoroughly tested for conflicting interactions, mainly just sanity testing to make sure things don't blow up. I only started the one service, so I don't think there are any conflicts. 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. It might be you're modifying the configuration of a different implementation from the one that's actually setting up swaponzram. No, it was quite clear that I was modifying the right config. It's the /etc/systemd/swap.conf as described in the man page and it was affecting the result. I don't understand the numbers I'm getting for these. I disabled my swap partition to force as much to go to zram as possible and then turned it back on. # swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 16G 1.9G-2 /zram0partition 4G 4G 32767 This looks like I'm using all 4G of allocated space in the zram swap, but: # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 This suggests that it's only using 1.8G. Can you explain what this means? Yeah that's confusing. zramctl just gets info from sysfs, but you could double check it by cat /sys/block/zram0/mm_stat The first value should match "DATA" column in zramctl (which reports in MiB). While the kernel has long had support for using up to 32 swap devices at the same time, this is seldom used in practice so it could be an artifact of this? Indicating that all of this swap is "in use" from the swap perspective, where zramctl is telling you the truth about what the zram kernel module is actually using. Is it a cosmetic reporting bug or intentional? Good question. I'll try to reproduce and report it upstream and see what they say. But if you beat me to it that would be great, and then I can just write the email for linux-mm and cite your bug report. :D Part of my concern is that if it's not actually full, then why is it using so much of the disk swap? For upstream, do you mean the kernel? ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 I've only casually tested systemd-swap package. Note this isn't an upstream systemd project. Where as the proposed rust zram-generator is "upstream" in that it's maintained by the same folks, but is not provided by systemd package I think because it's in rust. The first two packages I've used a lot and they work, there's nothing wrong with them. And yes the idea of this proposal is to say bon voyage, thank you for your service, and then converge on the rust zram-generator. There shouldn't be any weird/bad interactions between them, but it is possible for the user to become very confused which one is working. It *should* be zram-generator because it runs much earlier during boot than the others. But I have not thoroughly tested for conflicting interactions, mainly just sanity testing to make sure things don't blow up. >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. It might be you're modifying the configuration of a different implementation from the one that's actually setting up swaponzram. > I don't understand the numbers I'm getting for these. I disabled my > swap partition to force as much to go to zram as possible and then > turned it back on. > > # swapon > NAME TYPE SIZE USED PRIO > /dev/sda3 partition 16G 1.9G-2 > /zram0partition 4G 4G 32767 > > This looks like I'm using all 4G of allocated space in the zram swap, but: > > # zramctl > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 > > This suggests that it's only using 1.8G. Can you explain what this means? Yeah that's confusing. zramctl just gets info from sysfs, but you could double check it by cat /sys/block/zram0/mm_stat The first value should match "DATA" column in zramctl (which reports in MiB). While the kernel has long had support for using up to 32 swap devices at the same time, this is seldom used in practice so it could be an artifact of this? Indicating that all of this swap is "in use" from the swap perspective, where zramctl is telling you the truth about what the zram kernel module is actually using. Is it a cosmetic reporting bug or intentional? Good question. I'll try to reproduce and report it upstream and see what they say. But if you beat me to it that would be great, and then I can just write the email for linux-mm and cite your bug report. :D -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS
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://metacpan.org/pod/release/XSAWYERX/perl-5.30.3/pod/perldelta.pod -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS
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://metacpan.org/pod/release/XSAWYERX/perl-5.30.3/pod/perldelta.pod -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1838000] 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 --- 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://metacpan.org/pod/release/XSAWYERX/perl-5.30.3/pod/perldelta.pod -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1838000] 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 Group|security, qe_staff | CC||caillon+fedoraproject@gmail ||.com, iarn...@gmail.com, ||ka...@ucw.cz, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ||perl-maint-l...@redhat.com, ||psab...@redhat.com, ||rhug...@redhat.com, ||sandm...@redhat.com, ||spo...@gmail.com Deadline|2020-06-02 | Summary|EMBARGOED CVE-2020-12723|CVE-2020-12723 perl: |perl: corruption of |corruption of intermediate |intermediate language state |language state of compiled |of compiled regular |regular expression due to |expression due to recursive |recursive S_study_chunk() |S_study_chunk() calls leads |calls leads to DoS |to DoS | -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844664] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS [fedora-all]
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 associated bugs get updated when new packages are pushed to stable. = # bugfix, security, enhancement, newpackage (required) type=security # low, medium, high, urgent (required) severity=medium # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1838000,1844664 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False == Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844664] New: CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS [fedora-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 [fedora-all] Product: Fedora Version: 32 Status: NEW Component: perl Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: jples...@redhat.com Reporter: msidd...@redhat.com QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rhug...@redhat.com, sandm...@redhat.com, spo...@gmail.com Target Milestone: --- Classification: Fedora This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of fedora-all. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1838000] 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 [Bug 1844664] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS [fedora-all] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844664] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1844664 msidd...@redhat.com changed: What|Removed |Added Blocks||1838000 (CVE-2020-12723) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1838000 [Bug 1838000] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1838000] 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 --- 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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844663] New: 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=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] Product: Fedora Version: 32 Status: NEW Component: perl Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: jples...@redhat.com Reporter: msidd...@redhat.com QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rhug...@redhat.com, sandm...@redhat.com, spo...@gmail.com Target Milestone: --- Classification: Fedora This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of fedora-all. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS
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 [Bug 1844663] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS [fedora-all] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844663] 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=1844663 msidd...@redhat.com changed: What|Removed |Added Blocks||1837988 (CVE-2020-10878) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1837988 [Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS
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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1837988 msidd...@redhat.com changed: What|Removed |Added Group|security, qe_staff | CC||caillon+fedoraproject@gmail ||.com, iarn...@gmail.com, ||ka...@ucw.cz, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ||perl-maint-l...@redhat.com, ||psab...@redhat.com, ||rhug...@redhat.com, ||sandm...@redhat.com, ||spo...@gmail.com Deadline|2020-06-01 | Summary|EMBARGOED CVE-2020-10878|CVE-2020-10878 perl: |perl: corruption of |corruption of intermediate |intermediate language state |language state of compiled |of compiled regular |regular expression due to |expression due to integer |integer overflow leads to |overflow leads to DoS |DoS --- Comment #15 from msidd...@redhat.com --- References: https://github.com/Perl/perl5/blob/blead/pod/perl5303delta.pod https://github.com/Perl/perl5/compare/v5.30.2...v5.30.3 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844663] 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=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 associated bugs get updated when new packages are pushed to stable. = # bugfix, security, enhancement, newpackage (required) type=security # low, medium, high, urgent (required) severity=medium # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1837988,1844663 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False == Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844662] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1844662 msidd...@redhat.com changed: What|Removed |Added Blocks||1837975 (CVE-2020-10543) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1837975 [Bug 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS
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=1844662 [Bug 1844662] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS [fedora-all] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS
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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844662] New: CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS [fedora-all]
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: NEW Component: perl Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: jples...@redhat.com Reporter: msidd...@redhat.com QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rhug...@redhat.com, sandm...@redhat.com, spo...@gmail.com Target Milestone: --- Classification: Fedora This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of fedora-all. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1844662] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS [fedora-all]
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 associated bugs get updated when new packages are pushed to stable. = # bugfix, security, enhancement, newpackage (required) type=security # low, medium, high, urgent (required) severity=medium # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1837975,1844662 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False == Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1837975 msidd...@redhat.com changed: What|Removed |Added Group|security, qe_staff | CC||caillon+fedoraproject@gmail ||.com, iarn...@gmail.com, ||ka...@ucw.cz, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ||perl-maint-l...@redhat.com, ||psab...@redhat.com, ||rhug...@redhat.com, ||sandm...@redhat.com, ||spo...@gmail.com Deadline|2020-06-01 | Summary|EMBARGOED CVE-2020-10543|CVE-2020-10543 perl: |perl: heap-based buffer |heap-based buffer overflow |overflow in regular |in regular expression |expression compiler leads |compiler leads to DoS |to DoS | -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 the default compiler (at this time or in the foreseeable future). I have only stated that IF there are strong reasons to switch, THEN it should be done systemwide and not only for some special cases. But I currently see more reasons NOT to switch. Of course, some people here have proposed to change the default, that is undisputed. But I just wanted to make it clear that I was not one of those people, in case somebody got that false impression for some reason. Kevin Kofler ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 "GCC" is wrong here or you are missing a negation somewhere. > There are tons of gcc specific patches in chromium [0] Hmmm, looks like the situation has worsened recently, several of those patches are now downstream (or sidestream, e.g., copied from Gentoo). Chromium used to actually commit compile fixes for newer GCC releases in its master branch, just as projects using GCC primarily do as well, and the GCC-related patches in the Fedora specfile were mostly backported from there. What I see now makes me less happy. That said, the Chromium package no longer carrying such patches is going to make it harder for QtWebEngine to keep up with new GCC releases (and their incompatible changes). QtWebEngine defaults to building everything including the bundled Chromium fork with the toolchain Qt was built with. This is obviously GCC, and not likely to change any time soon (unless the distrowide default changes). When there is a build issue with a new GCC, chromium.spec is the first place to look for a fix. If Chromium switches to being built with Clang, the QtWebEngine maintainers will have to do all the work of tracking down the build fixes for the latest GCC on their own. Now, Qt upstream actually systematically tests building QtWebEngine with GCC, so we do not have to apply so many GCC build fixes there. (They are often already applied by Qt upstream.) The problem is just that Rawhide typically has a newer GCC than the rest of the world. But all that said, if the situation is really that Chromium requires so many downstream patches to even compile with GCC, then it actually falls under the already preexisting "upstream does not support GCC and/or the code does not compile with GCC" exception and this change is actually not needed at all for Chromium. The change only affects projects where upstream actually supports both compilers, but prefers Clang for whatever reason. And there, I do not think we should be bound by upstream's preference. Kevin Kofler ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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. On 6/5/20 3:07 PM, Chris Murphy wrote: $ swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 3.9G 778M -2 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 777M 240.4M 249.6M 8 [SWAP] $ In this example, the system evicts 777M, at a cost of 250M, for a total gain of ~527M. I don't understand the numbers I'm getting for these. I disabled my swap partition to force as much to go to zram as possible and then turned it back on. # swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 16G 1.9G-2 /zram0partition 4G 4G 32767 This looks like I'm using all 4G of allocated space in the zram swap, but: # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 This suggests that it's only using 1.8G. Can you explain what this means? ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 administrating his own systems, I find those to be extremely annoying, because they do stuff behind my back that I never asked to happen and I have to mask them (and/or uninstall them completely) to get rid of the unwanted behavior. E.g., the systemd generator that tries to automount partitions not listed in fstab based on their GPT UUIDs is just broken. If I do not have the partition in the fstab, I left it out for a reason (e.g., the swap partition I have on my SSD in case I ever need it, which is normally NOT mounted to avoid wearing out the SSD). So why does systemd want to second-guess me and mount that partition behind my back unless I go out of my way to mask the magic generator? So why can this zram feature not be a line in fstab, a parameter passed through the kernel CLI, or some other solution that is easily tweakable and that will definitely not affect upgrades of existing installations (unlike yet another systemd generator, if it happens to get installed for whatever reason)? IMHO, the only systemd generator that should ever mount partitions of any kind (including virtual ones such as zram) is the systemd-fstab-generator. If you want more stuff mounted, it should be added to /etc/fstab, that's what that file is for! Kevin Kofler ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2020-06-08 Fedora QA Meeting
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 this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 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 support, as opposed to packaging libraries as source code. > > This is not fair. It is a programming language that is safer than C and > is already used by some projects that we ship. rpm-ostree, firefox, > librsvg2 and others. 1. librsvg2 and firefox are not really core system components. They are UI-related packages (an image processing library and a web browser), which is at least one layer higher. 2. rpm-ostree is only a core system component if you use an ostree-based installation. In the default Fedora system, it is not. 3. I think that it is a bad enough precedent that even these packages are using Rust. We do not have a reasonable way to package software written in Rust. Packaging libraries as source code is not reasonable in a binary distribution. (And yes, I was opposed to the Go packaging guidelines from day 1, and the Rust packaging guidelines copy the same broken concepts, so I am opposed to those as well.) As a result, shipping Rust software in Fedora is very painful, because everything is essentially statically linked (actually compiled on demand at application compile time and then statically linked into the application). 4. The Rust toolchain is also inherently foreign on Fedora because it is not based on GCC (but on LLVM). Core system components should be written in C. The higher layers (UI, extra CLI tools, etc.) can use C++ as well. IMHO, any other programming language is just a pain. Kevin Kofler ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Supporting hibernation in Workstation ed., draft 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 options in firmware setup to become > >> unavailable, e.g. compatibility support modules for presenting a > >> legacy BIOS. I'm skeptical that pin shorts permit you to gain access > >> to such things - but if so, it's clearly a vulnerability that should > >> be reported. > > > > This is by design. Generally, there's a marking on the silkscreen with > > something like "PWD" or "PASSWD" to mark it. > > I seem to remember reading that resetting the firmware away from secure > modes also wipes the secure TPM storage, so that you effectively wipe > the machine to factory-fresh state. On some systems, that is the case. I've found that it's pretty rare, but I don't have any real data to base that on, it's anecdotal. That doesn't matter for Fedora, you can still boot the same system you installed with Secure Boot enabled without it enabled. -- John M. Harris, Jr. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Supporting hibernation in Workstation ed., draft 1
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 presenting a legacy BIOS. I'm skeptical that pin shorts permit you to gain access to such things - but if so, it's clearly a vulnerability that should be reported. This is by design. Generally, there's a marking on the silkscreen with something like "PWD" or "PASSWD" to mark it. I seem to remember reading that resetting the firmware away from secure modes also wipes the secure TPM storage, so that you effectively wipe the machine to factory-fresh state. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 ratio of nearly 3:1 over time, the initial evictions seem to be pretty highly compressible. Not sure why that is. Anyway 2:1 is a fairly safe bet for the general case. $ free -m totalusedfree shared buff/cache available Mem: 78637038 131 30 693 529 Swap: 3930 7783152 $ swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 3.9G 778M -2 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 777M 240.4M 249.6M 8 [SWAP] $ In this example, the system evicts 777M, at a cost of 250M, for a total gain of ~527M. Quit all VM's... $ free -m totalusedfree shared buff/cache available Mem: 7863 6786283 30 9016892 Swap: 3930 2293701 $ swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 3.9G 229.5M -2 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 228.6M 74M 105.1M 8 [SWAP] $ We see here that it has free'd up swap and memory, having dropped pages in swap. But there is some zram metadata overhead that is not dropped for whatever reason. But the net gain is still better than 50%. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 the > proposal I've made accounts for that by allowing the upstream project to > select the compiler. > In your case it would be GCC. For others it could well be Clang/LLVM. I respectfully disagree with your definition of bleeding edge ... IEEE-754-2008 (defined both Float128 and Decimal32/64/128. C11 includes the above in annex F. It seems like so long ago ;) Last I checked this is 2020 and GCC/GLIBC has made good progress implementing these standards. GCC supports several platforms (including PPC64LE) with hardware implementations for both types. The hard work has been done and Clang can leverage the run-time and standard headers directly. 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. I respectfully restate my position that clang/LLVM is incomplete and not ready for that role. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 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 (choosing Clang because they like it) and while we can (and have) > > engaged upstreams on this topic and I suspect we will continue to do so in > > some > > cases. > > > > But in the end I think we still have to respect the upstream project's > > choices, > > even if it's just because they like Clang/LLVM more than GCC. > > Why? Shouldn't the Fedora maintainers be able to decide this? If they have > been > using GCC for years and it hasn't been an obstackle for them, why should > they switch? Maintainers aren't static and when the maintainer chooses to go a different direction than upstream, then there's a cost to be paid. While it may work for a particular maintainer to do something different for their package, what about the poor person who takes the package over when the original maintainer leaves or someone who has to pick it up to deal with a CVE while the maintainer is on PTO. Not everyone is as toolchain savvy as you, or is able to understand the intent of code as well, or is likely to have the longevity you've had, etc. You're at a level that most developers will never achieve in their career. Think about folks that are less experienced, or with fewer natural gifts, etc and sometimes you come up with different answers. Conceptually, IHMO, packages in Fedora should be as close to upstream as possible. Toolchain selection is a piece of that. The major exception in my mind is flag selection, particularly due to the need to enforce consistent security hardening, distro-wide optimizations, or ISA selection to ensure the bits run everywhere they're supposed to. > If I understand the LO case, it is just that LO sometimes uses the Skia > library which is written by Google and Google likes compiler monoculture and > is using heavily #ifdef __clang__ in it and using the clang variants of the > generic vectors guarded by that, and as fallback just doesn't use simd. > I believe Honza Hubicka had quite some changes for Skia, not sure if they went > upstream already or not. > But the maintainers should be able to choose, build just Skia with clang and > rest of LO with GCC, or everything with GCC and with help from us get Skia > into shape for better portability (that would be ideal, but of course can > mean more hopefully one time work), or build all of it with Clang/LLVM. Again, I'd fall back to the "what does upstream do". DOing something different should require strong technical justification and none of the stuff I've seen discussed around LO, Firefox or Chromium would meet that bar IMHO. jeff > ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: broken threads
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, there is no In-reply-to: header. Is this caused by the agent: User-Agent: Evolution 3.36.2 (3.36.2-1.fc32) ? Yes, this was explained earlier. He's getting the list in digest form and Evolution isn't able to break it up properly to set the correct subjects and in-reply-to headers. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: subtle issue with systemd, dnf 'greedy' obsoletes behaviour, and multiple repos
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 want change in behavior, please open a discussion with libsolv's > upstream. I can try it, but the reaction to https://github.com/openSUSE/libsolv/issues/146 makes me sceptical that this one will be handled any better. But one can always try. > If I understand correctly how the sat-solver works, it's populated with > a set of rules before the transaction is resolved and it's not possible > to tweak in on fly as yum did. It could be possible to pre-process the > packages and hide Obsoletes of older packages, but what if the latest > package has broken deps and doesn't get into transaction? DNF in Fedora > has best=0. In that case the older package would get into transaction > and its Obsoletes would be ignored - and that's definitely something we > don't want. I rather think that this needs to be handled with some special SAT rule at the libsolv level (i.e., one such as: the transaction is not allowed to drag in both the old version of the package and the Obsoletes that it contains). It is true that this complexity did not exist with the old yum because it would never pick old versions of packages, but filter them out completely before even trying to compute a transaction (like dnf --best does, essentially). Kevin Kofler ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: subtle issue with systemd, dnf 'greedy' obsoletes behaviour, and multiple repos
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. > > https://github.com/openSUSE/libsolv/issues/146 That is actually the other issue, that splitting should be possible, which seems to be somehow partially fixed judging from Adam Williamson's tests. Not sure when and how though, given that libsolv upstream had refused to act on my report (see the comment history). I think the one about Obsoletes from outdated versions of packages is not filed at upstream libsolv yet, only downstream against DNF, and DNF probably cannot fix it without support from libsolv. But unfortunately, given the reaction to my issue 146, I doubt libsolv upstream will handle this any better if I file it there. Kevin Kofler ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 with a consistent toolchain > > > wherever possible. > > > > > > > Kevin, that's not true at all. Maybe it looks like it builds fine for you, > > because all the fixes get to you, but I as a co-maintainer of Chromium in > > Fedora and ex-maintainer of Chromium in RHEL can say that most of the time > > I spent fixing GCC problems. Just look at the current SPEC file and search > > for gcc there.. There are several gcc related bugs - > > https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec. Or > > even better look at > > https://bugs.chromium.org/p/chromium/issues/detail?id=819294 where the GCC > > The very first one there is just a bug in Chromium: using a type > without including the header that defines it. There are several others > like that (relying on unique_ptr bing declared implicitly, relying on > nullptr_t being declared implicitly ...) > > Those are upstream bugs and should be fixed. Period. Yup. And what you're hitting on is a real issue. Monocultures are generally bad. All the world is a vax, all the world is a sparc (running solaris), all the world is x86-linux, everything builds with gcc and so-on. There's a secondary problem you're touching on and that's engagement to get stuff fixed correctly. Finding the balance there can be hard too, particularly if the developer doesn't know *how* to engage a particular community. I run into this myself and it can be frustrating. So while I'd rather see better engagement on bugs, I do understand why a Chromium developer might not have reported issues to the GCC community. In an ideal world, everything would build with both compilers, folks would review and fix all the diagnostics they generate. Selection of which binaries would essentially happen at the end of the build cycle with the decision made on a per- package basis. However, I strongly suspect the pitchforks would be out if we tried to go that far :-) [ ... ] > tl;dr This is a chromium problem, not just a GCC problem. Fixing those > portability problems is an investment and reduces technical debt. It's a balance and judgment call. For Chromium and Firefox the cost of maintaining GCC as a build toolchain has apparently outgrown the cost of non- portable code. Of course the cost of the latter usually does show up until much later in a product's lifecycle, so only time will tell if those projects have made a good decision. Jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 > >> change proposal replaces that policy with one where compiler selection > >> for Fedora follows the package's upstream preferences. > >> > >> == Owner == > >> * Name: Jeff Law > >> * Email: l...@redhat.com > > > > I am opposed to this change. Chromium and Firefox build fine with GCC. I > > > > think that a distribution should be built with a consistent toolchain > > wherever possible. > > > > Last I checked, there were several reasons why GCC is preferred over > > Clang/LLVM in Fedora. And if that should ever change (or have changed > > already), then switching the systemwide default (reversing the rules, > > i.e., using GCC only for those packages that do not build with Clang) > > should be envisioned. But as far as I know, that is not the case at this > > time, considering runtime performance, security features, etc. > > > > I do not see why we should allow yet another special case for Firefox, > > nor why we should let random packages make their own choice of > > compiler and risk running into hidden binary incompatibilities. We have > > a system compiler for a reason. > > Just FTR, there are technical (and security) reasons why we might > consider switching Ruby from GCC to Clang in the future: > > https://bugzilla.redhat.com/show_bug.cgi?id=1721553 I don't think allowing builds with Clang are necessarily bad. It has one interesting feature that actually helps security. -ftrivial-auto-var-init=zero what this does is initialize to zero any variable that it detects is uninitialized. This can prevent leaking secrets in network protols if memset was forgotten and it prevents attacks where the value of the stack or heap is groomed to a certain value to enable an exploit. In one conference presentation, it was said that 900 fixed CVE's in Chrome and 12% of all Android CVE's would have been prevented with this feature. I am wondering if that should be a default flag for clang builds? And if you do fuzzing, you can compile AFL with clang and its more powerful. There's pro's and cons. -Steve ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 to be ABI compatible, see e.g.
https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
That is just one arch, has anyone e.g. tried gcc
make check-gcc check-c++-all RUN_ALL_COMPAT_TESTS=1 ALT_CC_UNDER_TEST=clang \
ALT_CXX_UNDER_TEST=clang++ RUNTESTFLAGS=struct-layout-1.exp
on different architectures?
That might come up with more.
Is e.g. C++
struct A {};
struct B { [[no_unique_address]] A a; double b; };
passed by value the same between g++ 10 and latest clang++?
Jakub
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
broken threads
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 agent: User-Agent: Evolution 3.36.2 (3.36.2-1.fc32) ? I have no idea which mail the reply is for. This makes it so hard to follow the discussion. Zbyszek ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
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 to your new > patch file). A test build with the new boost and that extra fix > succeeded, so once boost-1.73.0-4.fc33 is in the buildroot you should > be able to build freecad (I am going AFK now, so won't be able to kick > off the freecad build myself). > > Once the boost build completes this will tell you when it's in the > repo: > koji wait-repo --build boost-1.73.0-4.fc33 f33-build > > And using --enablerepo=local will let local mock builds use that new > build. > > I'll check email again in a few hours. > No worries, I'll take care of the official rebuild. Thanks for the help. Thanks, RIchard ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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: > > > > > On 05.06.2020 09:52, Kevin Kofler wrote: > > > > > > I am opposed to this change. Chromium and Firefox build fine > with GCC. I > > > > > > think that a distribution should be built with a consistent > toolchain > > > > > > wherever possible. > > > > > > > > > > Clang is much better than GCC nowadays. It has better architecture, > > > > > support lots of optimizations and analyzers. > > > > > > > > > > GCC is a legacy compiler. It should be completely replaced by > Clang in > > > > > the nearest future. > > > > > > > > > > > > > Having worked in a distribution that uses Clang by default > > > > (OpenMandriva), I can say that this is *not true*. Switching from GCC > > > > to Clang cost OpenMandriva a lot of performance. It also cost them a > lot of > > > > security hardening at the compiler level. GCC-built binaries are > still > > > > better, and remain better as long as people are continually using and > > > > developing for it. > > > > > > > > This change appears to largely be driven by the maintainers of web > > > > browser packages that upstream have no GCC validation and it has to > be > > > > > > Stop this. This change is driven by the Red Hat toolchain team > > > directly, at their own realization that Fedora's compiler policy is > > > out of line with upstream reality today. They suggested it, they > > > submitted it, and they are driving it. Chromium is used as an example > > > only. Please stop gaslighting why Changes are being submitted in > > > Fedora. > > > > > > Focus on the technical merits all you want. > > > > Hi Josh, > > I think (not sure, but I do) that you misread Neal message as accusing > > the Fedora packagers of Chromium, while I think Neal was blaming > > Chromium upstream for not caring about anything bug clang and making > > life hard downstream. > > > > Precisely this. I was not accusing Fedorans of anything. And I still > think that the main motivation for the RH Tools team to propose this > is because of those specific upstreams. This stuff doesn't come out of > a vacuum after all. > > > I do not know what is what at this point, but please let's all try to > > read positive intent first and explain each other. > > > > I was particularly confused and hurt by the accusation, especially > since I almost never interact with Josh even when I want to. :( > Sincere apologies Neal. I misread, overreacted, and took out Fedora frustrations on you. I have no excuse. I'm taking a break from Fedora for a while. josh > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 > > did make it usable. And we needed some work on the DARF consumers to > > correctly process GCC 10 LTO produced DWARF (I actually have two small > > patches for elfutils pending so it correctly parses the cross CU- > > references GCC 10 LTO now produces). > > > > I don't know if anybody did any analysis on llvm LTO produced > > debuginfo. In the past it was observed that llvm doesn't do VTA (Var > > Tracking Assignments) that is default in GCC. And VTA is really > > important for debugging and performance/tracing tools like systemtap. > > So even without LTO I am concerned about the observability of llvm > > generated binaries. > > And these are reasonable concerns (even more so in an LTO world and I expect > I'll > be spending most of my summer poking at debuginfo stuff for GCC LTO :-). > > IMHO this is one of the issues an upstream project needs to evaluate for their > toolchain choice -- no different than performance, diagnostics, sanitizer > support, plug-in support, etc etc. The level of observability needed by any > particular upstream project can vary. ie, the kernel may well have different > needs than the Ruby interpreter. I think you place too much faith in upstream and give Fedora and Fedora packagers not enough credit for creating a well integrated distribution. For Fedora it is important that what we ship is observable by our users. We, together with our users, sometimes need to debug, trace or do performance analysis on the binaries as we ship them. Some upstream projects don't care about that at all. They will happily tell their users to just rebuild with some other tools/optimizations/etc. Or just rebuild their whole world with some sanitizers enabled. So then an upstream developer might prefer a different toolchain, simply because they personally would rebuild the whole world with it. In such cases Fedora should not simply switch to a non-default system compiler. > I have not done any evaluation of LLVM's debug info. I would not be > surprised if > GCC is generally better, particularly with Alex's work over the last couple > years. But again, I think the upstream project is in the best position to > determine how to balance this against the other factors in toolchain > selection. GCC's is certainly better, it has much better coverage. That doesn't mean that LLVM's debuginfo is invalid, but it is less useful. At some point the kernel accidentially disabled VTA and it made the kernel a lot less observable by systemtap for example. And even if it is correct it might still not be fully supported by all our tools. For example clang used to default to not generate .debug_aranges, which is valid, but means a DWARF consumer needs to construct its own aranges table by reading the all the CUs. elfutils doesn't support that, and so some address/line lookups simply fail with clang generated binaries. I could cerainly add support for missing .debug_aranges, but there is so much more to do (luckily I could convince them to switch the default to generate .debug_aranges, at least for rust code). In general when someone reports an issue with an elfutils or valgrind based tool and it is against code not compiled with the default gcc toolchain I simply have to tell people to please use the system compiler. There are just not enough time to also try to resolve any debuginfo issues because people use an alternative toolchain. So I like this proposal to be a bit more strict in when it is OK to not use the system toolchain. Just deferring to upstream preference seems too weak. If upstream supports building with gcc, but some upstream developers have a preference for using clang, I would prefer to make it clear that the Fedora package should keep using gcc. We simply don't have the resources for all other tools to have to deal with another toolchain. Thanks, Mark ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 packages make their own choice of compiler and > > > risk > > > running into hidden binary incompatibilities. We have a system compiler > > > for > > > a reason. > > > > I'll note that there are some even not really hidden binary > > incompatibilities, where LLVM diverges from the psABI for years, it has been > > reported and nothing has been changed. > > So if a library is built with clang/LLVM and used by GCC built package or > > vice versa, one might very well run into those (this is e.g. about passing > > std::byte or other scoped enums with char/short underlying type by value, or > > in some cases even about passing char/short arguments). > > And of course unknown ABI bugs on both sides. > > So the new policy is only for non-library packages then? > Packages which provide libraries that can be linked to by other > packages still need to use the default system compiler to make sure > there is no breakage. At least to the other packages. A package that is > build with llvm might subtly break when linked against system > libraries. No, it makes no distinction between library and other packages. 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. Perhaps you're worried about libc++ (the Clang/LLVM C++ runtime)? We don't use or support libc++ in Fedora because it is not ABI compatible with libstdc++ and an object created by one library can not be used/manipulated by the other (or instantiated templates from the other). If you're aware of ABI compatibility issues between the compilers, certainly chime in here, the appropriate BZ or to me directly. You can even raise it in the Tuesday meetings with the LLVM/GCC teams -- I'm sure that if there's an issue that both Tom and I will want to know about it. jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 > > change proposal replaces that policy with one where compiler selection > > for Fedora follows the package's upstream preferences. > > Jeff, would you please clarify in the proposal that libc++ is out of > scope (as already discussed)? > > What about compiler-rt? And lld? Any other LLVM subprojects that could > be relevant? Done. I've modified the the change request to note that it's just compiler selection and does not apply to runtimes, linkers, debuggers, etc :-) Jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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. The question that comes to my mind: > > > Should we still try to convince upstreams to use GCC in such cases > > > or > > > not? > > It happens (choosing Clang because they like it) and while we can > > (and have) > > engaged upstreams on this topic and I suspect we will continue to do > > so in some > > cases. > > > > But in the end I think we still have to respect the upstream > > project's choices, > > even if it's just because they like Clang/LLVM more than GCC. > > > > > > > > > Also does this mean that Clang is now fully supported compiler by > > > full- > > > time working people @ Red Hat in toolchains team that are also > > > contributing to upstream? Just curious if we will be able to "fully > > > support" people when we find bugs in the compiler. > > Yes. Absolutely. Tom S & Serge G directly. Others in a more > > indirect capacity. > > > > > And also, does it mean that we will be following same pattern as > > > with > > > GCC to test pre-release versions in rawhide, do the mass rebuild > > > and so > > > on? > > Some of that is already happening internally. Tom's got a tester > > which spins > > Fedora packages with Clang/LLVM. I'm not sure if he's trying to > > cover the whole > > distro, but it is running regularly (it shares a jenkins instance > > with my > > tester). > > > > > > > > > ... > > > > > > I think this is not fully true because clang / gcc produce > > > different > > > binaries in terms of size / performance. So just switching compiler > > > in > > > some package may result in significat (hopefully not) performance > > > gain > > > / drop. > > Certainly switching compilers can result in performance changes. > > Having been > > through this kind of disruptive change on the other side (GCC vs > > various vendor > > compilers through the 90s), what tends to happen is the compilers get > > to a point > > where they're typically +-5% of each other on the vast majority of > > codes. That's > > where Clang/LLVM and GCC are today based on the data I've seen. > > > > > Also we probably should mention that -fstack-clash-protection is > > > not > > > available in clang, so in theory binaries can be less secure due to > > > that. > > Clang/LLVM is closing that gap rapidly. I fully expect stack clash > > protection to > > be at parity on the relevant platforms except aarch64 by LLVM 11 and > > a reasonable > > chance to reach parity on aarch64 by LLVM 12. > > Sure thing! I just asked to have it documented that as of F33 it is not > yet implemented, but is planned to be worked on. So that users do not > expect it to have all security features built-in as on F33. Where do we want this documented? I don't mind adding verbage to the change proposal around this, but I fear that's really not the right place and the info will get lost. Perhaps make it part of the packaging guidelines change if/when we make a change? jeff > ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 between the build phase and when the > > resultant > > packages land in the distro which runs annocheck to validate options > > used, CET > > coverage across the binary, PIE, etc etc. If that annocheck run > > fails, then the > > packages are not allowed into the distribution, buildroots, etc. > > > > We flipped it on a couple years ago in the run up to RHEL 8 and it > > proved to be > > quite valuable. > > Seems like a thing we should do in Fedora CI for each update! Possibly. It requires some work on by the packagers to understand the new requirements and how to interpret the annocheck results. Nick & Florian spent countless hours working with RHEL developers to understand and fix packaging issues. But it's awful nice once it's in and everyone's updated their packages. jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-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 build phase and when the > resultant > packages land in the distro which runs annocheck to validate options > used, CET > coverage across the binary, PIE, etc etc. If that annocheck run > fails, then the > packages are not allowed into the distribution, buildroots, etc. > > We flipped it on a couple years ago in the run up to RHEL 8 and it > proved to be > quite valuable. Seems like a thing we should do in Fedora CI for each update! Thanks again for all the work on making distribution better! > Jeff > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aqYQACgkQEV1auJxc Hh5xuBAAiW2mcJsidegXZcnsI5BQanOsVlawmBi6wvZUs5oMb6QpxSrDlMGPQhBr rW+fLdcC8sHyj4sKeC3Rvc//nURiPXLEtB9MDTZVYbdnglt2dNszDIxxxYtL4ktq fd1EvFNvVtB0mdymErgv0zDIDmkJFlsjkageQ/JZBTrFozHTERQadst8QvEoXZRR EmF1WWIy4ERMKSqX3gP1QE4M0pNjwZVNT72lXjf5oUhIcYvfCwsZCacml7GT8mnt Z+2T9GX/k3DRV568LIbuO3thW+hd4GHQa3eL0l3k/NKOy7US4eDET3At64MQgox3 S+pRSNqHlerRSrrlgDkWUY5gojumN2SwESsXdgw91K53Kvw1zOdppBfp93Q1jBJm sHJQR6yQZzh+9Ucn9ayFHE4pX9Zuvmi/93FiQ1sXSJXAvCEbKkCnMfeYVPCHkM6P d7jFvtbjq0Psl7qjV8ydYtUnNKrSzc/TnnrHbYwCxJ15rdVRKJ/TVV5P+M28+jh+ L+EW1niJpHN5ixgBy4N8OOUwzNi7Y9F9mhF7dLQHUN2rHharVikPfath/KoQ1L6D RYwPkpinn3ffw7FQX/9h3BdhxAF9M0W6/9NUoJwT5TB7v3yRtXbKNakT2BTJN/2z 9GK7szXrO35wHpebpQgjVTY96wZK6ieYiOVzIIyk1O6msBwKpB8= =miEX -END PGP SIGNATURE- ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: System-Wide Change proposal: CompilerPolicy Change
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 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 > > > 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 clients that support > > > this) ... > > > Right now, this is the 16th thread for this topic in my inbox. It > > > makes it *really really hard* to follow the discussion. > > Yea. Dominique and Florian have both reached out to me privately. It's an > > artifact of consuming the list in -digest form and evolution not having a > > way to > > explode the digest for individual replies AFAICT. > > > > I'm using Dominique's suggestion and hoping it helps, though it is somewhat > > painful. Thankfully I don't (usually) have to interact a lot on > > fedora-devel so > > just short term pain for me as we figure out if/how to move forward on the > > compiler stuff. > > I am glad I resisted till this point, as I was going to be the Nth to > contact you privately about it :-) No worries. I'll spare the list my frustrations with MUAs and desire to return to CLI MH :-) > > One way you could use, if it works better, is to import archives and > then reply from there, not sure if this is any less painful then > replying from hyperkitty. > > Another way is to subscribe to the full list instead of digest but have > an aggressive archive policy in evolution to clean your fedora-devel > folder (see auto-archive in folder properties). It may be easiest to just subscribe in the normal way for the duration of this discussion and return to a digest once the issues relevant to me have died down to the usual trickle. Jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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, CET coverage across the binary, PIE, etc etc. If that annocheck run fails, then the packages are not allowed into the distribution, buildroots, etc. We flipped it on a couple years ago in the run up to RHEL 8 and it proved to be quite valuable. Jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 am opposed to this change. Chromium and Firefox build fine with > > > > > GCC. I > > > > > think that a distribution should be built with a consistent toolchain > > > > > wherever possible. > > > > > > > > Clang is much better than GCC nowadays. It has better architecture, > > > > support lots of optimizations and analyzers. > > > > > > > > GCC is a legacy compiler. It should be completely replaced by Clang in > > > > the nearest future. > > > > > > > > > > Having worked in a distribution that uses Clang by default > > > (OpenMandriva), I can say that this is *not true*. Switching from GCC > > > to Clang cost OpenMandriva a lot of performance. It also cost them a lot > > > of > > > security hardening at the compiler level. GCC-built binaries are still > > > better, and remain better as long as people are continually using and > > > developing for it. > > > > > > This change appears to largely be driven by the maintainers of web > > > browser packages that upstream have no GCC validation and it has to be > > > > Stop this. This change is driven by the Red Hat toolchain team > > directly, at their own realization that Fedora's compiler policy is > > out of line with upstream reality today. They suggested it, they > > submitted it, and they are driving it. Chromium is used as an example > > only. Please stop gaslighting why Changes are being submitted in > > Fedora. > > > > Focus on the technical merits all you want. > > Hi Josh, > I think (not sure, but I do) that you misread Neal message as accusing > the Fedora packagers of Chromium, while I think Neal was blaming > Chromium upstream for not caring about anything bug clang and making > life hard downstream. > Precisely this. I was not accusing Fedorans of anything. And I still think that the main motivation for the RH Tools team to propose this is because of those specific upstreams. This stuff doesn't come out of a vacuum after all. > I do not know what is what at this point, but please let's all try to > read positive intent first and explain each other. > I was particularly confused and hurt by the accusation, especially since I almost never interact with Josh even when I want to. :( -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 > normally that high. If it weighs as much as a duck, it's a witch and we should burn it! In all the emails you've written, John, you could have this installed and working by now, and you'd have a much better idea of how this magic isn't really magic. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-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 wrote: > > > > > > > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr < > > > > joh...@splentity.com> > > > > 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 inactive anonymous page > > > > > > eviction, > > > > > > including reducing reclaim of file pages, without the black > > > > > > hole > > > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the > > > > > Server > > > > > image > > > > > right now, and go with its automatic partitioning scheme > > > > > generation, > > > > > it'll give you a swap partition on LVM. This is correct for > > > > > most > > > > > servers, > > > > > not necessarily the LVM part, but having swap on disk. > > > > > > > > > > > > > > > > > > > > The proposal recommends changing this. Cloud and Server folks > > > > will > > > > decide what's best for their use cases, not me. > > > > > > > > > > > > In that case, would you be open to changing this proposal to only > > > affect > > > Workstation? > > > > > > I think it is fine to have the proposal as it is. Those groups will > > chime in if they do not like this approach. Having things > > consistent > > across editions (in this regard) makes more sense to me tbh. > > What makes sense for desktops doesn't necessarily make sense for > servers, or > other environments. Fedora isn't just a desktop distro. Additionally, > what > GNOME folks believe to be best is normally not the best for other > desktop > environments. Can you be more specific about potential problems you see in other use- cases like server? > -- > John M. Harris, Jr. > > ___ > 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-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7appIACgkQEV1auJxc Hh5Dqw/+MbNqLrRDJb+cYb61f9+M/lvvDIV2OOoYDggchn+gQfUZbW5oEuMUzJY1 zBCqGUzm0nQovKXZtVigBTcLIW2rl7x9PNrDkF1yI6YpeZ52lQFeC+WlETaOs7f9 KaF6MRfjKY+w1qEX8zDnvA0lCjZJUkreoPI6YanQ6/GvX6bCABF3QjEEGjQNNcKL R6BKFdBKTvI1YHb2lPwNNlK8bDi+IBuEZ466WhaT/tDfGtnvHU6XVYzSwle8W5br W0W13xwH/K/40rgff32TFUoczDgB0XzwtEJ6UkJBUjQJV/mSHRuIa7Bwev8BbuNX Lik1lEQHAWvAyxCAuVrq45d0dzxHpYHwSp1tKaDZgbn8T0NDIZOJNn1q8T9OFhnM ZnnX3TOX2Ey9CaDFCnI6aca4LrRrkdSbcuwwtfefl+zlFqdfMHaBFS+6afMvYLDk JfYGVVwg2wKxX9a8YYFAMFshFjbDRT0lKDg+yhvxCdKjzvAxi0bR+7cEbw/NamR6 NTxsDwG8HNNYMHD8JOM3230uSK22bX1x9c4xzaAgOTtmG6StnekS8nLXs/kZBr1I hXyJ58+dCsh0podC7Sanz+XeFdMtxqQN+8Y0KDDY18sA+wYQwt/5GpkWEk4JPrF4 H2mT7hqm7gNAscXdxAl4b6/yjHR57B5sV2/AU+/XBLIH5JTDuMc= =bmkv -END PGP SIGNATURE- ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: System-Wide Change proposal: CompilerPolicy Change
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 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 > > 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 clients that support > > this) ... > > Right now, this is the 16th thread for this topic in my inbox. It > > makes it *really really hard* to follow the discussion. > Yea. Dominique and Florian have both reached out to me privately. It's an > artifact of consuming the list in -digest form and evolution not having a way > to > explode the digest for individual replies AFAICT. > > I'm using Dominique's suggestion and hoping it helps, though it is somewhat > painful. Thankfully I don't (usually) have to interact a lot on fedora-devel > so > just short term pain for me as we figure out if/how to move forward on the > compiler stuff. I am glad I resisted till this point, as I was going to be the Nth to contact you privately about it :-) One way you could use, if it works better, is to import archives and then reply from there, not sure if this is any less painful then replying from hyperkitty. Another way is to subscribe to the full list instead of digest but have an aggressive archive policy in evolution to clean your fedora-devel folder (see auto-archive in folder properties). HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-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 "upstream knows > > > better" > > > where I would have to disagree with you. > > > > Yes, this is a very good point. > > > > Many of Fedora's packages have upstreams that are not using the > > latest > > compilers, libraries, security features etc. > > > > Just because upstream hasn't been updated to work with compiler > > hardening features doesn't mean we should disable those features. > > Just > > because upstream's code is not portable to more than one compiler > > doesn't mean we shouldn't send them bugs (or better still, > > patches).<> > Right. Though I think the security side of this largely belongs in > redhat-rpm- > config and moving annobin/annocheck into an enforcement role (like > we've done > with RHEL). > > We did this for RHEL and while painful, getting the vast majority of > packages to > honor the flags injection and verification via annobin/annocheck > before the > resultant packages can be included in the distro has been a big win > and enables > us to do a lot of useful things knowing that the flags injection > works well. > > Fedora is behind on this. While most packages honor flags injection, > we don't > actually know which do not (either by accident or design) and we > don't have a way > to easily find them. So things like CET in enforcing mode by > default are going > to be harder to achieve in Fedora than in RHEL. But like so many > things, I don't > have the time to push on something like this for Fedora. Just curious, how is it done in RHEL? Just some kind of CI that analyses all builds or? > Jeff > ___ > 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-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7apgkACgkQEV1auJxc Hh5dhxAAk6g0ayGwzp9gg0P7LiNv1bfk9yFKMI/cI9ToFi2D3bzOCMomvorDui15 EbRZ+YeBB0aMt8OFMKDFwrLpL6dz9rfjxUi5XLuuUzvhpWpgfi4hDJSM8wY3vT5q vEKLCUi/pSGTIRkAYWnxmrJh7XaUIhuQS4FOWId0rzx++7ywPXKCcimMEmR5PnfU qVA1ulPsWrMZVQIiAM4EecJtHTlBKS8kVv5LecZmx0kqNeiiXFnBhThpTiM5LJJX xLhDGYWRKLPHCCKTBbi1nmN+AC71rEikQykry6XruiHFJUrimKdRytP3wdio89ox cbMbinZolYyHUo9aqN/Mqz1diIAoJsQhZ47RQY78lVnR5D78hUYzFCxg4dYQJp2r U0eOwe8Pd4lZxnpEt3Cegyn/2BlEViQPZvBLZa1yzJ5wpMapcqwNTYsv/H5h8Cj5 UpVzBT6/wbsJA528cpqpb3xZuR97M39dHJac1gs9UWXQlu4oM32A59nuHQKhVYxn ZCmiyLg7yl96tgvE/ilDZrsVA84CC2GY9yZY7FHEFEO+WAAIVUUwTCIsyJXAmMzR VWxuCv00ho78wT+UROaFBhYbjaSQJyrTgITpKBRD/Pcim7rO1PIisOg1bVZgTlZd xPcHCzjMGJ6idrROlGlgmj0Mqj7x9fUqEsxqlNSd3QO8NF/GPNY= =S+0b -END PGP SIGNATURE- ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 > > cause OOM. > > Either you did not read the page or I misunderstand how zram works. It > will take 3G of your memory and call it a SWAP. With a compression. So > essentially, if the starts will be aligned you will end up with 9G of > memory. Of course, if that is not enough, you can add on top of that > swap on the disk. That's basically correct. But that 3G swap when full is not free, it costs 1.5G RAM. It is true that the efficacy of swap-on-zram is not 100% eviction. It's contingent on the compression ratio. If it's 2:1, the swap-on-zram eviction efficacy is 50%. The memory cost is 1/2 of the savings. So you save 1/2. If the compression is 3:1 (which I often see but safer to promote 2:1), 3G /dev/zram0 with full swap costs 1G RAM, saving 2G. Efficacy is ~67%. It is super easy to get confused about this, part of which is it seems like magicsauce, and thus impossible witchcraft. I spent quite a lot of time wrapping my head around this. And it wasn't hours. It was days. I won't admit how many days. Could there be workloads that get close to 1:1 compression? I don't know. I haven't seen it. A synthetic test filling up anonymous pages from /dev/urandom should do this. As a workload gets closer to zero compression, the setup behaves more like noswap. It's not worse than noswap, but it would be worse than disk based swap. Still, it's way faster, so you don't see the swap thrashing. I think such a contrived test could be worth doing just to understand what happens in practice, not just in theory. And also? In a year? No kernel panics. So this code is rather robust. The manifestations will be in user space. And I've also tested this with and without earlyoom, for many months each. And have run webkitgtk compile while giving Firefox 80 tabs. And it is possible with a zram device set to 100% RAM to get into a kind of nutty CPU/memory based thrashing that doesn't end for a long time - which is no different than the same set up with disk based swap, except it lasts even longer to oom and is IO bound. So far, the worst case is that it doesn't make things better. I haven't yet seen it make things worse. But they probably exist, they're just edge cases. And for those workloads, zswap is likely a better way to spill over onto a disk based swap partition, while still getting the benefits of a memory cache. Another likely bad case, is simply overcommitting the system, by making it do something it flat out has insufficient resources for. We know the kernel lacks use space interactivity guarantees. This problem is part of on-going cgroupsv2 resource control to isolate processes that are essentially runaway, and we'll see more of that work in the near future too, both GNOME and KDE. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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...@splentity.com> 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 < mcatanz...@gnome.org> 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 was to get rid of the disk-based swap partition, since it has an unacceptable impact on system responsiveness? Default new installations, yes. No disk-based swap partition. For upgrades, there's no mechanism to remove an existing swap-on-drive. And the installer will still permit swap-on- drive being added in custom partitioning. Both of these paths results in two swap devices. We could ask Anaconda, if a custom installation creates swap- on-disk, to remove /etc/systemd/zram-generator.conf. And in that case, users will not get swap-on-zram. And we could also forgo the change being applied on upgrades. It may be best to respect the user's decision, and not add a zram device on upgraded systems. This would lead to less unexpected behavior. I'd support that, for sure :) Contra argument: It also leads to fragmentation of the user base. Most users use a distribution because they trust the decisions. And while it is only a preference, not a policy the Workstation Product Requirements Document says "Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation." There is a balancing act here that should be considered because a large percent of Fedora users upgrade rather than reprovision. It might even be the majority case. 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 zram device. That'd be a nice middleground for users like myself that don't have enough RAM to waste on a zram device. 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 cause OOM. Either you did not read the page or I misunderstand how zram works. It will take 3G of your memory and call it a SWAP. With a compression. So essentially, if the starts will be aligned you will end up with 9G of memory. Of course, if that is not enough, you can add on top of that swap on the disk. 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 normally that high. Erm, just plain zip reaches 1:3 compression for standard English plain text. And in my tests of zram running a full gnome desktop + firefox it reaches about 1:3 too. I actually started looking into zram after talks with some Endless engineers, which are using zram on all the devices they ship and they too were seeing 1:3 compression ratios a lot of apps do not make very efficient use of RAM, so usually it is quite compressible. I have been enabling ZRAM by default on all my devices for a while now. Also I must say that you being so stubborn on this, either not reading up on it, or refusing to understand how it works is getting really tiresome. You seem to insist on having an opinion on this, even though you have never tried it! You should really actually give zram a serious try and refrain from commenting on this thread until you have actually tried zram and given it a fair chance. As Chris has already said something like your ThinkPad X200 Tablet with 6 GiB of RAM is more or less exactly what this is for. Well mostly it is for machines with even less RAM, but it can help your case too. Regards, Hans ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: System-Wide Change proposal: CompilerPolicy Change
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. > > 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 clients that support > this) ... > Right now, this is the 16th thread for this topic in my inbox. It > makes it *really really hard* to follow the discussion. Yea. Dominique and Florian have both reached out to me privately. It's an artifact of consuming the list in -digest form and evolution not having a way to explode the digest for individual replies AFAICT. I'm using Dominique's suggestion and hoping it helps, though it is somewhat painful. Thankfully I don't (usually) have to interact a lot on fedora-devel so just short term pain for me as we figure out if/how to move forward on the compiler stuff. jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 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 inactive anonymous page eviction, > > > > > including reducing reclaim of file pages, without the black > > > > > hole > > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the Server > > > > image > > > > right now, and go with its automatic partitioning scheme > > > > generation, > > > > it'll give you a swap partition on LVM. This is correct for most > > > > servers, > > > > not necessarily the LVM part, but having swap on disk. > > > > > > > > > > > > > > > The proposal recommends changing this. Cloud and Server folks will > > > decide what's best for their use cases, not me. > > > > > > > > In that case, would you be open to changing this proposal to only > > affect > > Workstation? > > > I think it is fine to have the proposal as it is. Those groups will > chime in if they do not like this approach. Having things consistent > across editions (in this regard) makes more sense to me tbh. What makes sense for desktops doesn't necessarily make sense for servers, or other environments. Fedora isn't just a desktop distro. Additionally, what GNOME folks believe to be best is normally not the best for other desktop environments. -- John M. Harris, Jr. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
> 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 Fedora's packages have upstreams that are not using the latest > compilers, libraries, security features etc. > > Just because upstream hasn't been updated to work with compiler > hardening features doesn't mean we should disable those features. Just > because upstream's code is not portable to more than one compiler > doesn't mean we shouldn't send them bugs (or better still, patches).<> Right. Though I think the security side of this largely belongs in redhat-rpm- config and moving annobin/annocheck into an enforcement role (like we've done with RHEL). We did this for RHEL and while painful, getting the vast majority of packages to honor the flags injection and verification via annobin/annocheck before the resultant packages can be included in the distro has been a big win and enables us to do a lot of useful things knowing that the flags injection works well. Fedora is behind on this. While most packages honor flags injection, we don't actually know which do not (either by accident or design) and we don't have a way to easily find them. So things like CET in enforcing mode by default are going to be harder to achieve in Fedora than in RHEL. But like so many things, I don't have the time to push on something like this for Fedora. Jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-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 comes to my mind: > > Should we still try to convince upstreams to use GCC in such cases > > or > > not? > It happens (choosing Clang because they like it) and while we can > (and have) > engaged upstreams on this topic and I suspect we will continue to do > so in some > cases. > > But in the end I think we still have to respect the upstream > project's choices, > even if it's just because they like Clang/LLVM more than GCC. > > > > > > > Also does this mean that Clang is now fully supported compiler by > > full- > > time working people @ Red Hat in toolchains team that are also > > contributing to upstream? Just curious if we will be able to "fully > > support" people when we find bugs in the compiler. > Yes. Absolutely. Tom S & Serge G directly. Others in a more > indirect capacity. > > > > > And also, does it mean that we will be following same pattern as > > with > > GCC to test pre-release versions in rawhide, do the mass rebuild > > and so > > on? > Some of that is already happening internally. Tom's got a tester > which spins > Fedora packages with Clang/LLVM. I'm not sure if he's trying to > cover the whole > distro, but it is running regularly (it shares a jenkins instance > with my > tester). > > > > > ... > > > > I think this is not fully true because clang / gcc produce > > different > > binaries in terms of size / performance. So just switching compiler > > in > > some package may result in significat (hopefully not) performance > > gain > > / drop. > Certainly switching compilers can result in performance changes. > Having been > through this kind of disruptive change on the other side (GCC vs > various vendor > compilers through the 90s), what tends to happen is the compilers get > to a point > where they're typically +-5% of each other on the vast majority of > codes. That's > where Clang/LLVM and GCC are today based on the data I've seen. > > > > > Also we probably should mention that -fstack-clash-protection is > > not > > available in clang, so in theory binaries can be less secure due to > > that. > Clang/LLVM is closing that gap rapidly. I fully expect stack clash > protection to > be at parity on the relevant platforms except aarch64 by LLVM 11 and > a reasonable > chance to reach parity on aarch64 by LLVM 12. Sure thing! I just asked to have it documented that as of F33 it is not yet implemented, but is planned to be worked on. So that users do not expect it to have all security features built-in as on F33. > > > > > ... > > > > I think this should mention that annobin plugin should be prepared > > for > > clang. > Nick Clifton is already working on that :-) > > Jeff > ___ > 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-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aol8ACgkQEV1auJxc Hh5p+w//XQ32GF4YUnJUXbzQzquqogtmnr+wPcfsY9ZsjTR2PRQUhq+C0JV2ipf3 esitrJQlLPsBfU1pyxRT3ISFQZp4/RR6OtUddMPGS0TDj1UMyyBfuuRC+LKpm4wV MoYsOByMlKEZxeqHe2fKvWvxtcXhe1ocFaqpA3lJAPIxAg3UhjiZzqW7UjqqWQVI wC/Ap5BPSyNUH1QAtkfC98q58YNkMtm3YzUGHfebpp608gNgUzk/R8iE/Is+pHC0 laqiGpnhj8y2jwjqkBSc2sZhgwqYOYYPYy61YhouyNLNin5PqDA1dSBcnrNFXmHv gai1a9uHvN/jYUfDmpgE8TaO4EvWIncnlQV7E7SuH8X48nXNzYjqZl1CRj3bkAm6 kE/ZASmTE9p9aNrq5c7YnQy16zgX/jFVZuge4yKvJFfCZSSwMOPizVAMS2eVjBUG ToJE7q2YmGIwwqjX4W59HElCQXTwK4Yrscr5j9F5mJH+IOzOXuu3tW+XyeX6cjs6 OnyeXGJ1lojO5jBIC6PPJ5KtSFUBjOFyQqJb8ydYGdtwFXgjGDYxiBwJEASo00yE Gx1wpkIhQYGdglbDhVk8qd01S4c2IVpsb0ezGL2Irr0TKAtkFw9N6KM04hNf6zyH RdfTNrdJvNwR2QfyOdhWIRsdjI8/EnacZzORKOQ1pouldEuHQv4= =shcY -END PGP SIGNATURE- ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 an RFE for this already at zram-generator github. There is zstd support in our kernels now so that would be good to compare, I'm seeing impressive results but as this is workload-dependent it is hard to test from an objective point of view, but this is rather impressive: # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 zstd1G 753.4M 150.6M 158.8M 8 [SWAP] (enabled 15 or so days ago manually; according to smem I have bits of qemu, firefox, libreoffice, xorg, urxvt and most of lightdm, sd-pam, rpc.mountd.. in swap so it is quite varied) Either way +1 from me, I've just installed the generator and manually set the limit to 4G/0.5 as suggested in the change; I think such a config file should be added to the f32 rpm so people can try more easily to convince themselves with the actual config that would be installed. Cheers, -- Dominique ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 GCC. I > > > > think that a distribution should be built with a consistent toolchain > > > > wherever possible. > > > > > > Clang is much better than GCC nowadays. It has better architecture, > > > support lots of optimizations and analyzers. > > > > > > GCC is a legacy compiler. It should be completely replaced by Clang in > > > the nearest future. > > > > > > > Having worked in a distribution that uses Clang by default > > (OpenMandriva), I can say that this is *not true*. Switching from GCC > > to Clang cost OpenMandriva a lot of performance. It also cost them a lot of > > security hardening at the compiler level. GCC-built binaries are still > > better, and remain better as long as people are continually using and > > developing for it. > > > > This change appears to largely be driven by the maintainers of web > > browser packages that upstream have no GCC validation and it has to be > > Stop this. This change is driven by the Red Hat toolchain team > directly, at their own realization that Fedora's compiler policy is > out of line with upstream reality today. They suggested it, they > submitted it, and they are driving it. Chromium is used as an example > only. Please stop gaslighting why Changes are being submitted in > Fedora. > > Focus on the technical merits all you want. Hi Josh, I think (not sure, but I do) that you misread Neal message as accusing the Fedora packagers of Chromium, while I think Neal was blaming Chromium upstream for not caring about anything bug clang and making life hard downstream. I do not know what is what at this point, but please let's all try to read positive intent first and explain each other. sincerely, Simo. > josh > > > done in Fedora downstream. I know Chromium is a lost cause (Google > > couldn't possibly care any less than they do now, especially since > > they don't even care about Python 2 being EOL), but has anyone talked > > to Mozilla about introducing GCC-based CI for Firefox code? I assume > > they have a CI infrastructure that's relatively pluggable. > > > > 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. > > > > I would rather see us still *strongly prefer* GCC rather than allowing > > this to be freely changeable at a whim. > > > > > > > > -- > > 真実はいつも一つ！/ Always, there's only one truth! > > ___ > > 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-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > 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-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 convince upstreams to use GCC in such cases or > > not? > It happens (choosing Clang because they like it) and while we can (and have) > engaged upstreams on this topic and I suspect we will continue to do so in > some > cases. > > But in the end I think we still have to respect the upstream project's > choices, > even if it's just because they like Clang/LLVM more than GCC. Why? Shouldn't the Fedora maintainers be able to decide this? If they have been using GCC for years and it hasn't been an obstackle for them, why should they switch? If I understand the LO case, it is just that LO sometimes uses the Skia library which is written by Google and Google likes compiler monoculture and is using heavily #ifdef __clang__ in it and using the clang variants of the generic vectors guarded by that, and as fallback just doesn't use simd. I believe Honza Hubicka had quite some changes for Skia, not sure if they went upstream already or not. But the maintainers should be able to choose, build just Skia with clang and rest of LO with GCC, or everything with GCC and with help from us get Skia into shape for better portability (that would be ideal, but of course can mean more hopefully one time work), or build all of it with Clang/LLVM. Jakub ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20200605.n.0 changes
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:161.18 KiB Size of upgraded packages: 1.41 GiB Size of downgraded packages: 17.61 MiB Size change of upgraded packages: 10.85 MiB Size change of downgraded packages: 127.55 KiB = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: fswatch-1.14.0-3.fc33 Summary: A cross-platform file change monitor RPMs:fswatch fswatch-devel fswatch-static Size:2.20 MiB Package: golang-github-dustinkirkland-petname-0-0.1.20200605git8e5a1ed.fc33 Summary: An RFC1178 implementation RPMs:golang-github-dustinkirkland-petname golang-github-dustinkirkland-petname-devel Size:3.30 MiB Package: golang-github-gehirninc-crypt-0-0.3.20200605gitbb7000b.fc33 Summary: Pure Go crypt(3) Implementation RPMs:golang-github-gehirninc-crypt-devel Size:22.15 KiB Package: golang-github-haproxytech-config-parser-2.0.2-1.fc33 Summary: HAProxy configuration parser RPMs:compat-golang-github-haproxytech-config-parser-2-devel golang-github-haproxytech-config-parser-devel Size:106.61 KiB Package: golang-github-haproxytech-models-2.0.2-1.fc33 Summary: HAProxy Go structs for API RPMs:compat-golang-github-haproxytech-models-2-devel golang-github-haproxytech-models-devel Size:59.98 KiB Package: golang-github-masterzen-simplexml-0-0.1.20200604git31eea30.fc33 Summary: Go library to generate XML content from a naive DOM RPMs:golang-github-masterzen-simplexml-devel Size:15.48 KiB Package: python-beautifultable-0.8.0-2.fc33 Summary: Print ASCII tables for terminals RPMs:python-beautifultable-doc python3-beautifultable Size:215.43 KiB Package: python-jaraco-envs-2.0.0-1.fc33 Summary: Classes for orchestrating Python (virtual) environments RPMs:python-jaraco-envs-doc python3-jaraco-envs Size:151.14 KiB Package: python-testfixtures-6.14.1-1.fc33 Summary: A collection of helpers and mock objects for unit tests RPMs:python3-testfixtures Size:188.90 KiB Package: rust-wayland-scanner-0.26.6-1.fc33 Summary: Wayland Scanner for generating rust APIs from XML wayland protocol files RPMs:rust-wayland-scanner+default-devel rust-wayland-scanner-devel Size:31.71 KiB Package: rust-wayland-sys-0.26.6-1.fc33 Summary: FFI bindings to the various libwayland-*.so libraries RPMs:rust-wayland-sys+client-devel rust-wayland-sys+cursor-devel rust-wayland-sys+default-devel rust-wayland-sys+dlib-devel rust-wayland-sys+dlopen-devel rust-wayland-sys+egl-devel rust-wayland-sys+lazy_static-devel rust-wayland-sys+libc-devel rust-wayland-sys+server-devel rust-wayland-sys-devel Size:82.27 KiB = DROPPED PACKAGES = Package: boost-nowide-0-20190814.gitec9672b.fc32 Summary: Boost.Nowide makes cross platform Unicode aware programming easier. RPMs:boost-nowide boost-nowide-devel boost-nowide-docs Size:161.18 KiB = UPGRADED PACKAGES = Package: ImageMagick-1:6.9.11.16-1.fc33 Old package: ImageMagick-1:6.9.10.86-3.fc33 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs ImageMagick-perl Size: 40.03 MiB Size change: 34.38 KiB Changelog: * Wed Jun 03 2020 Michael Cronenworth - 1:6.9.11.16-1 - Update to 6.9.11.16 - Drop extra BRs on -devel package (RHBZ#1835344) Package: Lmod-8.3.14-1.fc33 Old package: Lmod-8.3.13-1.fc33 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.05 MiB Size change: 671 B Changelog: * Fri Jun 05 2020 Orion Poplawski - 8.3.14-1 - Update to 8.3.14 Package: adwaita-icon-theme-3.37.2-1.fc33 Old package: adwaita-icon-theme-3.36.1-1.fc33 Summary: Adwaita icon theme RPMs: adwaita-cursor-theme adwaita-icon-theme adwaita-icon-theme-devel Size: 11.21 MiB Size change: 6.73 KiB Changelog: * Thu Jun 04 2020 Kalev Lember - 3.37.2-1 - Update to 3.37.2 Package: antlrworks-1.5.2-16.fc33 Old package: antlrworks-1.5.2-14.fc32 Summary: Grammar development environment for ANTLR v3 grammars RPMs: antlrworks Size: 1020.27 KiB Size change: 27.68 KiB Changelog: * Sat Apr 25 2020 Fabio Valentini - 1.5.2-15 - Remove unnecessary dependency on deprecated parent pom. * Wed Jun 03 2020 Fabio Valentini - 1.5.2-16 - Override javac source and target version to fix builds using Java 11. Package: awscli-1.18.73-1.fc33 Old package: awscli-1.18.70-1.fc33 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.75 MiB Size change: -542 B Changelog: * Thu Jun 04 2020 Gwyn Ciesla - 1.18.72-1 - 1.18.72 * Fri Jun 05
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
> -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 (maintainers are as well developers in upstream and > work full-time on this, development versions are being tested in > rawhide early, etc…) I do not see a reason to disallow that. Yup. As mentioned in my previous message. Tom S in Red Hat's LLVM lead with Serge G. directly contributing to LLVM and a couple others that are more indirect contributors. > > - From the security features, do you have some specifics in mind? I saw > only from our CFLAGS/LDFLAGS, only the -fstack-clash-protection is not > yet supported, but it is being worked on (already in trunk, though only > for x86). As mentioned elsewhere, LLVM 10 adds x86_64, LLVM 11 should add Power and Z and LLVM 12 adding AArch64. > > ... > > Well, if they are supported in the same way as GCC (in the sense as it > is not just being packaged in Fedora, but developed and properly tested > in Fedora), why not to declare that we have 2 system compilers? > Regarding hidden binary incompatibilities, those are the bugs that > needs to be fixed so I assume if maintainers of clang make commitment, > they will have to fix it because Clang will be 2nd system compiler. Precisely. I think between Tom & Serge with direct upstream work and my contacts into the LLVM groups at IBM and ARM I'm confident we'll be able to deal with issues. Or to look at it another way. Red Hat's supported offerings already include full support for Clang/LLVM (using libstdc++, not libc++) and GCC. They have to work and they have to work together. Red Hat is already in a dual compiler world. Jeff > ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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: > > > > > > > > > > > > > > > > > > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro < > > > > > mcatanz...@gnome.org> > > > > > 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 was to get rid of the disk-based swap > > > > > > partition, > > > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > > > swap-on-drive. And the installer will still permit swap-on- > > > > > drive being > > > > > added in custom partitioning. Both of these paths results in > > > > > two swap > > > > > devices. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap- > > > > > on-disk, > > > > > to remove /etc/systemd/zram-generator.conf. And in that case, > > > > > users > > > > > will not get swap-on-zram. And we could also forgo the change > > > > > being > > > > > applied on upgrades. > > > > > > > > > > > > > > > > > > > > > > > > It may be best to respect the user's decision, and not add a zram > > > > device > > > > on upgraded systems. This would lead to less unexpected behavior. > > > > I'd > > > > support that, for sure :) > > > > > > > > > > > > > > > Contra argument: It also leads to fragmentation of the user base. > > > Most > > > users use a distribution because they trust the decisions. And > > > while > > > it is only a preference, not a policy the Workstation Product > > > Requirements Document says "Upgrading the system multiple times > > > through the upgrade process should give a result that is the same > > > as > > > an original install of Fedora Workstation." > > > > > > > > > > > > There is a balancing act here that should be considered because a > > > large percent of Fedora users upgrade rather than reprovision. It > > > might even be the majority case. > > > > > > > > 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 zram device. That'd be a nice middleground for > > users like > > myself that don't have enough RAM to waste on a zram device. 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 > > cause OOM. > > > Either you did not read the page or I misunderstand how zram works. It > will take 3G of your memory and call it a SWAP. With a compression. So > essentially, if the starts will be aligned you will end up with 9G of > memory. Of course, if that is not enough, you can add on top of that > swap on the disk. 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 normally that high. -- John M. Harris, Jr. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-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 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 inactive anonymous page eviction, > > > > including reducing reclaim of file pages, without the black > > > > hole > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the Server > > > image > > > right now, and go with its automatic partitioning scheme > > > generation, > > > it'll give you a swap partition on LVM. This is correct for most > > > servers, > > > not necessarily the LVM part, but having swap on disk. > > > > > > The proposal recommends changing this. Cloud and Server folks will > > decide what's best for their use cases, not me. > > In that case, would you be open to changing this proposal to only > affect > Workstation? I think it is fine to have the proposal as it is. Those groups will chime in if they do not like this approach. Having things consistent across editions (in this regard) makes more sense to me tbh. > -- > John M. Harris, Jr. > > ___ > 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-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7an1kACgkQEV1auJxc Hh5Ezg/+PrFUmkHOc46SKgDIMa5x3w/SCHOF3VKhpvN4bQ6WWY+HpJhmsh92dvle ogYnseXIl2wuOyCr75vIMXpuyvBGoZMBlFJmQZG5+2jABJ1/DZ+MyyYgpBWZtkPs QUoNs03pJ70DHuLjakv4mX9nbXqHPBwOzlQuk07ivdVoj6qTXDhkSpJCBULlBm/N QsHCIPOoP7Hmu5AZuNopjgzvlr9Ezt3ra/SM65hSxJDNl2Pn/Piex4A35i8+WHgs iWCvH04iF/+iLt6V09Rya2d+9xWary05DtZdmIRbsR2IjgoYIWtOwC1rp8DsRcL/ nsRODfQuMbP7HB2IihpWIF4A9PATcVP1r+DE7NtlLdSERqrSbTvKcycbsbGww/7b 9IZhhNSRJ0CH4xyRW7R9E6mRHR8K9uYykD8t0eWS7dIlw7mIbDZnwjHYRu1qlQzK OdgPZkpY9aZkAWWA5iFE3pWIYYmCkRwPPytxFVH4adEqSo0i5xJs0bmbHowthVZ0 zjLQRv/LNxZJTedKgCyLtEt9fb0Gza/8+zrlcmYC1Ahq9+NSWYalFMwRJunRL95b L9NlTQ8qYUZEAQM9zIL4ULjniUL9lNuq5GIH9OE3JdCvtNY78Ml4u9GjRRX+HwjX 22MQqgNdXQ5tWvcJo2gRDSaUzpIENVvPwY8mUwoEuN4ceYVgnvw= =RlRQ -END PGP SIGNATURE- ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-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 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > > > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro < > > > > mcatanz...@gnome.org> > > > > 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 was to get rid of the disk-based swap > > > > > partition, > > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > > swap-on-drive. And the installer will still permit swap-on- > > > > drive being > > > > added in custom partitioning. Both of these paths results in > > > > two swap > > > > devices. > > > > > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap- > > > > on-disk, > > > > to remove /etc/systemd/zram-generator.conf. And in that case, > > > > users > > > > will not get swap-on-zram. And we could also forgo the change > > > > being > > > > applied on upgrades. > > > > > > > > > > > > It may be best to respect the user's decision, and not add a zram > > > device > > > on upgraded systems. This would lead to less unexpected behavior. > > > I'd > > > support that, for sure :) > > > > > > Contra argument: It also leads to fragmentation of the user base. > > Most > > users use a distribution because they trust the decisions. And > > while > > it is only a preference, not a policy the Workstation Product > > Requirements Document says "Upgrading the system multiple times > > through the upgrade process should give a result that is the same > > as > > an original install of Fedora Workstation." > > > > There is a balancing act here that should be considered because a > > large percent of Fedora users upgrade rather than reprovision. It > > might even be the majority case. > > 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 zram device. That'd be a nice middleground for > users like > myself that don't have enough RAM to waste on a zram device. 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 > cause OOM. Either you did not read the page or I misunderstand how zram works. It will take 3G of your memory and call it a SWAP. With a compression. So essentially, if the starts will be aligned you will end up with 9G of memory. Of course, if that is not enough, you can add on top of that swap on the disk. > -- > John M. Harris, Jr. > > ___ > 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-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7anxkACgkQEV1auJxc Hh6kqg//a/iT6Cdeg9ZJrfuj/0xWerydUtwRwveG1GoUp6gHK92rDlADWreOpKtw p+aGbG/L01Mp4KrNJdwND4/5iy8F7/kB8DfBoEGVT7BNg2KRh/OQLmA5r0LVn6RE lEk+BbwDhHEsZoQQH5bicvMEMwO2J+kUL9edAH2ZW6ZQrsXilXIJxogUUuAoR9fH EaqadUaF5eWK3qf1HbMV5ffcraN6de+MYxA1C4peQoq5Dr8FPxjoZTl9ECtRMlpw 5utWnwwQZAQ9SDXyiIP1oJ3s+iR34eDwXr2V8Aq1940hoGbPsAOH1n6DNWkKULPq 6cnZE6tcCIu0bP3Gh7pmmtUZprK5yvIqdgGRXP+nImEXT0AevH3R/VTEsVQsL6f1 Qu4+MbsC5+hfHUj1JX9M2TDYztCtmcDO6q9P15dmG8KmemEeKZ4iAUsh3kZCq8p4 L9afY1quySpmnhpIFe68TjcIobclEOLSo9gtDbIgSvuPtVaPEXUpNqm/kP944CNv NGjLG8LJ+hWETbkji465ny6CSJS+vDj2LXu+Bv7ilhgjoV3PDwU0JGVSfSCEXb04 H8tl0KwSYH2QrOZZk89l5vlpjx2UEJwEQhXM/tHJAWDPRvyJSZdPVrBAlIBGSLpb hS4JJ5Em0ovA6jUK4kRHlm5xcuizrCfix/bCkp7MzIB0S4UkRbc= =kJR5 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
> 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 (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases. But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC. > > Also does this mean that Clang is now fully supported compiler by full- > time working people @ Red Hat in toolchains team that are also > contributing to upstream? Just curious if we will be able to "fully > support" people when we find bugs in the compiler. Yes. Absolutely. Tom S & Serge G directly. Others in a more indirect capacity. > > And also, does it mean that we will be following same pattern as with > GCC to test pre-release versions in rawhide, do the mass rebuild and so > on? Some of that is already happening internally. Tom's got a tester which spins Fedora packages with Clang/LLVM. I'm not sure if he's trying to cover the whole distro, but it is running regularly (it shares a jenkins instance with my tester). > ... > > I think this is not fully true because clang / gcc produce different > binaries in terms of size / performance. So just switching compiler in > some package may result in significat (hopefully not) performance gain > / drop. Certainly switching compilers can result in performance changes. Having been through this kind of disruptive change on the other side (GCC vs various vendor compilers through the 90s), what tends to happen is the compilers get to a point where they're typically +-5% of each other on the vast majority of codes. That's where Clang/LLVM and GCC are today based on the data I've seen. > > Also we probably should mention that -fstack-clash-protection is not > available in clang, so in theory binaries can be less secure due to > that. Clang/LLVM is closing that gap rapidly. I fully expect stack clash protection to be at parity on the relevant platforms except aarch64 by LLVM 11 and a reasonable chance to reach parity on aarch64 by LLVM 12. > > ... > > I think this should mention that annobin plugin should be prepared for > clang. Nick Clifton is already working on that :-) Jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 zram device. That'd be a nice middleground for users like myself that don't have enough RAM to waste on a zram device. 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 cause OOM. I think you've completely missed the technical description of how this works. It does not take more than a tiny bit of RAM when it's not being used. It definitely does not take half your RAM right away. It only starts using RAM when you would otherwise be going into swap. Then it takes those pages that would be going to disk and compresses them so they use less RAM. So no it will not kill your system's performance and will help avoid the OOM condition. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 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 was to get rid of the disk-based swap partition, > > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > > swap-on-drive. And the installer will still permit swap-on-drive being > > > > added in custom partitioning. Both of these paths results in two swap > > > > devices. > > > > > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap-on-disk, > > > > to remove /etc/systemd/zram-generator.conf. And in that case, users > > > > will not get swap-on-zram. And we could also forgo the change being > > > > applied on upgrades. > > > > > > > > > > > > It may be best to respect the user's decision, and not add a zram device > > > on upgraded systems. This would lead to less unexpected behavior. I'd > > > support that, for sure :) > > > > > > Contra argument: It also leads to fragmentation of the user base. Most > > users use a distribution because they trust the decisions. And while > > it is only a preference, not a policy the Workstation Product > > Requirements Document says "Upgrading the system multiple times > > through the upgrade process should give a result that is the same as > > an original install of Fedora Workstation." > > > > There is a balancing act here that should be considered because a > > large percent of Fedora users upgrade rather than reprovision. It > > might even be the majority case. > > Well, that's for the GNOME stuff. This is a system-wide change proposal, is it > not? It is intended for all editions and spins. >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 zram device. That'd be a nice middleground for users like > myself that don't have enough RAM to waste on a zram device. 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 cause OOM. Ok so you've just decided to ignore that this is used already for years on ARM and Fedora IoT (including my 512M Raspberry Pi), and somehow you think your use case wouldn't benefit even though you haven't tried it? Maybe try it? You do not need to wait for F33. You can disable disk based swap and install the zram-generator right now on F31 or F32. Your use case is *exactly* what this feature has in mind. And it's even used by default in Chrome OS and Android when they moved to kernel 4.4, although not all OEM's opted in. By all means find a problem. Now is the perfect time for that. I am beginning to think this feature is like magic and I really want to see an edge case that blows up magnificently. In a year of testing I haven't found one that's worse than disk based swap. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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* compatible across the two compilers. As others mentioned, LTO will be contained to a specific package build. Allowing Clang can also *improve* LTO. Specifically, Firefox has a mix of C++ (could use GCC or Clang) and Rust (always LLVM). With Clang, they'd have an all-LLVM build, and could enable cross-language LTO: http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: System-Wide Change proposal: CompilerPolicy Change
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 clients that support > this) ... > Right now, this is the 16th thread for this topic in my inbox. It > makes it *really really hard* to follow the discussion. I brought it up to him off-list just a couple of hours ago, he wasn't aware of it. The problem comes from digest mails that his mailer (evolution) doesn't explode correctly to respond with correct in-reply-to header; he said he'd look into it and hasn't given a new reply to the thread yet but I'm sure he took it to heart. (I also suggested getting the message-id from hyperkitty, as its reply button properly gives it to keep threading, but it's more work than replying to emails from the comfort of one's mailbox... Getting the correct message-ids from the digest would be ideal.) Thanks for bringing it up as well, I should have kept the list in Cc to avoid multiple requests! Cheers, -- Dominique ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1844622] New: perl-DBD-Pg-3.12.3 is available
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 Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, dev...@gunduz.org, john.j5l...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, prais...@redhat.com, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.12.3 Current version/release in rawhide: 3.12.2-1.fc33 URL: http://search.cpan.org/dist/DBD-Pg/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2809/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 others. It was working for me on one laptop in > > February, consistently doesn't work now and I haven't gotten a reply > > yet from upstream about the problem. > > It may be true that most laptops have "Secure Boot" enabled, but not those > running Fedora. We don't have numbers to support that claim, and most devices > require "Secure Boot" to be disabled, or to have the mode changed so that it > accepts new keys, to install Fedora. Most systems that have UEFI Secure Boot enabled include Microsoft's signing key. Fedora's shim is signed by Microsoft's signing key. And shim contains Fedora's signing key, so that it can verify GRUB and the kernel, both of which are signed by Fedora. It's been this way for ~8 years. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 create disk-based swap at all. A small swap-on-zram > > > provides all the benefits of inactive anonymous page eviction, > > > including reducing reclaim of file pages, without the black hole > > > performance problems of swap-on-drive. > > > > > > > > > > > > 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. > > > > > > > > That doesn't seem to reflect reality. If you download the Server image > > right now, and go with its automatic partitioning scheme generation, > > it'll give you a swap partition on LVM. This is correct for most servers, > > not necessarily the LVM part, but having swap on disk. > > > The proposal recommends changing this. Cloud and Server folks will > decide what's best for their use cases, not me. In that case, would you be open to changing this proposal to only affect Workstation? -- John M. Harris, Jr. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: System-Wide Change proposal: CompilerPolicy Change
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 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 clients that support this) ... Right now, this is the 16th thread for this topic in my inbox. It makes it *really really hard* to follow the discussion. Fabio ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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: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 was to get rid of the disk-based swap partition, > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > swap-on-drive. And the installer will still permit swap-on-drive being > > > added in custom partitioning. Both of these paths results in two swap > > > devices. > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap-on-disk, > > > to remove /etc/systemd/zram-generator.conf. And in that case, users > > > will not get swap-on-zram. And we could also forgo the change being > > > applied on upgrades. > > > > > > > > It may be best to respect the user's decision, and not add a zram device > > on upgraded systems. This would lead to less unexpected behavior. I'd > > support that, for sure :) > > > Contra argument: It also leads to fragmentation of the user base. Most > users use a distribution because they trust the decisions. And while > it is only a preference, not a policy the Workstation Product > Requirements Document says "Upgrading the system multiple times > through the upgrade process should give a result that is the same as > an original install of Fedora Workstation." > > There is a balancing act here that should be considered because a > large percent of Fedora users upgrade rather than reprovision. It > might even be the majority case. 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 zram device. That'd be a nice middleground for users like myself that don't have enough RAM to waste on a zram device. 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 cause OOM. -- John M. Harris, Jr. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 inactive anonymous page eviction, > > including reducing reclaim of file pages, without the black hole > > performance problems of swap-on-drive. > > > > 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. > > That doesn't seem to reflect reality. If you download the Server image right > now, and go with its automatic partitioning scheme generation, it'll give you > a swap partition on LVM. This is correct for most servers, not necessarily the > LVM part, but having swap on disk. The proposal recommends changing this. Cloud and Server folks will decide what's best for their use cases, not me. > It really seems like this is wrong for most of Fedora, but that individual > parts, such as Fedora GNOME or IoT, should be left to make the decision for > themselves, without affecting the rest. Your opinion is noted. And now you don't have to keep repeating yourself and swamping the list with extraneous emails that contribute nothing new, correct? If you have some new insight, that's great. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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, 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 was to get rid of the disk-based swap partition, > > > since it has an unacceptable impact on system responsiveness? > > > > > > Default new installations, yes. No disk-based swap partition. > > > > For upgrades, there's no mechanism to remove an existing > > swap-on-drive. And the installer will still permit swap-on-drive being > > added in custom partitioning. Both of these paths results in two swap > > devices. > > > > We could ask Anaconda, if a custom installation creates swap-on-disk, > > to remove /etc/systemd/zram-generator.conf. And in that case, users > > will not get swap-on-zram. And we could also forgo the change being > > applied on upgrades. > > It may be best to respect the user's decision, and not add a zram device on > upgraded systems. This would lead to less unexpected behavior. I'd support > that, for sure :) Contra argument: It also leads to fragmentation of the user base. Most users use a distribution because they trust the decisions. And while it is only a preference, not a policy the Workstation Product Requirements Document says "Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation." There is a balancing act here that should be considered because a large percent of Fedora users upgrade rather than reprovision. It might even be the majority case. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: System-Wide Change proposal: CompilerPolicy Change
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 going to have codegen issues, or rejects-valid-code bugs. > > Ultimately they're just bugs and I don't see that one toolchain or the > > other is inherently better than the other, particularly WRT ABI > > issues. > > More problematic are not ABI bugs, but the cases where the ABI > divergence is a matter of opinion (more or less). Yes because these are much less likely to get fixed. THankfully these don't pop up nearly as often. > > I think we really should figure out what to do about the alignment of > _Atomic long long on 32-bit. GCC has 4, Clang has 8. Clang seems to be > correct here. This also has implications for the use of libatomic. 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. jeff ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 which we do not even have dynamic linking support. Or > > > even real static linking support, as opposed to packaging libraries as > > > source code.> > > > > Kevin Kofler > > > > > > > > Agreed. Besides, GNOME already has this enabled, right? It's definitely > > not right for servers, as I brought up the last time this was thrown > > around. > > 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 inactive anonymous page eviction, > including reducing reclaim of file pages, without the black hole > performance problems of swap-on-drive. > > 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. That doesn't seem to reflect reality. If you download the Server image right now, and go with its automatic partitioning scheme generation, it'll give you a swap partition on LVM. This is correct for most servers, not necessarily the LVM part, but having swap on disk. It really seems like this is wrong for most of Fedora, but that individual parts, such as Fedora GNOME or IoT, should be left to make the decision for themselves, without affecting the rest. -- John M. Harris, Jr. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 the key into the kernel for trust. > > Most of the "Secure Boot" hardware I've gotten my hands on have been early > generations, up to some produced in 2015. I've had to change the mode to > "deployment" on some HP ProDesk systems in order to get it to install Fedora, > for example. I can't speak for the most recent generations, but I remain > skeptical due to the "lockdown" functionality breaking everything. > > Other times you'd need to do so are when you'd like hibernation support, any > out of tree modules such as ZFS, kexec, hot patching.. That signing kernels is non-obvious and should get better does not mean it is good advice to tell people to disable UEFI Secure Boot. I have used out of tree ZFS in the past with Secure Boot enabled by signing the modules. Please move the non zram discussion to another thread. It's respectful to readers who come to this thread expecting to read about this subject matter. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 overhead, which is small but not zero, is just > > > a waste. > > > > > > > > I thought the plan was to get rid of the disk-based swap partition, > > since it has an unacceptable impact on system responsiveness? > > > Default new installations, yes. No disk-based swap partition. > > For upgrades, there's no mechanism to remove an existing > swap-on-drive. And the installer will still permit swap-on-drive being > added in custom partitioning. Both of these paths results in two swap > devices. > > We could ask Anaconda, if a custom installation creates swap-on-disk, > to remove /etc/systemd/zram-generator.conf. And in that case, users > will not get swap-on-zram. And we could also forgo the change being > applied on upgrades. It may be best to respect the user's decision, and not add a zram device on upgraded systems. This would lead to less unexpected behavior. I'd support that, for sure :) -- John M. Harris, Jr. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 support, as opposed to packaging libraries as source code. > > Kevin Kofler > > Agreed. Besides, GNOME already has this enabled, right? It's definitely not > right for servers, as I brought up the last time this was thrown around. 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 inactive anonymous page eviction, including reducing reclaim of file pages, without the black hole performance problems of swap-on-drive. 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. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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. > > Have you got proof of that and can provide figures? Having been > running it on Arm and IoT by default for a few releases now it > certainly doesn't cause fragmentation, it's allocated early in the > boot process so it's one single block. I also run zram on my laptop > and it's generally faster as when it has to hit swap that's backed by > RAM and is an order of magnitude faster, even with dealing with > compression, than hitting my NVME SSD. With one exception, I agree with all of this including better swap performance than on NVMe (~1500M/s). /dev/zram0 is definitely not preallocated $ cat /sys/block/zram0/mm_stat 4096 7412288012288000 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 4K 74B 12K 8 [SWAP] ]$ This 4G /dev/zram0 device isn't being used by swap right now. From the kernel documentation: mem_used_total the amount of memory allocated for this disk. This includes allocator fragmentation and metadata overhead, allocated for this disk. So, allocator space efficiency can be calculated using compr_data_size and this statistic. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
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(boost::geometry::index::detail::rtree::visitors::insert, WireJoiner::PntGetter>::members_holder,
boost::geometry::index::detail::rtree::insert_default_tag>&,
boost::variant,
boost::geometry::model::box >,
boost::geometry::index::detail::rtree::allocators,
WireJoiner::VertexInfo, boost::geometry::index::linear<16>,
boost::geometry::model::box >,
boost::geometry::index::detail::rtree::node_variant_static_tag>,
boost::geometry::index::detail::rtree::node_variant_static_tag>,
boost::geometry::index::detail::rtree::variant_internal_node,
boost::geometry::model::box >,
boost::geometry::index::detail::rtree::allocators,
WireJoiner::VertexInfo, boost::geometry::index::linear<16, 4>,
boost::geometry::model::box >,
boost::geometry::index::detail::rtree::node_variant_static_tag>,
boost::geometry::index::detail::rtree::node_variant_static_tag> >&)'
51 | boost::apply_visitor(v, n);
| ^~
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 inaccessible within this context
And it looks like that's a bug in Boost:
// Default insert visitor
template
class insert
: MembersHolder::visitor
{
I think that base class needs to be public.
Is your work-in-progress to get freecad building pushed to dist-git?
If not, could you send me a SRPM please? I'll try building it against
a patched boost. If that works, I'll push the patched boost to rawhide
and report it upstream.
Looking at the rest of the Boost.Geometry code, and the rest of the
patch that changed that line, I'm convinced it's a Boost bug.
Reported as:
https://github.com/boostorg/geometry/issues/721
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 to your new
patch file). A test build with the new boost and that extra fix
succeeded, so once boost-1.73.0-4.fc33 is in the buildroot you should
be able to build freecad (I am going AFK now, so won't be able to kick
off the freecad build myself).
Once the boost build completes this will tell you when it's in the
repo:
koji wait-repo --build boost-1.73.0-4.fc33 f33-build
And using --enablerepo=local will let local mock builds use that new
build.
I'll check email again in a few hours.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: devel Digest, Vol 196, Issue 58
* 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. > Ultimately they're just bugs and I don't see that one toolchain or the > other is inherently better than the other, particularly WRT ABI > issues. More problematic are not ABI bugs, but the cases where the ABI divergence is a matter of opinion (more or less). I think we really should figure out what to do about the alignment of _Atomic long long on 32-bit. GCC has 4, Clang has 8. Clang seems to be correct here. This also has implications for the use of libatomic. Thanks, Florian ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
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 was to get rid of the disk-based swap partition, > since it has an unacceptable impact on system responsiveness? Default new installations, yes. No disk-based swap partition. For upgrades, there's no mechanism to remove an existing swap-on-drive. And the installer will still permit swap-on-drive being added in custom partitioning. Both of these paths results in two swap devices. We could ask Anaconda, if a custom installation creates swap-on-disk, to remove /etc/systemd/zram-generator.conf. And in that case, users will not get swap-on-zram. And we could also forgo the change being applied on upgrades. -- Chris Murphy ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
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 Jun 2020 11:15:39 -0500 > > From: Steven Munroe > > Subject: Re: Fedora 33 System-Wide Change proposal: > > CompilerPolicy > > Change > > To: devel@lists.fedoraproject.org > > Message-ID: > > < > > CAPrKuAohVppTu_B4GDoxSMW=kzxtq_m13utpozoccok0xoz...@mail.gmail.com > > > > > Content-Type: text/plain; charset="UTF-8" > > > > I would also add that Clang/LLVM is missing some of the newer C > > language revisions at least for the pppc64le target. > > > > Both IEEE/ISO _Float128 and _Decimalxx support is missing. Ie > > the > > type is not supported or if supported basic arithmetic and math.h > > support is missing. Also finding bugs for in-line assembly and > > missing > > constraints needed to work around the missing language features. > > > > Also Clang's poor support for constant folding makes using > > __int128 > > (and vector __int128) harder than it needs to be. > > > > This is a significant impact for enabling my project (PVECLIB) > > for > > Clang. As-is a number of project features have been disabled for > > Clang. > Clearly your upstream project is still using GCC then and as such > the Fedora > package would continue to use GCC. > > We're not changing the default here. We're just removing the anti > Clang/LLVM > policy and allowing upstreams to select the compiler that best > suits their needs. > Clearly Clang/LLVM is not the right choice for your project. This looks fine, but why not add to the policy that for upstream projects that have no defined preference of compiler, the package have to use GCC in order to have at least some standard and not let the packager bias be the rule, unless some measurable advantage is found to use LLVM This has been discussed in this thread, Jeff wants to keep GCC a default choice for packages. Just to have an option to select Clang in some cases. I don't think the change proposal makes that entirely clear, but as long as the changes to the packaging guidelines are clear, that's fine. ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-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: Steven Munroe > > > Subject: Re: Fedora 33 System-Wide Change proposal: > > > CompilerPolicy > > > Change > > > To: devel@lists.fedoraproject.org > > > Message-ID: > > > < > > > CAPrKuAohVppTu_B4GDoxSMW=kzxtq_m13utpozoccok0xoz...@mail.gmail.com > > > > > > > Content-Type: text/plain; charset="UTF-8" > > > > > > I would also add that Clang/LLVM is missing some of the newer C > > > language revisions at least for the pppc64le target. > > > > > > Both IEEE/ISO _Float128 and _Decimalxx support is missing. Ie > > > the > > > type is not supported or if supported basic arithmetic and math.h > > > support is missing. Also finding bugs for in-line assembly and > > > missing > > > constraints needed to work around the missing language features. > > > > > > Also Clang's poor support for constant folding makes using > > > __int128 > > > (and vector __int128) harder than it needs to be. > > > > > > This is a significant impact for enabling my project (PVECLIB) > > > for > > > Clang. As-is a number of project features have been disabled for > > > Clang. > > Clearly your upstream project is still using GCC then and as such > > the Fedora > > package would continue to use GCC. > > > > We're not changing the default here. We're just removing the anti > > Clang/LLVM > > policy and allowing upstreams to select the compiler that best > > suits their needs. > > Clearly Clang/LLVM is not the right choice for your project. > > This looks fine, but why not add to the policy that for upstream > projects that have no defined preference of compiler, the package > have > to use GCC in order to have at least some standard and not let the > packager bias be the rule, unless some measurable advantage is found > to > use LLVM This has been discussed in this thread, Jeff wants to keep GCC a default choice for packages. Just to have an option to select Clang in some cases. > > > > > > > > > > I think Clang needs more time to cook. > > 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 the proposal I've made accounts > > for that by > > allowing the upstream project to select the compiler. In your case > > it would be > > GCC. For others it could well be Clang/LLVM. > > > > jeff > > > > > > > > ___ > > 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-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > ___ > 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-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7ajyoACgkQEV1auJxc Hh6ATg/+ImOPA1iIt0LVohfZA25Ljv7HPkN6I/jOqQiAXsnqJFWSwv/CSKE3kt+r Bbs0CcVvqUOFjOuK/jfHtZJP0RdvCpgnHmyddY896bYZaJvLeVZrhPw5a5IWbSbS Nd4SZaWwzkJVJJM/kXnAJfil2LpINNF2hS9usjFtc8ZgEheXzBLwmLqReS7Ikp7S 1oLLSROqHVMm0WNp1k/1uRRTFi38KkEdDGfZwvp7BHEOv0h99tuNaDqmnUi4wDSQ ke9xWXosSbfjOboJPY3LXZrl3vWam4+WEt7+OEPW8z44ClPAs5+guX059O41OVR9 SwDxYzM3Z8yqWjTVsYs9W5joCCR6CjtyrkR2l4LkEUIxUp6Q5X/YbYBJrhd1UIXi YBQ9iYV1MdZUdU23w0aez44py8xUWSMRVXhtcahd4eM6KToJ8t4AF0hInz7jDrzD NiAACAXr/aiJZ95LvALrSlBXfzXxDz+9Itmv7h43QoSET6NAHcFgJfCe5V1GhgNh ztJy2U2ORBN2bL3qL/lB/vjBFg5s1tpziwIRMlmw9aHlrDVL5vMzpfDFM2JDtLbv lsNwzDaO+RyEkwELi6d1+clO9aoVYLrL8PrYHXBOPw4SXy3gGWoS45Rrk+gChMn1 zls7UgiHBp3FhdA1xRfCKVP2+rhvAMgkiQcfTNmCTG+GzZVUSfc= =tSW7 -END PGP SIGNATURE- ___ 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-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
