Re: Btrfs by default, the compression option
On Friday, July 10, 2020, Zachary Lym wrote: > > Yes, it's completely reasonable to not do it. It might seem like a big > > change on its own, but Btrfs has had native compression for 10+ years, > > and at least three years for most all of the workloads at Facebook. So > > it's quite safe. > > But it has been eating data as recently as 2018 [1] and the Debian wiki > warns strongly against using compression that is dated for 2020 [2]. The > project will already see a large number of new bugs thanks to the wider > breadth of hardware, why throw in an additional variable when you can flip > it on in six months anyway? Then again only for new installs. Would be better to move all of it by six months - enabling it without taking advantage of such features would be kind of wasteful. Also if two years is "recent" how do 6 months change anything? > > 1: https://www.spinics.net/lists/linux-btrfs/msg81293.html > 2: https://wiki.debian.org/Btrfs#Warnings > ___ > 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: The future of legacy BIOS support in Fedora.
On 7/9/20 10:46 AM, John M. Harris Jr wrote: "Secure Boot" doesn't make root non-uid 0, and can't keep root from controlling system devices, even uploading unsigned firmware to peripherals. While it's true that a completely secure software chain doesn't really exist yet, we are slowly going in that direction, because it is just inconceivable otherwise in the world with billions of autonomous IOT devices---the consequences of a worm-type insecurity that would subvert a significant portion of Internet-connected devices are just too scary. For instance, one possible solution used e.g. for a secure BIOS updates is to prevent loading firmware directly, and instead load it into a separate flash area. Then, reset the system: * existing certified firmware boots and finds the updated firmware * new firmware is measured and verified * if it passes, the old firmware copies and activates the updated firmware So you see that you can't subvert this even with UID==0. Same thing for controlling system devices---with secure software chain even the applications can be certified and controlled. THis is not your or my desktop system, of course, but there is a need for systems like this. When I hear you say that this takes away the ownership of our computers from us, I think that it's got to be this way for a large part of those billions of systems---as the saying goes, we have to stop thinking of computers as pets, and start seeing them as cattle. We can still have pets as well, but there has to be a way to herd cattle. ___ 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-07-10 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/10/report-389-ds-base-1.4.4.4-20200709git318a3ce.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: Make btrfs the default file system for desktop variants
On 7/9/20 9:15 PM, Josef Bacik wrote: > On 7/9/20 9:30 PM, Eric Sandeen wrote: ... >>> This test is run constantly by us, specifically because it's the error >>> cases that get you. But not for crash consistency reasons, because we're >>> solid there. I run them to make sure I don't have stupid things like >>> reference leaks or whatever in the error path. Thanks, >> >> or "corrupted!" printk()s that terrify the hapless user? ;) > > I'd love to know what hapless user is running xfstests. Thanks, *sigh* the point is, telling the user "your filesystem is corrupted" if it's not actually corrupted is bad news. Discovering that communication problem via xfstests does not make the concern less valid. I was trying to gently tease you that the test not only discovers leaks, but also discovers terrifyingly inaccurate messages in response to IO errors, but I guess that didn't come through. Thanks. -Eric ___ 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: Make btrfs the default file system for desktop variants
On 7/9/20 9:30 PM, Eric Sandeen wrote:
On 7/9/20 8:22 PM, Josef Bacik wrote:
On 7/9/20 7:23 PM, Eric Sandeen wrote:
On 7/9/20 4:27 PM, Eric Sandeen wrote:
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
...
As someone on one of the teams at FB that has to deal with that, I can
assure you all the scenarios you listed can and do happen, and they
happen a lot. While we don't have the "laptop's out of battery" issue
on the production side, we have plenty of power events and unplanned
maintenances that can and will hit live machines and cut power off.
Force reboots (triggered by either humans or automation) are also not
at all uncommon. Rebuilding machines from scratch isn't free, even with
all the automation and stuff we have, so if power loss or reboot events
on machines using btrfs caused widespread corruption or other issues
I'm confident we'd have found that out pretty early on.
It is a bare minimum expectation that filesystems like btrfs, ext4, and xfs
do not suffer filesystem corruptions and inconsistencies due to reboots
and power losses.
So for the record I am in no way insinuating that btrfs is less crash-safe
than other filesystems (though I have not tested that, so if I have time
I'll throw that into the mix as well.)
So, we already have those tests in xfstests, and I put btrfs through a few
loops. This is generic/475:
# Copyright (c) 2017 Oracle, Inc. All Rights Reserved.
#
# FS QA Test No. 475
#
# Test log recovery with repeated (simulated) disk failures. We kick
# off fsstress on the scratch fs, then switch out the underlying device
# with dm-error to see what happens when the disk goes down. Having
# taken down the fs in this manner, remount it and repeat. This test
# is a Good Enough (tm) simulation of our internal multipath failure
# testing efforts.
It fails within 2 loops. Is it a critical failure? I don't know; the
test looks for unexpected things in dmesg, and perhaps the filter is
wrong. But I see stack traces during the run, and message like:
[689284.484258] BTRFS: error (device dm-3) in btrfs_sync_log:3084: errno=-117
Filesystem corrupted
You might want to change that message, then. If it's not corrupted, I'd suggest not doing
printk("corrupted!") because that will make people think that it's corrupted, because it
says "Filesystem corrupted..." ;)
Yeah probably not the best, but again not something a user will generally see.
Yeah, because dm-error throws EIO, and thus we abort the transaction, which
results in an EUCLEAN if you run fsync. This is a scary sounding message, but
its _exactly_ what's expected from generic/475. I've been running this in a
loop for an hour and the thing hasn't failed yet. There's all sorts of scary
messages
That's weird. The test fails very quickly for me - again, AFAICT it fails due
to things in dmesg that aren't recognized as safe by the test harness, but a
variety of things - not just stack dumps - seem to trigger the failure.
Do you know what's tripping it? Because my loop is still running happily along.
[17929.939871] BTRFS warning (device dm-13): direct IO failed ino 261 rw
1,34817 sector 0xb8ce0 len 24576 err no 10
[17929.943099] BTRFS: error (device dm-13) in btrfs_commit_transaction:2323:
errno=-5 IO failure (Error while writing out transaction)
again, totally expected because we're forcing EIO's at random times.
Right, of course it will get IO errors, that's why I didn't highlight those in
my email.
so I can't say for sure.
Are btrfs devs using these tests to assess crash/powerloss resiliency
on a regular basis? TBH I honestly did not expect to see any test
failures here, whether or not they are test artifacts; any filesystem
using xfstests as a benchmark needs to be keeping things up to date.
It depends on the config options. Some of our transaction abort sites dump
stack, and that trips the dmesg filter, and thus it fails. Generally when I
run this test I turn those options off.
It would be good, in general, to fix up the test for btrfs so that it does not
yield false positives, if that's what this is. Otherwise it trains people to
ignore it or not run it
Except it doesn't, it's not failing for me now. Like I said we pay particularly
close attention to this test because it has a habit of finding memory leaks or
reference accounting bugs.
This test is run constantly by us, specifically because it's the error cases
that get you. But not for crash consistency reasons, because we're solid
there. I run them to make sure I don't have stupid things like reference leaks
or whatever in the error path. Thanks,
or "corrupted!" printk()s that terrify the hapless user? ;)
I'd love to know what hapless user is running xfstests. Thanks,
Josef
___
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: Make btrfs the default file system for desktop variants
On 7/9/20 8:22 PM, Josef Bacik wrote:
> On 7/9/20 7:23 PM, Eric Sandeen wrote:
>> On 7/9/20 4:27 PM, Eric Sandeen wrote:
>>> On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
>>
>> ...
>>
As someone on one of the teams at FB that has to deal with that, I can
assure you all the scenarios you listed can and do happen, and they
happen a lot. While we don't have the "laptop's out of battery" issue
on the production side, we have plenty of power events and unplanned
maintenances that can and will hit live machines and cut power off.
Force reboots (triggered by either humans or automation) are also not
at all uncommon. Rebuilding machines from scratch isn't free, even with
all the automation and stuff we have, so if power loss or reboot events
on machines using btrfs caused widespread corruption or other issues
I'm confident we'd have found that out pretty early on.
>>>
>>> It is a bare minimum expectation that filesystems like btrfs, ext4, and xfs
>>> do not suffer filesystem corruptions and inconsistencies due to reboots
>>> and power losses.
>>>
>>> So for the record I am in no way insinuating that btrfs is less crash-safe
>>> than other filesystems (though I have not tested that, so if I have time
>>> I'll throw that into the mix as well.)
>>
>> So, we already have those tests in xfstests, and I put btrfs through a few
>> loops. This is generic/475:
>>
>> # Copyright (c) 2017 Oracle, Inc. All Rights Reserved.
>> #
>> # FS QA Test No. 475
>> #
>> # Test log recovery with repeated (simulated) disk failures. We kick
>> # off fsstress on the scratch fs, then switch out the underlying device
>> # with dm-error to see what happens when the disk goes down. Having
>> # taken down the fs in this manner, remount it and repeat. This test
>> # is a Good Enough (tm) simulation of our internal multipath failure
>> # testing efforts.
>>
>> It fails within 2 loops. Is it a critical failure? I don't know; the
>> test looks for unexpected things in dmesg, and perhaps the filter is
>> wrong. But I see stack traces during the run, and message like:
>>
>> [689284.484258] BTRFS: error (device dm-3) in btrfs_sync_log:3084:
>> errno=-117 Filesystem corrupted
You might want to change that message, then. If it's not corrupted, I'd
suggest not doing printk("corrupted!") because that will make people think that
it's corrupted, because it says "Filesystem corrupted..." ;)
>
> Yeah, because dm-error throws EIO, and thus we abort the transaction, which
> results in an EUCLEAN if you run fsync. This is a scary sounding message,
> but its _exactly_ what's expected from generic/475. I've been running this
> in a loop for an hour and the thing hasn't failed yet. There's all sorts of
> scary messages
That's weird. The test fails very quickly for me - again, AFAICT it fails due
to things in dmesg that aren't recognized as safe by the test harness, but a
variety of things - not just stack dumps - seem to trigger the failure.
> [17929.939871] BTRFS warning (device dm-13): direct IO failed ino 261 rw
> 1,34817 sector 0xb8ce0 len 24576 err no 10
> [17929.943099] BTRFS: error (device dm-13) in btrfs_commit_transaction:2323:
> errno=-5 IO failure (Error while writing out transaction)
>
> again, totally expected because we're forcing EIO's at random times.
Right, of course it will get IO errors, that's why I didn't highlight those in
my email.
>> so I can't say for sure.
>>
>> Are btrfs devs using these tests to assess crash/powerloss resiliency
>> on a regular basis? TBH I honestly did not expect to see any test
>> failures here, whether or not they are test artifacts; any filesystem
>> using xfstests as a benchmark needs to be keeping things up to date.
>>
>
> It depends on the config options. Some of our transaction abort sites dump
> stack, and that trips the dmesg filter, and thus it fails. Generally when I
> run this test I turn those options off.
It would be good, in general, to fix up the test for btrfs so that it does not
yield false positives, if that's what this is. Otherwise it trains people to
ignore it or not run it
> This test is run constantly by us, specifically because it's the error cases
> that get you. But not for crash consistency reasons, because we're solid
> there. I run them to make sure I don't have stupid things like reference
> leaks or whatever in the error path. Thanks,
or "corrupted!" printk()s that terrify the hapless user? ;)
-Eric
___
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
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a8a3c29a putty-0.74-1.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8c3e76982e python-rsa-3.4.2-1.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7b550f6ce5 python-gnupg-0.4.6-1.el6 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-cf2168a68d php-horde-kronolith-4.2.28-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing gtk-gnutella-1.2.0-1.el6 Details about builds: gtk-gnutella-1.2.0-1.el6 (FEDORA-EPEL-2020-109ce16b2a) GUI based Gnutella Client Update Information: Update to 1.2.0 Fixes many bugs and crashes and has many improvements, see http://gtk-gnutella.sourceforge.net/en/?page=news for more info. ChangeLog: * Thu Jul 9 2020 Dmitry Butskoy - 1.2.0-1 - Upgrade to 1.2.0 - re-calculate sha1 of the stripped binary at the end of the install stage (when it is actually stripped in the distribution's specific way) - provide appdata file * Wed Jan 29 2020 Fedora Release Engineering - 1.1.15-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/9/20 7:23 PM, Eric Sandeen wrote: On 7/9/20 4:27 PM, Eric Sandeen wrote: On 7/9/20 3:32 PM, Davide Cavalca via devel wrote: ... As someone on one of the teams at FB that has to deal with that, I can assure you all the scenarios you listed can and do happen, and they happen a lot. While we don't have the "laptop's out of battery" issue on the production side, we have plenty of power events and unplanned maintenances that can and will hit live machines and cut power off. Force reboots (triggered by either humans or automation) are also not at all uncommon. Rebuilding machines from scratch isn't free, even with all the automation and stuff we have, so if power loss or reboot events on machines using btrfs caused widespread corruption or other issues I'm confident we'd have found that out pretty early on. It is a bare minimum expectation that filesystems like btrfs, ext4, and xfs do not suffer filesystem corruptions and inconsistencies due to reboots and power losses. So for the record I am in no way insinuating that btrfs is less crash-safe than other filesystems (though I have not tested that, so if I have time I'll throw that into the mix as well.) So, we already have those tests in xfstests, and I put btrfs through a few loops. This is generic/475: # Copyright (c) 2017 Oracle, Inc. All Rights Reserved. # # FS QA Test No. 475 # # Test log recovery with repeated (simulated) disk failures. We kick # off fsstress on the scratch fs, then switch out the underlying device # with dm-error to see what happens when the disk goes down. Having # taken down the fs in this manner, remount it and repeat. This test # is a Good Enough (tm) simulation of our internal multipath failure # testing efforts. It fails within 2 loops. Is it a critical failure? I don't know; the test looks for unexpected things in dmesg, and perhaps the filter is wrong. But I see stack traces during the run, and message like: [689284.484258] BTRFS: error (device dm-3) in btrfs_sync_log:3084: errno=-117 Filesystem corrupted Yeah, because dm-error throws EIO, and thus we abort the transaction, which results in an EUCLEAN if you run fsync. This is a scary sounding message, but its _exactly_ what's expected from generic/475. I've been running this in a loop for an hour and the thing hasn't failed yet. There's all sorts of scary messages [17929.939871] BTRFS warning (device dm-13): direct IO failed ino 261 rw 1,34817 sector 0xb8ce0 len 24576 err no 10 [17929.943099] BTRFS: error (device dm-13) in btrfs_commit_transaction:2323: errno=-5 IO failure (Error while writing out transaction) again, totally expected because we're forcing EIO's at random times. so I can't say for sure. Are btrfs devs using these tests to assess crash/powerloss resiliency on a regular basis? TBH I honestly did not expect to see any test failures here, whether or not they are test artifacts; any filesystem using xfstests as a benchmark needs to be keeping things up to date. It depends on the config options. Some of our transaction abort sites dump stack, and that trips the dmesg filter, and thus it fails. Generally when I run this test I turn those options off. This test is run constantly by us, specifically because it's the error cases that get you. But not for crash consistency reasons, because we're solid there. I run them to make sure I don't have stupid things like reference leaks or whatever in the error path. Thanks, Josef ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 695 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 434 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 144 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 84 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ad4894c0c jbig2dec-0.12-5.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0078f6abc1 xpdf-3.04-10.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-af9c6001d1 ngircd-26-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5d348316dd chromium-83.0.4103.116-3.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-afd5c42fd6 coturn-4.5.1.3-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6949cf3502 xrdp-0.9.13.1-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f70f49092 putty-0.74-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f25da8099 python-rsa-3.4.2-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-28cc1451e0 python-gnupg-0.4.6-2.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-cbcc9ca06b php-horde-kronolith-4.2.28-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8dd45257ad seamonkey-2.53.3-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing gtk-gnutella-1.2.0-1.el7 python-catkin_lint-1.6.10-1.el7 rdiff-backup-2.0.3-5.el7 Details about builds: gtk-gnutella-1.2.0-1.el7 (FEDORA-EPEL-2020-df3ecab1c8) GUI based Gnutella Client Update Information: Update to 1.2.0 Fixes many bugs and crashes and has many improvements, see http://gtk-gnutella.sourceforge.net/en/?page=news for more info. ChangeLog: * Thu Jul 9 2020 Dmitry Butskoy - 1.2.0-1 - Upgrade to 1.2.0 - re-calculate sha1 of the stripped binary at the end of the install stage (when it is actually stripped in the distribution's specific way) - provide appdata file * Wed Jan 29 2020 Fedora Release Engineering - 1.1.15-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild python-catkin_lint-1.6.10-1.el7 (FEDORA-EPEL-2020-9d82ed87b3) Check catkin packages for common errors Update Information: Update to the latest catkin_lint release ChangeLog: * Thu Jul 9 2020 Scott K Logan - 1.6.10-1 - Update to 1.6.10 (rhbz#1851568) References: [ 1 ] Bug #1851568 - python-catkin_lint-1.6.10.post1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1851568 rdiff-backup-2.0.3-5.el7 (FEDORA-EPEL-2020-d3078f1c10) Convenient and transparent local/remote incremental mirror/backup Update Information: Add requirement of python3-setuptools (Ref upstream issue #305 ChangeLog: * Thu Jul 9 2020 Frank Crawford 2.0.3-5 - Bump to be higher than COPR version * Thu Jul 9 2020 Frank Crawford 2.0.3-2 - Add requirement of python3-setuptools (Ref upstream issue #305) ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[Bug 1854141] perl-Socket-2.030 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1854141 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Socket-2.030-1.fc33|perl-Socket-2.030-1.fc33 ||perl-Socket-2.030-1.fc32 Resolution|--- |ERRATA Last Closed||2020-07-10 01:02:14 --- Comment #6 from Fedora Update System --- FEDORA-2020-57101032dc has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- 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 1149524] Review Request: perl-Digest-Whirlpool - Interface to Whirlpool hash algorithm
https://bugzilla.redhat.com/show_bug.cgi?id=1149524 Package Review changed: What|Removed |Added Flags||needinfo?(dd...@cpan.org) --- Comment #3 from Package Review --- This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted. -- 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: Btrfs by default, the compression option
> Yes, it's completely reasonable to not do it. It might seem like a big > change on its own, but Btrfs has had native compression for 10+ years, > and at least three years for most all of the workloads at Facebook. So > it's quite safe. But it has been eating data as recently as 2018 [1] and the Debian wiki warns strongly against using compression that is dated for 2020 [2]. The project will already see a large number of new bugs thanks to the wider breadth of hardware, why throw in an additional variable when you can flip it on in six months anyway? 1: https://www.spinics.net/lists/linux-btrfs/msg81293.html 2: https://wiki.debian.org/Btrfs#Warnings ___ 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: Make btrfs the default file system for desktop variants
On 7/9/20 4:27 PM, Eric Sandeen wrote: > On 7/9/20 3:32 PM, Davide Cavalca via devel wrote: ... >> As someone on one of the teams at FB that has to deal with that, I can >> assure you all the scenarios you listed can and do happen, and they >> happen a lot. While we don't have the "laptop's out of battery" issue >> on the production side, we have plenty of power events and unplanned >> maintenances that can and will hit live machines and cut power off. >> Force reboots (triggered by either humans or automation) are also not >> at all uncommon. Rebuilding machines from scratch isn't free, even with >> all the automation and stuff we have, so if power loss or reboot events >> on machines using btrfs caused widespread corruption or other issues >> I'm confident we'd have found that out pretty early on. > > It is a bare minimum expectation that filesystems like btrfs, ext4, and xfs > do not suffer filesystem corruptions and inconsistencies due to reboots > and power losses. > > So for the record I am in no way insinuating that btrfs is less crash-safe > than other filesystems (though I have not tested that, so if I have time > I'll throw that into the mix as well.) So, we already have those tests in xfstests, and I put btrfs through a few loops. This is generic/475: # Copyright (c) 2017 Oracle, Inc. All Rights Reserved. # # FS QA Test No. 475 # # Test log recovery with repeated (simulated) disk failures. We kick # off fsstress on the scratch fs, then switch out the underlying device # with dm-error to see what happens when the disk goes down. Having # taken down the fs in this manner, remount it and repeat. This test # is a Good Enough (tm) simulation of our internal multipath failure # testing efforts. It fails within 2 loops. Is it a critical failure? I don't know; the test looks for unexpected things in dmesg, and perhaps the filter is wrong. But I see stack traces during the run, and message like: [689284.484258] BTRFS: error (device dm-3) in btrfs_sync_log:3084: errno=-117 Filesystem corrupted so I can't say for sure. Are btrfs devs using these tests to assess crash/powerloss resiliency on a regular basis? TBH I honestly did not expect to see any test failures here, whether or not they are test artifacts; any filesystem using xfstests as a benchmark needs to be keeping things up to date. As a further test, I skipped the dmesg check, which may or may not be finding false positives, and replaced it with a mount/umount/check cycle. That seems to pass, so if fsck validation is complete and correct, perhaps all is well in this regard. -Eric ___ 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: Make btrfs the default file system for desktop variants
On Thu, Jul 9, 2020 at 3:06 PM Stephen John Smoogen wrote: > > That is because anyone who questions the perfection of ZFS is quickly > burned at a stake. I think Neal also has a good take on why, which is that it was mostly a closed door development early on, wasn't used on heterogeneous hardware out in the wild, upon release wasn't commonly available for years - and just never really got the same kind of scrutiny and rumor that Btrfs did. > > I don't know what it is about filesystems turning into religions that > do not brook questioning but what I am seeing in these emails is what > turns me off of btrfs every time it is brought up in the same way I > couldn't stand reiser, ZFS, or various other filesystems.. I realize > filesystems take a lot of faith as people have to put something they > value into a leap of faith it will be there the next day.. but it > seems to morph quickly into some sort of fanatical evangelical > movement. I've said this same thing in recent weeks. I don't understand it. I don't know if you think I've done this. Certainly my experience over 10 years has been Btrfs developers have been among the least defensive, and the first to say it doesn't meet every use case and of course folks should use the file system that fits their requirements the best. > So a good reason why no one brings it up.. you learn quickly that > questioning the perfection of any filesystem will fill your inbox with > tirades from people. Yeah that's kind of an obnoxious pig pen. -- 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: Make btrfs the default file system for desktop variants
- Original Message -
> From: "Josef Bacik"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, July 9, 2020 9:11:07 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default
> file system for desktop variants
>
> On 7/9/20 1:51 PM, Eric Sandeen wrote:
> > On 7/6/20 12:07 AM, Chris Murphy wrote:
> >> On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
> >> wrote:
> >>>
> >>> On 7/3/20 1:41 PM, Chris Murphy wrote:
> SSDs can fail in weird ways. Some spew garbage as they're
> failing, some go read-only. I've seen both. I don't have stats on
> how common it is for an SSD to go read-only as it fails, but once
> it happens you cannot fsck it. It won't accept writes. If it
> won't mount, your only chance to recover data is some kind of
> offline scrape tool. And Btrfs does have a very very good scrape
> tool, in terms of its success rate - UX is scary. But that can
> and will improve.
> >>>
> >>> Ok, you and Josef have both recommended the btrfs restore
> >>> ("scrape") tool as a next recovery step after fsck fails, and I
> >>> figured we should check that out, to see if that alleviates the
> >>> concerns about recoverability of user data in the face of
> >>> corruption.
> >>>
> >>> I also realized that mkfs of an image isn't representative of an
> >>> SSD system typical of Fedora laptops, so I added "-m single" to
> >>> mkfs, because this will be the mkfs.btrfs default on SSDs (right?).
> >>> Based on Josef's description of fsck's algorithm of throwing away
> >>> any block with a bad CRC this seemed worth testing.
> >>>
> >>> I also turned fuzzing /down/ to hitting 2048 bytes out of the 1G
> >>> image, or a bit less than 1% of the filesystem blocks, at random.
> >>> This is 1/4 the fuzzing rate from the original test.
> >>>
> >>> So: -m single, fuzz 2048 bytes of 1G image, run btrfsck --repair,
> >>> mount, mount w/ recovery, and then restore ("scrape") if all that
> >>> fails, see what we get.
> >>
> >> What's the probability of this kind of corruption occurring in the
> >> real world? If the probability is so low it can't practically be
> >> computed, how do we assess the risk? And if we can't assess risk,
> >> what's the basis of concern?
> >
> > From 20 years of filesystem development experience, I know that people
> > run filesystem repair tools. It's just a fact. For a wide variety of
> > reasons - from bugs, to hardware errors, to admin errors, you name it,
> > filesystems experience corruption and inconsistencies. At that point
> > the administrator needs a path forward.
> >
> > "people won't need to repair btrfs" is, IMHO, the position that needs
> > to be supported, not "filesystem repair tools should be robust."
> >
> >>> I ran 50 loops, and got:
> >>>
> >>> 46 btrfsck failures 20 mount failures
> >>>
> >>> So it ran btrfs restore 20 times; of those, 11 runs lost all or
> >>> substantially all of the files; 17 runs lost at least 1/3 of the
> >>> files.
> >>
> >> Josef states reliability of ext4, xfs, and Btrfs are in the same
> >> ballpark. He also reports one case in 10 years in which he failed to
> >> recover anything. How do you square that with 11 complete failures,
> >> trivially produced? Is there even a reason to suspect there's
> >> residual risk?
> >
> > Extrapolating from Facebook's usecases to the fedora desktop should be
> > approached with caution, IMHO.
> >
> > I've provided evidence that if/when damage happens for whatever reason,
> > btrfs is unable to recover in place far more often than other filesytems.
> >
> >> When metadata is single profile, Btrfs is basically an early warning
> >> system.> The available research on uncorrectable errors, errors that drive
> >> ECC
> >> does not catch, suggests that users are decently likely to experience
> >> at least one block of corruption in the life of the drive. And that
> >> it tends to get worse up until drive failure. But there is much less
> >> chance to detect this, if the file system isn't also checksumming the
> >> vastly larger payload on a drive: the data.
> >
> > One of the problems in this whole discussion is the assumption that
> > filesystem
> > inconsistencies only arise from disk bitflips etc; that's just not the
> > case.
> >
> > Look, I'm just providing evidence of what I've found when re-evaluating the
> > btrfs administration/repair tools. I've found them to be quite weak.
> >
> > From what I've gathered from these responses, btrfs is unique in that it
> > is
> > /expected/ that if anything goes wrong, the administrator should be
> > prepared
> > to scrape out remaining data, re-mkfs, and start over. If that's
> > acceptable
> > for the Fedora desktop, that's fine, but I consider it a risk that should
> > not
> > be ignored when evaluating this proposal.
> >
>
> Agreed, it's the very first thing I said when I was asked what are the
> downsides. There's clearly more work to be done in the recovery arena. How
> often do disks fail for
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/9/20 3:38 PM, Chris Murphy wrote: > On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote: >> On 7/9/20 2:11 PM, Josef Bacik wrote: From what I've gathered from these responses, btrfs is unique in that it is /expected/ that if anything goes wrong, the administrator should be prepared to scrape out remaining data, re-mkfs, and start over. If that's acceptable for the Fedora desktop, that's fine, but I consider it a risk that should not be ignored when evaluating this proposal. >>> Agreed, it's the very first thing I said when I was asked what are the >>> downsides. There's clearly more work to be done in the recovery arena. >>> How often do disks fail for Fedora? Do we have that data? Is this a real >>> risk? Nobody can say because Fedora doesn't have data. >> But again, let me reiterate that disk failures are far from the only >> reason that admins need capable filesystem repair tools, in general. >> >> We see users running fsck all the time, for various reasons. I can't >> back it up, but my hunch is that bugs and misconfigurations (i.e. write >> cache) are more often the root cause for filesystem inconsistencies. >> >> IMHO, focusing on physical disk failure rates is focusing too narrowly, >> but I suppose I'm just joining the chorus of hunches and anecdotes now. > Actually there's quite a lot of evidence of this, even though there's > no precise estimate - not least of which these populations are > constantly dying and reemerging, and can be batch (firmware version) > specific. This is only the most recent such story on linux-btrfs@ (and > warning, this reads like an alien autopsy): > > https://lore.kernel.org/linux-btrfs/20200708034407.ge10...@hungrycats.org/ > > fsck.btrfs is a no op, same as fsck.xfs. And recently the actual > repair utility dissuades users from running it casually. Honestly, that's not relevant. They are no-ops because they do not need to be run at boot time after an unclean shutdown, because the filesystems are explicitly designed to handle that. This is clearly stated in the man page, the script itself, and the commit log. In fact fsck.btrfs was copied from fsck.xfs. (Honestly fsck.ext[34] could be a no-op too, but for $REASONS it chooses to do journal replay in userspace instead, via fsck.) They are no-ops for this reason, and /not/ because fsck isn't /ever/ expected to be needed. -Eric ___ 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: Make btrfs the default file system for desktop variants
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote: > On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote: >> However I have had bad kernels, power outages, loss of battery power >> (laptops on too long suspend) and other random reasons to force >> reboot >> a system. That has been the primary case of file system checks >> through >> my Fedora usage. And luckily so far I never had a loss of filesystem >> or >> data that way, fsck always ended up solving most of the issues, and >> whenever I lost file they ended up being temporary files I did not >> care >> for. >> >> I do not think those failures are common in Facebook fleets, so I am >> quite skeptical FB data and failure modes are representative of >> Fedora >> usage as a desktop/laptop OS and therefore of the behavior of btrfs >> in >> those cases. > > As someone on one of the teams at FB that has to deal with that, I can > assure you all the scenarios you listed can and do happen, and they > happen a lot. While we don't have the "laptop's out of battery" issue > on the production side, we have plenty of power events and unplanned > maintenances that can and will hit live machines and cut power off. > Force reboots (triggered by either humans or automation) are also not > at all uncommon. Rebuilding machines from scratch isn't free, even with > all the automation and stuff we have, so if power loss or reboot events > on machines using btrfs caused widespread corruption or other issues > I'm confident we'd have found that out pretty early on. It is a bare minimum expectation that filesystems like btrfs, ext4, and xfs do not suffer filesystem corruptions and inconsistencies due to reboots and power losses. So for the record I am in no way insinuating that btrfs is less crash-safe than other filesystems (though I have not tested that, so if I have time I'll throw that into the mix as well.) We do at times see corrupted filesystems when something has a writeback cache w/o a battery backup, though, because then the hardware violates its guarantees to the filesystem this is the sort of thing I'd put in the "misconfiguration" bucket. Which happens from time to time, and from which it is nice to be able to recover w/o heroics. -Eric ___ 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: Make btrfs the default file system for desktop variants
On Thu, Jul 9, 2020 at 4:16 PM Simo Sorce wrote: > > On Thu, 2020-07-09 at 12:56 -0700, Eric Sandeen wrote: > > On 7/9/20 2:11 PM, Josef Bacik wrote: > > > > From what I've gathered from these responses, btrfs is unique in that > > > > it is > > > > /expected/ that if anything goes wrong, the administrator should be > > > > prepared > > > > to scrape out remaining data, re-mkfs, and start over. If that's > > > > acceptable > > > > for the Fedora desktop, that's fine, but I consider it a risk that > > > > should not > > > > be ignored when evaluating this proposal. > > > > > > > > > > Agreed, it's the very first thing I said when I was asked what are the > > > downsides. There's clearly more work to be done in the recovery arena. > > > How often do disks fail for Fedora? Do we have that data? Is this a > > > real risk? Nobody can say because Fedora doesn't have data. > > > > But again, let me reiterate that disk failures are far from the only > > reason that admins need capable filesystem repair tools, in general. > > > > We see users running fsck all the time, for various reasons. I can't > > back it up, but my hunch is that bugs and misconfigurations (i.e. write > > cache) are more often the root cause for filesystem inconsistencies. > > > > IMHO, focusing on physical disk failure rates is focusing too narrowly, > > but I suppose I'm just joining the chorus of hunches and anecdotes now. > > Anecdata, > but I use raid-1 on all my disks (since a catastrophic failure 20 years > ago) and that shielded me from all disk failures since then (although I > may have had silent corruption during the years I never lost any really > important data that way, some picture may have got lost that way > probably but it has been inconsequential for me). > > However I have had bad kernels, power outages, loss of battery power > (laptops on too long suspend) and other random reasons to force reboot > a system. That has been the primary case of file system checks through > my Fedora usage. And luckily so far I never had a loss of filesystem or > data that way, fsck always ended up solving most of the issues, and > whenever I lost file they ended up being temporary files I did not care > for. > > I do not think those failures are common in Facebook fleets, so I am > quite skeptical FB data and failure modes are representative of Fedora > usage as a desktop/laptop OS and therefore of the behavior of btrfs in > those cases. > > Note, not saying btrfs should be avoided or anything, just that we need > more data about those failure modes and how they affect btrfs before a > change of defaults. > Maybe it's not the most helpful anecdotal data, but one of my computers has been suffering through random CPU lockups to the point where everything freezes and I need to reboot. I'm pretty sure there's a fault in RAM or CPU (but with everything soldered on computers these days...), but it's been nice to see that with these issues happening to me fairly frequently (as in now basically weekly) forcing me to power cycle, Btrfs has withstood that perfectly. No data loss, no corruption, no inconsistencies. Everything just works. :) The last time I had something like this with an ext4 system, it got torched within a month, forcing me to spend money I couldn't really afford to spend to replace the machine. Btrfs is letting me use a bad computer longer. :) -- 真実はいつも一つ！/ 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: The future of legacy BIOS support in Fedora.
Once upon a time, nick...@gmail.com said: > To be honest, I don't know. Do all UEFI secure boot implementations > allow you to add your own keys to the list of trusted keys? I believe that the Microsoft OEM Windows x86_64 distribution requirements require UEFI, with Scure Boot enabled, and with the ability for the system admin to add their own signing keys. So, most every AMD/Intel system you run across should support that. -- Chris Adams ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/9/20 8:44 AM, Kevin Kofler wrote: Przemek Klosowski via devel wrote: * disk access is literally O(1) slower than RAM access This notation is meaningless. By the definition of the O notation, O(1)=O(1)=O(k) for any constant k. Yes, you are right of course, but I just hope that everyone understood that was just a shortcut for saying that the speed ratio is somewhere between 1e3 and 1e5 ___ 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: Make btrfs the default file system for desktop variants
On Thu, 2020-07-09 at 13:32 -0700, Davide Cavalca via devel wrote: > On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote: > > However I have had bad kernels, power outages, loss of battery power > > (laptops on too long suspend) and other random reasons to force > > reboot > > a system. That has been the primary case of file system checks > > through > > my Fedora usage. And luckily so far I never had a loss of filesystem > > or > > data that way, fsck always ended up solving most of the issues, and > > whenever I lost file they ended up being temporary files I did not > > care > > for. > > > > I do not think those failures are common in Facebook fleets, so I am > > quite skeptical FB data and failure modes are representative of > > Fedora > > usage as a desktop/laptop OS and therefore of the behavior of btrfs > > in > > those cases. > > As someone on one of the teams at FB that has to deal with that, I can > assure you all the scenarios you listed can and do happen, and they > happen a lot. While we don't have the "laptop's out of battery" issue > on the production side, we have plenty of power events and unplanned > maintenances that can and will hit live machines and cut power off. > Force reboots (triggered by either humans or automation) are also not > at all uncommon. Rebuilding machines from scratch isn't free, even with > all the automation and stuff we have, so if power loss or reboot events > on machines using btrfs caused widespread corruption or other issues > I'm confident we'd have found that out pretty early on. Oh this is really good to know, it is more reassuring! 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: Make btrfs the default file system for desktop variants
On Thu, 9 Jul 2020 at 16:49, Chris Murphy wrote: > > On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote: > > > > On 7/9/20 2:11 PM, Josef Bacik wrote: > > >> > > >> From what I've gathered from these responses, btrfs is unique in that > > >> it is > > >> /expected/ that if anything goes wrong, the administrator should be > > >> prepared > > >> to scrape out remaining data, re-mkfs, and start over. If that's > > >> acceptable > > >> for the Fedora desktop, that's fine, but I consider it a risk that > > >> should not > > >> be ignored when evaluating this proposal. > > >> > > > > > > Agreed, it's the very first thing I said when I was asked what are the > > > downsides. There's clearly more work to be done in the recovery arena. > > > How often do disks fail for Fedora? Do we have that data? Is this a > > > real risk? Nobody can say because Fedora doesn't have data. > > > > But again, let me reiterate that disk failures are far from the only > > reason that admins need capable filesystem repair tools, in general. > > > > We see users running fsck all the time, for various reasons. I can't > > back it up, but my hunch is that bugs and misconfigurations (i.e. write > > cache) are more often the root cause for filesystem inconsistencies. > > > > IMHO, focusing on physical disk failure rates is focusing too narrowly, > > but I suppose I'm just joining the chorus of hunches and anecdotes now. > > Actually there's quite a lot of evidence of this, even though there's > no precise estimate - not least of which these populations are > constantly dying and reemerging, and can be batch (firmware version) > specific. This is only the most recent such story on linux-btrfs@ (and > warning, this reads like an alien autopsy): > > https://lore.kernel.org/linux-btrfs/20200708034407.ge10...@hungrycats.org/ > > fsck.btrfs is a no op, same as fsck.xfs. And recently the actual > repair utility dissuades users from running it casually. > > COW file systems are different. ZFS has no fsck to speak of, it can be > harrassed badly by hardware/firmware bugs too, and yet there aren't > many people who consider ZFS a problemed file system. How would the > story of Btrfs be different either without dm-log-writes to this day, > or had it already arrived in 2010? > That is because anyone who questions the perfection of ZFS is quickly burned at a stake. I don't know what it is about filesystems turning into religions that do not brook questioning but what I am seeing in these emails is what turns me off of btrfs every time it is brought up in the same way I couldn't stand reiser, ZFS, or various other filesystems.. I realize filesystems take a lot of faith as people have to put something they value into a leap of faith it will be there the next day.. but it seems to morph quickly into some sort of fanatical evangelical movement. So a good reason why no one brings it up.. you learn quickly that questioning the perfection of any filesystem will fill your inbox with tirades from people. -- Stephen J Smoogen. ___ 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2020-07-10 from 21:00:00 to 22:00:00 UTC At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-6 #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9722/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Thu, 09 Jul 2020 23:10:46 +0300 nick...@gmail.com wrote: > On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote: > > That is, isn't this only an issue if the person doing the kernel > > development hasn't generated their own key, and isn't signing their > > kernels locally? > > To be honest, I don't know. Do all UEFI secure boot implementations > allow you to add your own keys to the list of trusted keys? I don't know, but I used Fedora tools to create the key pair, and insert the public key (x86_64). Anyway, just another data point in the discussion. ___ 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: Make btrfs the default file system for desktop variants
On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote: > > On 7/9/20 2:11 PM, Josef Bacik wrote: > >> > >> From what I've gathered from these responses, btrfs is unique in that it > >> is > >> /expected/ that if anything goes wrong, the administrator should be > >> prepared > >> to scrape out remaining data, re-mkfs, and start over. If that's > >> acceptable > >> for the Fedora desktop, that's fine, but I consider it a risk that should > >> not > >> be ignored when evaluating this proposal. > >> > > > > Agreed, it's the very first thing I said when I was asked what are the > > downsides. There's clearly more work to be done in the recovery arena. > > How often do disks fail for Fedora? Do we have that data? Is this a real > > risk? Nobody can say because Fedora doesn't have data. > > But again, let me reiterate that disk failures are far from the only > reason that admins need capable filesystem repair tools, in general. > > We see users running fsck all the time, for various reasons. I can't > back it up, but my hunch is that bugs and misconfigurations (i.e. write > cache) are more often the root cause for filesystem inconsistencies. > > IMHO, focusing on physical disk failure rates is focusing too narrowly, > but I suppose I'm just joining the chorus of hunches and anecdotes now. Actually there's quite a lot of evidence of this, even though there's no precise estimate - not least of which these populations are constantly dying and reemerging, and can be batch (firmware version) specific. This is only the most recent such story on linux-btrfs@ (and warning, this reads like an alien autopsy): https://lore.kernel.org/linux-btrfs/20200708034407.ge10...@hungrycats.org/ fsck.btrfs is a no op, same as fsck.xfs. And recently the actual repair utility dissuades users from running it casually. COW file systems are different. ZFS has no fsck to speak of, it can be harrassed badly by hardware/firmware bugs too, and yet there aren't many people who consider ZFS a problemed file system. How would the story of Btrfs be different either without dm-log-writes to this day, or had it already arrived in 2010? -- 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: Make btrfs the default file system for desktop variants
On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote: > However I have had bad kernels, power outages, loss of battery power > (laptops on too long suspend) and other random reasons to force > reboot > a system. That has been the primary case of file system checks > through > my Fedora usage. And luckily so far I never had a loss of filesystem > or > data that way, fsck always ended up solving most of the issues, and > whenever I lost file they ended up being temporary files I did not > care > for. > > I do not think those failures are common in Facebook fleets, so I am > quite skeptical FB data and failure modes are representative of > Fedora > usage as a desktop/laptop OS and therefore of the behavior of btrfs > in > those cases. As someone on one of the teams at FB that has to deal with that, I can assure you all the scenarios you listed can and do happen, and they happen a lot. While we don't have the "laptop's out of battery" issue on the production side, we have plenty of power events and unplanned maintenances that can and will hit live machines and cut power off. Force reboots (triggered by either humans or automation) are also not at all uncommon. Rebuilding machines from scratch isn't free, even with all the automation and stuff we have, so if power loss or reboot events on machines using btrfs caused widespread corruption or other issues I'm confident we'd have found that out pretty early on. Cheers Davide ___ 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: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 23:10 +0300, nick...@gmail.com wrote: > On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote: > > On Thu, 09 Jul 2020 18:07:39 +0300 > > nick...@gmail.com wrote: > > > > > Yes, that's why "secure boot" should only be an option and the user > > > must have the option to turn it off. Otherwise, it wouldn't be > > > possible to do any kernel development on that computer. > > > > For my edification. I build custom kernels, and sign them using > > pesign with my own key that I generated locally, and put in the EFI > > key > > database. I can then boot the custom kernel in secure mode. Couldn't > > I > > also sign modules if I ever generated them with that same key? > > > > That is, isn't this only an issue if the person doing the kernel > > development hasn't generated their own key, and isn't signing their > > kernels locally? > > To be honest, I don't know. Do all UEFI secure boot implementations > allow you to add your own keys to the list of trusted keys? In theory they should, but the interface may be broken or overly complicated. That said you can always disable secure boot on x86_64 ... not so on ARM based hw. 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: Make btrfs the default file system for desktop variants
On Thu, 2020-07-09 at 12:56 -0700, Eric Sandeen wrote: > On 7/9/20 2:11 PM, Josef Bacik wrote: > > > From what I've gathered from these responses, btrfs is unique in that it > > > is > > > /expected/ that if anything goes wrong, the administrator should be > > > prepared > > > to scrape out remaining data, re-mkfs, and start over. If that's > > > acceptable > > > for the Fedora desktop, that's fine, but I consider it a risk that should > > > not > > > be ignored when evaluating this proposal. > > > > > > > Agreed, it's the very first thing I said when I was asked what are the > > downsides. There's clearly more work to be done in the recovery arena. > > How often do disks fail for Fedora? Do we have that data? Is this a real > > risk? Nobody can say because Fedora doesn't have data. > > But again, let me reiterate that disk failures are far from the only > reason that admins need capable filesystem repair tools, in general. > > We see users running fsck all the time, for various reasons. I can't > back it up, but my hunch is that bugs and misconfigurations (i.e. write > cache) are more often the root cause for filesystem inconsistencies. > > IMHO, focusing on physical disk failure rates is focusing too narrowly, > but I suppose I'm just joining the chorus of hunches and anecdotes now. Anecdata, but I use raid-1 on all my disks (since a catastrophic failure 20 years ago) and that shielded me from all disk failures since then (although I may have had silent corruption during the years I never lost any really important data that way, some picture may have got lost that way probably but it has been inconsequential for me). However I have had bad kernels, power outages, loss of battery power (laptops on too long suspend) and other random reasons to force reboot a system. That has been the primary case of file system checks through my Fedora usage. And luckily so far I never had a loss of filesystem or data that way, fsck always ended up solving most of the issues, and whenever I lost file they ended up being temporary files I did not care for. I do not think those failures are common in Facebook fleets, so I am quite skeptical FB data and failure modes are representative of Fedora usage as a desktop/laptop OS and therefore of the behavior of btrfs in those cases. Note, not saying btrfs should be avoided or anything, just that we need more data about those failure modes and how they affect btrfs before a change of defaults. My 2c, 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: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote: > On Thu, 09 Jul 2020 18:07:39 +0300 > nick...@gmail.com wrote: > > > Yes, that's why "secure boot" should only be an option and the user > > must have the option to turn it off. Otherwise, it wouldn't be > > possible to do any kernel development on that computer. > > For my edification. I build custom kernels, and sign them using > pesign with my own key that I generated locally, and put in the EFI > key > database. I can then boot the custom kernel in secure mode. Couldn't > I > also sign modules if I ever generated them with that same key? > > That is, isn't this only an issue if the person doing the kernel > development hasn't generated their own key, and isn't signing their > kernels locally? To be honest, I don't know. Do all UEFI secure boot implementations allow you to add your own keys to the list of trusted keys? Nikolay ___ 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 1854753] perl-Sereal-4.015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1854753 --- Comment #7 from Fedora Update System --- FEDORA-2020-43a6a0fdca has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-43a6a0fdca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-43a6a0fdca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 1854754] perl-Sereal-Decoder-4.015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1854754 --- Comment #7 from Fedora Update System --- FEDORA-2020-43a6a0fdca has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-43a6a0fdca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-43a6a0fdca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 1854752] perl-Sereal-Encoder-4.015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1854752 --- Comment #7 from Fedora Update System --- FEDORA-2020-43a6a0fdca has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-43a6a0fdca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-43a6a0fdca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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: Make btrfs the default file system for desktop variants
On 7/9/20 2:11 PM, Josef Bacik wrote: >> >> From what I've gathered from these responses, btrfs is unique in that it is >> /expected/ that if anything goes wrong, the administrator should be prepared >> to scrape out remaining data, re-mkfs, and start over. If that's acceptable >> for the Fedora desktop, that's fine, but I consider it a risk that should not >> be ignored when evaluating this proposal. >> > > Agreed, it's the very first thing I said when I was asked what are the > downsides. There's clearly more work to be done in the recovery arena. How > often do disks fail for Fedora? Do we have that data? Is this a real risk? > Nobody can say because Fedora doesn't have data. But again, let me reiterate that disk failures are far from the only reason that admins need capable filesystem repair tools, in general. We see users running fsck all the time, for various reasons. I can't back it up, but my hunch is that bugs and misconfigurations (i.e. write cache) are more often the root cause for filesystem inconsistencies. IMHO, focusing on physical disk failure rates is focusing too narrowly, but I suppose I'm just joining the chorus of hunches and anecdotes now. -Eric > Facebook does however have that data, and it's a microscopically small > percentage. I agree that Facebook is vastly different from Fedora from a > recovery standpoint, but our workloads and hardware I think extrapolate to > the normal Fedora user quite well. We drive the disks harder than the normal > Fedora user does of course, but in the end we're updating packages, taking > snapshots, and building code. We're just doing it at 1000x what a normal > Fedora user does. Thanks, > > Josef ___ 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 1855334] perl-Sereal-Encoder-4.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855334 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Sereal-Encoder-4.016 |perl-Sereal-Encoder-4.017 |is available|is available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 4.017 Current version/release in rawhide: 4.011-1.fc32 URL: http://search.cpan.org/dist/Sereal-Encoder/ 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/8065/ -- 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 1855332] perl-Sereal-4.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855332 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Sereal-4.016 is|perl-Sereal-4.017 is |available |available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 4.017 Current version/release in rawhide: 4.011-1.fc32 URL: http://search.cpan.org/dist/Sereal/ 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/7605/ -- 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 1855333] perl-Sereal-Decoder-4.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855333 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Sereal-Decoder-4.016 |perl-Sereal-Decoder-4.017 |is available|is available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 4.017 Current version/release in rawhide: 4.011-1.fc32 URL: http://search.cpan.org/dist/Sereal-Decoder/ 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/8066/ -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thu, Jul 9, 2020 at 12:53 PM Brandon Nielsen wrote: > > On 7/9/20 12:24 PM, Alexey A. wrote: > > I agree. I think that 4GB cap is too small and 4 GB may be used quickly. > > > > > Since the values being used seem to have been determined somewhat > heuristically for both EarlyOOM and SwapOnZRAM, I was wondering if there > was any prediction for how the values might change if one, the other, or > both get switched on for Server builds? > > SwapOnZRAM in particular is of interest to me. I have one system with a > workload that's bursty on memory use, and when it starts using the swap > the system becomes unresponsive, even using active SSH sessions is not > guaranteed until the contention clears. The last time it happened I > found myself wondering if SwapOnZRAM would make things more pleasant. It > certainly does on my workstation machines, especially memory limited ones. Yeah we need to learn a little more about these cases. Spikes are very well suited by memory base swap (zram) or cache (zswap), because they can absorb the hit way faster than disk based swap. But those pools can become exhausted. So if the workload is spikey but not long lived, that's good for memory based swap. If it's enduring page out, or the anonymous pages become stale, that's a case where we might need a way to dump those to disk based swap still. Eventually I'd like to see either zram's writeback cache option (to disk, something exposed by sysfs but not by zramctl or zram-generator), or zswap have more clear benefit in these cases. So for those who like to experiment, I've got ideas. Also, we can detect reclaim via cgroups. Reclaim can look like swap thrashing in terms of IO. But it's with file pages, rather than anonymous pages. If reclaim pressure is increasing, it means we don't have enough swap. Or something needs to be killed off. Which is it, is the question. So what we don't want to do is just start adding more swap, because then we just end up back in the situation we're trying to solve. There is a need to choreograph a strategy between having enough of and the right kind of swap, a user space oom killer that responds to pressure, and resource control that ensures the apps we care about get minimum cpu, memory, and IO. It is possible to reincorporate disk based swap, possibly dynamically by creating swapfiles, but use resource control to restrict IO so that we don't get runaway swap thrashing. So even though swap partitions are going away by default in F33, does not necessarily mean we're done with disk based swap. These things are super esoteric and highly technical. But it's really been cool being part of this work happening in Fedora. The Workstation WG has been the central launching point of the motivating factors: the UX here is terrible, we have to do better than this. And then we get the kernel cgroup2, mm, zram, zswap folks building really interesting technologies to have the ability to get information about system state and control it. The systemd folks doing the work to make it possible to bridge that kernel work, making it accessible to the desktop developers - where this resource control isolation work is heavily developed in GNOME and KDE. And then it feeds back quite quickly into Fedora. There's a long list of developers who have done 8 bajillion percent more work than my emails and change proposals on these subjects. -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thursday, July 9, 2020 9:22:01 AM MST Alexey A. wrote: > >You can limit the process with cgroups > > In this case the process will be killed by OOM killer. Note that OOM killer > exists by default. Limiting cgroup means the OOM killer will be invoked in > the cgroup. With earlyoom you database server will get SIGTERM and maybe > will gracefully shutdown. I'm suggesting the use of cgroups on software like web browsers, that users complain run away with RAM, certainly not databases. -- 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: Make btrfs the default file system for desktop variants
On 7/9/20 1:51 PM, Eric Sandeen wrote:
On 7/6/20 12:07 AM, Chris Murphy wrote:
On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
wrote:
On 7/3/20 1:41 PM, Chris Murphy wrote:
SSDs can fail in weird ways. Some spew garbage as they're
failing, some go read-only. I've seen both. I don't have stats on
how common it is for an SSD to go read-only as it fails, but once
it happens you cannot fsck it. It won't accept writes. If it
won't mount, your only chance to recover data is some kind of
offline scrape tool. And Btrfs does have a very very good scrape
tool, in terms of its success rate - UX is scary. But that can
and will improve.
Ok, you and Josef have both recommended the btrfs restore
("scrape") tool as a next recovery step after fsck fails, and I
figured we should check that out, to see if that alleviates the
concerns about recoverability of user data in the face of
corruption.
I also realized that mkfs of an image isn't representative of an
SSD system typical of Fedora laptops, so I added "-m single" to
mkfs, because this will be the mkfs.btrfs default on SSDs (right?).
Based on Josef's description of fsck's algorithm of throwing away
any block with a bad CRC this seemed worth testing.
I also turned fuzzing /down/ to hitting 2048 bytes out of the 1G
image, or a bit less than 1% of the filesystem blocks, at random.
This is 1/4 the fuzzing rate from the original test.
So: -m single, fuzz 2048 bytes of 1G image, run btrfsck --repair,
mount, mount w/ recovery, and then restore ("scrape") if all that
fails, see what we get.
What's the probability of this kind of corruption occurring in the
real world? If the probability is so low it can't practically be
computed, how do we assess the risk? And if we can't assess risk,
what's the basis of concern?
From 20 years of filesystem development experience, I know that people
run filesystem repair tools. It's just a fact. For a wide variety of
reasons - from bugs, to hardware errors, to admin errors, you name it,
filesystems experience corruption and inconsistencies. At that point
the administrator needs a path forward.
"people won't need to repair btrfs" is, IMHO, the position that needs
to be supported, not "filesystem repair tools should be robust."
I ran 50 loops, and got:
46 btrfsck failures 20 mount failures
So it ran btrfs restore 20 times; of those, 11 runs lost all or
substantially all of the files; 17 runs lost at least 1/3 of the
files.
Josef states reliability of ext4, xfs, and Btrfs are in the same
ballpark. He also reports one case in 10 years in which he failed to
recover anything. How do you square that with 11 complete failures,
trivially produced? Is there even a reason to suspect there's
residual risk?
Extrapolating from Facebook's usecases to the fedora desktop should be
approached with caution, IMHO.
I've provided evidence that if/when damage happens for whatever reason,
btrfs is unable to recover in place far more often than other filesytems.
When metadata is single profile, Btrfs is basically an early warning
system.> The available research on uncorrectable errors, errors that drive ECC
does not catch, suggests that users are decently likely to experience
at least one block of corruption in the life of the drive. And that
it tends to get worse up until drive failure. But there is much less
chance to detect this, if the file system isn't also checksumming the
vastly larger payload on a drive: the data.
One of the problems in this whole discussion is the assumption that filesystem
inconsistencies only arise from disk bitflips etc; that's just not the case.
Look, I'm just providing evidence of what I've found when re-evaluating the
btrfs administration/repair tools. I've found them to be quite weak.
From what I've gathered from these responses, btrfs is unique in that it is
/expected/ that if anything goes wrong, the administrator should be prepared
to scrape out remaining data, re-mkfs, and start over. If that's acceptable
for the Fedora desktop, that's fine, but I consider it a risk that should not
be ignored when evaluating this proposal.
Agreed, it's the very first thing I said when I was asked what are the
downsides. There's clearly more work to be done in the recovery arena. How
often do disks fail for Fedora? Do we have that data? Is this a real risk?
Nobody can say because Fedora doesn't have data.
Facebook does however have that data, and it's a microscopically small
percentage. I agree that Facebook is vastly different from Fedora from a
recovery standpoint, but our workloads and hardware I think extrapolate to the
normal Fedora user quite well. We drive the disks harder than the normal Fedora
user does of course, but in the end we're updating packages, taking snapshots,
and building code. We're just doing it at 1000x what a normal Fedora user does.
Thanks,
Josef
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
Re: Bodhi 5.4.0 in production
Il 09/07/20 15:12, Miro Hrončok ha scritto: > > Finally I got to testing this. > > The bugzilla was added to the update: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-c1be13ded8 > > But it was not closed: > > https://bugzilla.redhat.com/show_bug.cgi?id=1851519 > > Should I report this as a bug or am i doing something wrong? The commit is: > > https://src.fedoraproject.org/rpms/python-tox/c/d154cf5aabe445914123b41239243811eeac93b7?branch=master > > But the build was done from one clenaup commit above this. Is that relevant? > The feature is not completely working in Bodhi 5.4.0, a fix is ready [1] and it will be deployed with the next bugfix (probably 5.4.1) Mattia [1] https://github.com/fedora-infra/bodhi/pull/4068 ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/9/20 12:24 PM, Alexey A. wrote: I agree. I think that 4GB cap is too small and 4 GB may be used quickly. Since the values being used seem to have been determined somewhat heuristically for both EarlyOOM and SwapOnZRAM, I was wondering if there was any prediction for how the values might change if one, the other, or both get switched on for Server builds? SwapOnZRAM in particular is of interest to me. I have one system with a workload that's bursty on memory use, and when it starts using the swap the system becomes unresponsive, even using active SSH sessions is not guaranteed until the contention clears. The last time it happened I found myself wondering if SwapOnZRAM would make things more pleasant. It certainly does on my workstation machines, especially memory limited ones. ___ 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: Make btrfs the default file system for desktop variants
On 7/6/20 8:21 PM, Chris Murphy wrote: ... > Yes. Also in fuzzing there is the concept of "when to stop fuzzing" > because it's a rabbit hole, you have to come up for air at some point, > and work on other things. But you raise a good and subtle point which > is also that ext4 has a very good fsck built up over decades, they > succeed today from past failures. It's no different with Btrfs. > > But also there is a bias. ext4 needs fsck to succeed in the worst > cases in order to mount the file system. Really? > Btrfs doesn't need that. > Often it can tolerate a read-only mount without any other mount > option; Well, this assertion can be tested, so let's do that as well; I'll do 50 runs of: * mkfs w/ -m single as would happen on SSD * fuzz 2048 byte of that 1G image at random * mount -o ro, tally mount failures * count missing/unreachable files if mount -o ro succeeds <50 runs later on btrfs> 16 readonly mounts failed (32% failure rate) Within the successful mounts, 1 or more files were unreachable in 30 attempts. Across all 50 attempts, 7720 files were lost. Is that better than ext4, and will ext4 need fsck just to be able to mount? <50 runs later on ext4, same strategy> zero mount failures for ext4. Within the successful mounts, 1 or more files were unreachable in 2 attempts. Across all 50 attempts, 48 files were lost. It does not seem that btrfs has any unique or superior mount -o ro recovery capabilities, either. > and optionally can be made more tolerant to errors while still > mounting read-only. This is a significant difference in recovery > strategy. An fsck is something of a risk because it is writing changes > to the file system. It is irreversible. Btrfs takes a different view, > which is to increase the chance of recovery without needing a risky > repair as the first step. Once your important data is out, now try the > repair. Good chance it works, but maybe not as good as ext4's. That's not supported by any of these test results. -Eric ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, 2020-07-09 at 11:09 -0700, Adam Williamson wrote: > On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote: > > On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > > > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" > > > > action on > > > > a system upgrade, because we want that package to be prensented on > > > > the > > > > system. However I worry that DNF does not possess a capability for > > > > doing > > > > it. (Except of injecting that command into some externally executed > > > > script.) > > > > > > Unless I'm mistaken, it should only be present if the user manually > > > installed > > > it, and opted into modularity, right? > > > > No, it should be installed by default. > > Are you talking about upgrades here, or fresh installs? > > It is not being installed on fresh installs presently, and as I read > the ticket, that was intended, per your comment: > https://pagure.io/fesco/issue/2114#comment-653352 > "Probably best way would be going back to "Boltron" (IIRC how that > thing was called) and have modular repos in their own fedora-repos > subpackage which are enabled by default, but the package **is not > installed by default.**" (emphasis added) Oh, looking at it again, now I see this: https://pagure.io/fesco/issue/2406#comment-658315 which seems to suggest that FESCo expects fedora-repos-modular to be installed out of the box. Well, in yesterday's and today's Rawhide (default Server DVD install) it wasn't, openQA caught this. On my first reading of #2114 I figured this was intentional and adjusted openQA to install fedora-repos-modular , but it sounds like it's actually a bug and comps and/or kickstarts and/or package dependencies will need to be changed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: The future of legacy BIOS support in Fedora.
On Thu, 09 Jul 2020 18:07:39 +0300 nick...@gmail.com wrote: > Yes, that's why "secure boot" should only be an option and the user > must have the option to turn it off. Otherwise, it wouldn't be > possible to do any kernel development on that computer. For my edification. I build custom kernels, and sign them using pesign with my own key that I generated locally, and put in the EFI key database. I can then boot the custom kernel in secure mode. Couldn't I also sign modules if I ever generated them with that same key? That is, isn't this only an issue if the person doing the kernel development hasn't generated their own key, and isn't signing their kernels locally? ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, Jul 09, 2020 at 11:09:57AM -0700, Adam Williamson wrote: > What we're dealing with now is awkward consequences of this change for > existing installs, where we'd probably want to *keep* modular repos, > especially if any modules are actually enabled. Is it a terrible idea to suggest that MBS insert a "Requires: fedora-repos-modular" into all of the packages built in that system? -- Matthew Miller Fedora Project Leader ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thu, Jul 09, 2020 at 10:40:39AM -0700, John M. Harris Jr wrote: > I briefly discussed the situation with bcotton, and that's how it'll handle > that in the future. I wasn't aware of the particular situation. Thanks John! -- Matthew Miller Fedora Project Leader ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on > > a system upgrade, because we want that package to be prensented on the > > system. However I worry that DNF does not possess a capability for doing > > it. (Except of injecting that command into some externally executed > > script.) > > Unless I'm mistaken, it should only be present if the user manually installed > it, and opted into modularity, right? The slightly missing context is that the package is new and did not exist until a couple of days ago. Previously modular repos were part of fedora-repos , they have now been split into a separate subpackage which is not be installed by default on fresh installs, effectively meaning the whole modularity system is now optional and not available by default, only if the user runs 'dnf install fedora-repos-modular'. What we're dealing with now is awkward consequences of this change for existing installs, where we'd probably want to *keep* modular repos, especially if any modules are actually enabled. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote: > On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" > > > action on > > > a system upgrade, because we want that package to be prensented on > > > the > > > system. However I worry that DNF does not possess a capability for > > > doing > > > it. (Except of injecting that command into some externally executed > > > script.) > > > > Unless I'm mistaken, it should only be present if the user manually > > installed > > it, and opted into modularity, right? > > No, it should be installed by default. Are you talking about upgrades here, or fresh installs? It is not being installed on fresh installs presently, and as I read the ticket, that was intended, per your comment: https://pagure.io/fesco/issue/2114#comment-653352 "Probably best way would be going back to "Boltron" (IIRC how that thing was called) and have modular repos in their own fedora-repos subpackage which are enabled by default, but the package **is not installed by default.**" (emphasis added) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
https://fedoraproject.org/wiki/Changes/ModularPolicy == Summary == Establish a set of rules for Modular content in Fedora to ensure an optimal user and packager experience. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email: sgall...@redhat.com == Detailed Description == Over the last several months, members of the Modularity WG and FESCo have been working to establish a policy for module inclusion in Fedora. We now have a proposal that FESCo requested be taken to the Fedora community via the Change Proposal. There is a preview of the new policy available at https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ == Benefit to Fedora == This policy makes explicit what packagers can and cannot do with Modules in Fedora, which should avoid future issues like those that were seen during the Fedora 31 and Fedora 32 cycles. == Scope == * Proposal owners: The proposal is written, so minimal work remains. We may need to make revisions or clarifications based on public feedback. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == N/A this is not a user-facing change. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
https://fedoraproject.org/wiki/Changes/ModularPolicy == Summary == Establish a set of rules for Modular content in Fedora to ensure an optimal user and packager experience. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email: sgall...@redhat.com == Detailed Description == Over the last several months, members of the Modularity WG and FESCo have been working to establish a policy for module inclusion in Fedora. We now have a proposal that FESCo requested be taken to the Fedora community via the Change Proposal. There is a preview of the new policy available at https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ == Benefit to Fedora == This policy makes explicit what packagers can and cannot do with Modules in Fedora, which should avoid future issues like those that were seen during the Fedora 31 and Fedora 32 cycles. == Scope == * Proposal owners: The proposal is written, so minimal work remains. We may need to make revisions or clarifications based on public feedback. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == N/A this is not a user-facing change. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: Make btrfs the default file system for desktop variants
On 7/6/20 12:07 AM, Chris Murphy wrote:
> On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
> wrote:
>>
>> On 7/3/20 1:41 PM, Chris Murphy wrote:
>>> SSDs can fail in weird ways. Some spew garbage as they're
>>> failing, some go read-only. I've seen both. I don't have stats on
>>> how common it is for an SSD to go read-only as it fails, but once
>>> it happens you cannot fsck it. It won't accept writes. If it
>>> won't mount, your only chance to recover data is some kind of
>>> offline scrape tool. And Btrfs does have a very very good scrape
>>> tool, in terms of its success rate - UX is scary. But that can
>>> and will improve.
>>
>> Ok, you and Josef have both recommended the btrfs restore
>> ("scrape") tool as a next recovery step after fsck fails, and I
>> figured we should check that out, to see if that alleviates the
>> concerns about recoverability of user data in the face of
>> corruption.
>>
>> I also realized that mkfs of an image isn't representative of an
>> SSD system typical of Fedora laptops, so I added "-m single" to
>> mkfs, because this will be the mkfs.btrfs default on SSDs (right?).
>> Based on Josef's description of fsck's algorithm of throwing away
>> any block with a bad CRC this seemed worth testing.
>>
>> I also turned fuzzing /down/ to hitting 2048 bytes out of the 1G
>> image, or a bit less than 1% of the filesystem blocks, at random.
>> This is 1/4 the fuzzing rate from the original test.
>>
>> So: -m single, fuzz 2048 bytes of 1G image, run btrfsck --repair,
>> mount, mount w/ recovery, and then restore ("scrape") if all that
>> fails, see what we get.
>
> What's the probability of this kind of corruption occurring in the
> real world? If the probability is so low it can't practically be
> computed, how do we assess the risk? And if we can't assess risk,
> what's the basis of concern?
From 20 years of filesystem development experience, I know that people
run filesystem repair tools. It's just a fact. For a wide variety of
reasons - from bugs, to hardware errors, to admin errors, you name it,
filesystems experience corruption and inconsistencies. At that point
the administrator needs a path forward.
"people won't need to repair btrfs" is, IMHO, the position that needs
to be supported, not "filesystem repair tools should be robust."
>> I ran 50 loops, and got:
>>
>> 46 btrfsck failures 20 mount failures
>>
>> So it ran btrfs restore 20 times; of those, 11 runs lost all or
>> substantially all of the files; 17 runs lost at least 1/3 of the
>> files.
>
> Josef states reliability of ext4, xfs, and Btrfs are in the same
> ballpark. He also reports one case in 10 years in which he failed to
> recover anything. How do you square that with 11 complete failures,
> trivially produced? Is there even a reason to suspect there's
> residual risk?
Extrapolating from Facebook's usecases to the fedora desktop should be
approached with caution, IMHO.
I've provided evidence that if/when damage happens for whatever reason,
btrfs is unable to recover in place far more often than other filesytems.
> When metadata is single profile, Btrfs is basically an early warning
> system.> The available research on uncorrectable errors, errors that drive ECC
> does not catch, suggests that users are decently likely to experience
> at least one block of corruption in the life of the drive. And that
> it tends to get worse up until drive failure. But there is much less
> chance to detect this, if the file system isn't also checksumming the
> vastly larger payload on a drive: the data.
One of the problems in this whole discussion is the assumption that filesystem
inconsistencies only arise from disk bitflips etc; that's just not the case.
Look, I'm just providing evidence of what I've found when re-evaluating the
btrfs administration/repair tools. I've found them to be quite weak.
From what I've gathered from these responses, btrfs is unique in that it is
/expected/ that if anything goes wrong, the administrator should be prepared
to scrape out remaining data, re-mkfs, and start over. If that's acceptable
for the Fedora desktop, that's fine, but I consider it a risk that should not
be ignored when evaluating this proposal.
-Eric
___
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thursday, July 9, 2020 10:32:06 AM MST Matthew Miller wrote: > On Thu, Jul 09, 2020 at 08:46:57AM -0700, John M. Harris Jr wrote: > > > On Thursday, July 9, 2020 8:17:50 AM MST you wrote: > > > > > keep private mail private idiot > > > > > > You're responding to my post on a mailing list. I don't see any reason to > > keep this private. I'm not the only one on this list that you've > > attempted to contact directly with this sort of comment either, and I > > believe it's important that others are aware. > > > I also don't see any reason to be required to keep unsolicited negative > "private" emails secret. There's no agreement that they should be. However, > I would request that you ignore them rather than bringing them back to the > list. We can unsubscribe and moderate, but we can't do anything about > reading and off-list replies, and I'd prefer for them to not get dragged > back here. (My suggestion is to just ignore.) > > -- > Matthew Miller > > Fedora Project Leader I briefly discussed the situation with bcotton, and that's how it'll handle that in the future. I wasn't aware of the particular situation. -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thu, Jul 09, 2020 at 08:46:57AM -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 8:17:50 AM MST you wrote: > > keep private mail private idiot > > You're responding to my post on a mailing list. I don't see any reason to > keep > this private. I'm not the only one on this list that you've attempted to > contact directly with this sort of comment either, and I believe it's > important that others are aware. I also don't see any reason to be required to keep unsolicited negative "private" emails secret. There's no agreement that they should be. However, I would request that you ignore them rather than bringing them back to the list. We can unsubscribe and moderate, but we can't do anything about reading and off-list replies, and I'd prefer for them to not get dragged back here. (My suggestion is to just ignore.) -- Matthew Miller Fedora Project Leader ___ 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: Btrfs by default, the compression option
On Wed, Jul 08, 2020 at 02:20:06PM -0700, John M. Harris Jr wrote: > > Yeah I guess for /usr the most relevant write metric is "does it slow down > > DNF upgrades or install operations enough to be noticeable / annoying / > > problematic"? > More importantly, does it hurt the performance of installed packages? Definitely. I expect for reads the impact will be negligible in most cases (possible improvements in some, even), but it's important to validate that. -- Matthew Miller Fedora Project Leader ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>75% and 6G >for the cap might be better. I agree. I think that 4GB cap is too small and 4 GB may be used quickly. >I regularly see 3 to 1 and even 4 to 1. It's true. It's easy to get 4:1 with browser. In fact, the compression ratio is highly dependent on the workload. I get 1.4:1 with blender, and maybe 100:1 with compressing zeroes in tmpfs: https://imgur.com/a/XfNRedA пт, 10 июл. 2020 г. в 01:46, Chris Murphy : > On Thu, Jul 9, 2020 at 8:52 AM John M. Harris Jr > wrote: > > > What's the KDE SIG's rationale behind supporting this? This actively > limits > > the amount of RAM that end users are able to make use of. The more RAM > the end > > user has, the more RAM is not available for use, because EarlyOOM will > kill > > software long before it's able to be used. For example, on my system, > with 6 > > GiB of RAM, this will send SIGTERM while I still have over half of a > gigabyte > > of RAM, and SIGKILL while I still have over a quarter of a gigabyte of > RAM. > > 6G RAM means a 3G /dev/zram0 device that will use ~ 1.5G RAM *if* the > swap device is full and we're only getting 2 to 1 compression. 2 to 1 > is conservative I regularly see 3 to 1 and even 4 to 1. But let's go > with 2:1. This means your system has the effective benefit of running > 9G RAM at a cost of 1.5G. i.e a net of 7.5G RAM. Without having to use > disk based swap. > > Is it possible a case can be made for using zswap instead (this is not > related to zram at all - this is compressed memory cache that acts as > a writeback cache to an existing disk based swap)? Yes. I've made this > argument myself, so has Alexey. And as we learn more about those use > case and workloads, it is possible that it may be a future feature. > It's even possible it gets rolled into zram-generator so that users > don't have to fuss with these things. But in the meantime? We are > learning and innovating. And by all means try to break it. No one > wants users to have a suboptimal experience out of the box. > > My suggestion is to stop the 'complaining for the sake of complaining' > phase of the feature. And move to the "when I do X Y Z, this other app > is killed off - how to tweak this?" And then does the tweak represent > covering an edge case? Or is it good enough to be the new default? > > We can certainly change the defaults in the F33 cycle for both > swaponzram and earlyoom. In fact we can change the defaults with a > regular update if we have clear data that we should do that. But we've > entered the real world phase of testing. And the hypotheticals from > just complaining isn't very useful, even if those complaints later > turn out to be valid. Data is what will persuade. > > There's lots of data from Fedora IoT and other use cases out there > that 50% RAM for the /dev/zram size is a pretty good start. It's > likely it could go to 75% even in the Fedora 33 time frame. So folks > should really try to do too much with the defaults and see if they can > get some failures or unexpected behaviors. And then see if 75% > consistently solves it. Not that some folks might need to bump the cap > above 4GB to see an increase if they change the fraction of memory > used for zram. > > For sure this only seems like magic. The efficacy of disk based swap > is 100%. When a page is evicted, 100% of it goes to disk and 0% > remains in memory. For swaponzram, the efficacy depends on the > compression ratio. It's definitely not 0% (unless it's random or > encrypted data) and it's definitely not 100% even if it's all zeros in > the page. But we're going to get at least 50% efficacy. The overall > efficiency of memory utilization is still better. But yeah, in tight > situations it could be a problem. We need to learn more. 75% and 6G > for the cap might be better. But that also has a risk for upgrades, > which is that now on a 6G RAM system, /dev/zram is 4.5G which might > consume 2.3G RAM. So it's going to be a particularly special workload > that really wants to live fully in 4+ GB of memory. If it has to do a > bunch of paging in and out through? It's certainly going to be faster > still than doing that same paging to/from disk based swap. > > And for sure it is better than the noswap case, which means 0% > eviction efficacy. Those anonymous pages can't go anywhere, they're > pinned in RAM. At least with a zram based swap, they take up 1/2 or > less the memory. > > So it's a bit more like magic than not. It's pretty cool. But yeah we > should try to break it. > > > > -- > 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: SwapOnZRAM and how it affects earlyoom thresholds
On Thu, Jul 9, 2020 at 10:49 am, Rex Dieter wrote: Upon reading the SwapOnZRAM feature proposal, I see it is advocating allocating 50% of ram for swap. I'd like folks to consider and evaluate how this impacts earlyoom. It effectively makes the earlyoom memory threshold double (right?). If so, at least think about lowering 4 to (2 or 3), since that will make earlyoom's behavior closer to before swaponzram was introduced. Well it's min(50% of RAM, 4 GB). You never get more than 4 GB of zram. ___ 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: 20200709.n.0 changes
OLD: Fedora-Rawhide-20200708.n.0 NEW: Fedora-Rawhide-20200709.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 13 Dropped packages:23 Upgraded packages: 135 Downgraded packages: 0 Size of added packages: 89.61 MiB Size of dropped packages:32.80 MiB Size of upgraded packages: 2.79 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 126.77 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20200709.n.0.iso = DROPPED IMAGES = Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20200708.n.0.iso = ADDED PACKAGES = Package: golang-github-gocomply-scap-0-0.1.20200708git27dcc4e.fc33 Summary: A GO module of the Security Content Automation Protocol (SCAP) Specification RPMs:golang-github-gocomply-scap-devel Size:173.43 KiB Package: golang-github-zeebo-admission-3.0.1-1.fc33 Summary: Admission is a package for processing a bunch of udp packets RPMs:golang-github-zeebo-admission-devel Size:22.44 KiB Package: golang-github-zeebo-incenc-0-0.1.20200708git0d92902.fc33 Summary: Incremental Encoding RPMs:golang-github-zeebo-incenc-devel Size:16.48 KiB Package: golang-storj-drpc-0.0.13-1.fc33 Summary: Light replacement for gprc RPMs:golang-storj-drpc golang-storj-drpc-devel Size:10.49 MiB Package: golie-0-0.1.20200708git9dd93d8.fc33 Summary: A client/server implementation of ROLIE written in GO RPMs:golang-github-rolieup-golie-devel golie Size:25.27 MiB Package: gstreamer1-doc-1.17.2-2.fc33 Summary: GStreamer documentation RPMs:gstreamer1-doc Size:36.40 MiB Package: libmysofa-1.1-1.fc33 Summary: C functions for reading HRTFs RPMs:libmysofa libmysofa-devel mysofa Size:5.70 MiB Package: librhsm-0.0.3-1.fc33 Summary: Red Hat Subscription Manager library RPMs:librhsm librhsm-devel Size:260.92 KiB Package: libspatialaudio-3.1-1.20200406gitd926a2e.fc33 Summary: Ambisonic encoding / decoding and binauralization library RPMs:libspatialaudio libspatialaudio-devel Size:10.86 MiB Package: python-django-contrib-comments-1.9.2-1.fc33 Summary: The code formerly known as django.contrib.comments RPMs:python3-django-contrib-comments Size:199.89 KiB Package: python-fastprogress-0.2.3-1.fc33 Summary: Progress bar for Jupyter Notebook and console RPMs:python3-fastprogress Size:27.88 KiB Package: rust-enumflags2_derive-0.6.4-1.fc33 Summary: Do not use directly, use the reexport in the `enumflags2` crate RPMs:rust-enumflags2_derive+default-devel rust-enumflags2_derive+not_literal-devel rust-enumflags2_derive-devel Size:25.76 KiB Package: uresourced-0.1.0-1.fc33 Summary: Dynamically allocate resources to the active user RPMs:uresourced Size:185.09 KiB = DROPPED PACKAGES = Package: abgraph-1.1-18.fc32 Summary: ABGraph is a simple tool to benchmark webservers RPMs:abgraph Size:20.32 KiB Package: accrete-1.0-22.fc32 Summary: Accrete is a physical simulation of solar system planet formation RPMs:accrete Size:118.26 KiB Package: astronomy-backgrounds-1.0-18.fc32 Summary: Desktop wallpapers with Astronomy theme RPMs:astronomy-backgrounds Size:1.28 MiB Package: astronomy-bookmarks-1-23.fc32 Summary: Fedora astronomy bookmarks RPMs:astronomy-bookmarks Size:8.67 KiB Package: cvsgraph-1.6.1-27.fc32 Summary: CVS/RCS repository grapher RPMs:cvsgraph Size:504.85 KiB Package: cvsplot-1.7.4-23.fc32 Summary: Collect statistics from CVS controlled files RPMs:cvsplot Size:28.19 KiB Package: cvsweb-3.0.6-25.fc32 Summary: Web interface for CVS repositories RPMs:cvsweb Size:70.40 KiB Package: eris-1.3.23-16.fc31 Summary: Client-side session layer for Atlas-C++ RPMs:eris eris-devel Size:2.11 MiB Package: gcx-0.9.11-27.fc32 Summary: Data-reduction tool for CCD photometry RPMs:gcx Size:1.82 MiB Package: ggobi-2.1.7-24.fc32 Summary: Open source visualization for exploring high-dimensional data RPMs:ggobi ggobi-devel Size:4.12 MiB Package: ircd-ratbox-3.0.10-6.fc32 Summary: Ircd-ratbox is an advanced, stable and fast ircd RPMs:ircd-ratbox ircd-ratbox-mkpasswd Size:5.53 MiB Package: mencal-2.3-20.fc32 Summary: Menstruation calendar RPMs:mencal Size:26.00 KiB Package: mercator-0.3.3-15.fc31 Summary: Terrain library for WorldForge client/server RPMs:mercator mercator-devel Size:1.84 MiB Package: nightfall-1.92-4.fc32 Summary: Nightfall is an astronomy application for emulation of eclipsing stars RPMs:nightfall Size:4.08 MiB Package: pam_ccreds-10-21.fc32 Summary: Pam module to cache login credentials RPMs:pam_ccreds Size:169.19 KiB Package: pyephem-3.7.6.0-19.fc33 Summary: Basic astronomical computations for Python RPMs:python3-pyephem Size:3.24 MiB Package: ratbox
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thu, Jul 9, 2020 at 8:52 AM John M. Harris Jr wrote: > What's the KDE SIG's rationale behind supporting this? This actively limits > the amount of RAM that end users are able to make use of. The more RAM the end > user has, the more RAM is not available for use, because EarlyOOM will kill > software long before it's able to be used. For example, on my system, with 6 > GiB of RAM, this will send SIGTERM while I still have over half of a gigabyte > of RAM, and SIGKILL while I still have over a quarter of a gigabyte of RAM. 6G RAM means a 3G /dev/zram0 device that will use ~ 1.5G RAM *if* the swap device is full and we're only getting 2 to 1 compression. 2 to 1 is conservative I regularly see 3 to 1 and even 4 to 1. But let's go with 2:1. This means your system has the effective benefit of running 9G RAM at a cost of 1.5G. i.e a net of 7.5G RAM. Without having to use disk based swap. Is it possible a case can be made for using zswap instead (this is not related to zram at all - this is compressed memory cache that acts as a writeback cache to an existing disk based swap)? Yes. I've made this argument myself, so has Alexey. And as we learn more about those use case and workloads, it is possible that it may be a future feature. It's even possible it gets rolled into zram-generator so that users don't have to fuss with these things. But in the meantime? We are learning and innovating. And by all means try to break it. No one wants users to have a suboptimal experience out of the box. My suggestion is to stop the 'complaining for the sake of complaining' phase of the feature. And move to the "when I do X Y Z, this other app is killed off - how to tweak this?" And then does the tweak represent covering an edge case? Or is it good enough to be the new default? We can certainly change the defaults in the F33 cycle for both swaponzram and earlyoom. In fact we can change the defaults with a regular update if we have clear data that we should do that. But we've entered the real world phase of testing. And the hypotheticals from just complaining isn't very useful, even if those complaints later turn out to be valid. Data is what will persuade. There's lots of data from Fedora IoT and other use cases out there that 50% RAM for the /dev/zram size is a pretty good start. It's likely it could go to 75% even in the Fedora 33 time frame. So folks should really try to do too much with the defaults and see if they can get some failures or unexpected behaviors. And then see if 75% consistently solves it. Not that some folks might need to bump the cap above 4GB to see an increase if they change the fraction of memory used for zram. For sure this only seems like magic. The efficacy of disk based swap is 100%. When a page is evicted, 100% of it goes to disk and 0% remains in memory. For swaponzram, the efficacy depends on the compression ratio. It's definitely not 0% (unless it's random or encrypted data) and it's definitely not 100% even if it's all zeros in the page. But we're going to get at least 50% efficacy. The overall efficiency of memory utilization is still better. But yeah, in tight situations it could be a problem. We need to learn more. 75% and 6G for the cap might be better. But that also has a risk for upgrades, which is that now on a 6G RAM system, /dev/zram is 4.5G which might consume 2.3G RAM. So it's going to be a particularly special workload that really wants to live fully in 4+ GB of memory. If it has to do a bunch of paging in and out through? It's certainly going to be faster still than doing that same paging to/from disk based swap. And for sure it is better than the noswap case, which means 0% eviction efficacy. Those anonymous pages can't go anywhere, they're pinned in RAM. At least with a zram based swap, they take up 1/2 or less the memory. So it's a bit more like magic than not. It's pretty cool. But yeah we should try to break it. -- 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
incorrect docs for forge macro extension, when using 'unknown' scm source (e.g., git.kernel.org) ?
I'm working on a spec, pulling source with forgemeta/scm
With known/supported scm sources (e.g., github), it works as expected, with no
issues.
Atm, I'm trying to pull from a different source,
git.kernel.org
with this 'ofono-test.spec'
%global forgeurl
https://git.kernel.org/pub/scm/network/ofono/ofono.git
%global commit aeeb321a72d0b84c0fe5008dc7c49f0707582ca0
%forgemeta -i -a
Name: ofono
Version: 0
Release: %{dist}
Summary: ofono
License: GPL-2.0
URL: %{forgeurl}
Source:%{forgesource}
BuildRequires: git
%description
ofono
%prep
%forgesetup
%build
%install
%files
%changelog
"build through %prep" stage fails
rpmbuild --clean --verbose -bp ofono-test.spec
Packaging variables read or set by %forgemeta
forgeurl0:
https://git.kernel.org/pub/scm/network/ofono/ofono.git
forgesource0: #/.%{archiveext0}
forgesetupargs0: -c -n %{archivename0}
extractdir0: %{archivename0}
commit0: aeeb321a72d0b84c0fe5008dc7c49f0707582ca0
distprefix0: .%{scm0}aeeb321
dist: .%{scm0}aeeb321.fc32
(snapshot date is either manually supplied or computed once
%{_sourcedir}/%{archivename0}.%{archiveext0} is available)
warning: line 8: Possible unexpanded macro in: Release:
.%{scm0}aeeb321.fc32
error: Bad source: /root/rpmbuild/SOURCES/.%{archiveext0}: No
such file or directory
Not at all clear what the actual problem is. Since it _does_ work with
gitbub/gitlab sources, I'd _guess_ it's a URL/source string format issue ...
Reading at
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Extending_the_macro
states
"locate the latest version of the forgemeta macro (it should be
installed in /usr/lib/rpm/macros.d/macros.forge-srpm by fedora-rpm-macros)"
the package is installed
dnf list --installed fedora-rpm-macros
Installed Packages
fedora-rpm-macros.noarch26-8.fc32@fedora
there's no such file
ls -al /usr/lib/rpm/macros.d/macros.forge-srpm
ls: cannot access '/usr/lib/rpm/macros.d/macros.forge-srpm': No
such file or directory
checking
rpm -ql fedora-rpm-macros
/usr/lib/rpm/macros.d/macros.fedora
and, the file's empty
cat /usr/lib/rpm/macros.d/macros.fedora
# Miscellaneous Fedora-related RPM macros.
# Currently there is nothing here.
(1) Are there up-to-date/correct docs for 'Extending the macro' ?
(2) Is there an explcit example for use with 'git.kernel.org' sources?
___
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>You can limit the process with cgroups In this case the process will be killed by OOM killer. Note that OOM killer exists by default. Limiting cgroup means the OOM killer will be invoked in the cgroup. With earlyoom you database server will get SIGTERM and maybe will gracefully shutdown. пт, 10 июл. 2020 г. в 00:10, John M. Harris Jr : > On Thursday, July 9, 2020 7:57:25 AM MST Reindl Harald (privat) wrote: > > Am 09.07.20 um 16:53 schrieb John M. Harris Jr: > > > On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > > >> +1 This would be a genuine improvement for end users! > > > > > > In what way do you believe this will be an improvement for end users? > By > > > killing their software, while it's legitimately using RAM, as expected? > > > How > > > exactly is that beneficial? If anything, this is actively working > against > > > the best interests of the end user. > > > > could you just shutup about topics you don't understand? > > I understand exactly what EarlyOOM does, which is precisely why I take > issue > with enabling this by default. > > > my co-developer had a recursion in his code and after a few seconds the > > machine was completly unresponsible due debugging the root cause > > That doesn't sound like anything to do with recursion, but either a memory > leak, or unchecked allocation. It may help to limit the amount of memory > that > specific program can use, in order to help debug the issue. > > > even power-key took *15 minutes* for a clean shutdown while he was > > tempted to hard power off the machine which is not much fun witch 32 GB > > RAM and all sort of database services > > Yeah, OOM situations are never fun. However, with all sorts of database > services, you wouldn't want something killing processes all willy nilly. > > > guess what was the solution: kill the fucking httpd worker before it > > kills the system > > You can limit the process with cgroups, so that only the software you > actually > intend to limit is affected, and the rest works as you'd expect. > > -- > John M. Harris, Jr. > Splentity > > ___ > 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: SwapOnZRAM and how it affects earlyoom thresholds
On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter wrote: > > part of some irc discussions on > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > raised my attention to related item, > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > As it stands currently with earlyoom, it's default thresholds are 4% ram and > 10% swap before it acts. That's fine and dandy. > > Upon reading the SwapOnZRAM feature proposal, I see it is advocating > allocating 50% of ram for swap. I'd like folks to consider and evaluate how > this impacts earlyoom. It effectively makes the earlyoom memory threshold > double (right?). If so, at least think about lowering 4 to (2 or 3), since > that will make earlyoom's behavior closer to before swaponzram was > introduced. > > Thoughts? The net effect is that earlyoom is more likely to trigger than with a disk based swap because right now disk based swap is huge by default. It's huge by default to accommodate a hibernation image. The most common value I've found over a long period of time, for swap without hibernation is 50% of RAM. So this approximates those expectations. I'd like to hear from Alexey what he thinks about further reducing the values in earlyoom versus possibly raising the cap in zram-generator-defaults. I don't want to get too carried away there, because we are applying this to upgrades (wherever the to-be-obsoleted 'zram' package exists already even if not enabled). There is an opportunity, of course, right now and through beta testing, to keep on testing variations on both the size of the zram device used for swap and for earlyoom. But we also have another Fedora release, Fedora 34. So I'm more inclined to go conservative so long as that itself isn't causing problems. One thing I'm a bit skeptical of with reducing earlyoom's triggers is that free memory is needed for the recovery from an actual kill. Usually this is just sigterm. That's the first attempt. If that doesn't work then earlyoom issues sigkill, which is at a lower threshold already. -- 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: out of Koji disk space
On Tue, 07 Jul 2020 21:11:31 +0200, Kevin Fenzi wrote: > I am not sure what to tell you here. Perhaps you could describe the > reason you are working on the chromium debuginfo? Is it broken? Missing? > Less useful that normal? Missing. Completely. And it is not just about enabling it (=remove its disable) because with default Fedora building options (no -fdebug-types-section and using DWZ) the build will fail. That is because debuginfo will exceed 4GB which is the limit of DWARF32 format and GNU tools do not much support DWARF64. Enable debuginfo for x86_64 and aarch64. https://src.fedoraproject.org/rpms/chromium/pull-request/27 > All I see in this thread is that you were working on it and it increased > disk space usage, I must have missed the background/goal here? The goal is to have debuginfo for Chromium. Or why other Fedora packages have debuginfo but Chromium does not? Thanks, Jan ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>By killing their software, while it's legitimately using RAM, as expected? Memory usage causes system hang is not legitimately using RAM. Expected behavior is killing memory hog. чт, 9 июл. 2020 г. в 23:53, John M. Harris Jr : > On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > > +1 This would be a genuine improvement for end users! > > In what way do you believe this will be an improvement for end users? By > killing their software, while it's legitimately using RAM, as expected? > How > exactly is that beneficial? If anything, this is actively working against > the > best interests of the end user. > > -- > 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 > ___ 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: SwapOnZRAM and how it affects earlyoom thresholds
On Thu, Jul 9, 2020 at 11:50 AM Rex Dieter wrote: > > Upon reading the SwapOnZRAM feature proposal, I see it is advocating > allocating 50% of ram for swap. I'd like folks to consider and evaluate how > this impacts earlyoom. It effectively makes the earlyoom memory threshold > double (right?). If so, at least think about lowering 4 to (2 or 3), since > that will make earlyoom's behavior closer to before swaponzram was > introduced. > No objections from me as KDE EarlyOOM change owner. My main concern is that if someone disables SwapOnZRAM, the effective default EarlyOOM threshold changes. I don't think there's any easy way to handle that, but it's an effect we should explicitly take into account. With my FPgM hat on, I would consider this to be a part of the Swap on ZRAM proposal, which has been approved by FESCo and so wouldn't require its own change proposal. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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 Self-Contained Change proposal: NSS dbm support removal
On Thu, Jul 9, 2020 at 10:50 AM Daiki Ueno wrote: > > Hello Igor, > > Sorry for the delay. > > Igor Raits writes: > > > On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote: > >> https://fedoraproject.org/wiki/Changes/NSSDBMRemoval > >> > >> == Summary == > >> Network Security Services (NSS) historically supports 2 different > >> database backends, based on SQLite and dbm. Since Fedora 28, the > >> SQLite backend has been used by default and the dbm backend has been > >> deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format > >> SQL]]). This Change is about removing the support for the dbm backend > >> entirely. > >> > >> == Owner == > >> * Name: [[User:ueno| Daiki Ueno]] > >> * Email: du...@redhat.com > >> > >> == Detailed Description == > >> Applications that use the NSS library often use a database for > >> storage > >> of keys, certificates and trust. NSS supports two different storage > >> formats, one is based on SQLite and another one is based on dbm > >> files. > >> > >> Today's default file format used by NSS, used when applications omit > >> the type parameter, is the SQLite file format, and the older dbm > >> format has been considered as deprecated since Fedora 28, because it > >> has several drawbacks such as lack of support for parallel access to > >> the storage. > >> > >> As the default change was made 2 years ago, and NSS provides a > >> transparent migration mechanism from the dbm format to the SQLite > >> format, the suggestion is to completely disable the dbm backend. > >> > >> == Benefit to Fedora == > >> There are a few benefits: > >> * By disabling the dbm database, the size of the library binary will > >> be slightly smaller > >> * The NSS developers will be able to focus on the new file format > >> > >> == Scope == > >> * Proposal owners: > >> A build time environment variable (NSS_DISABLE_DBM) needs to be set. > >> > >> * Other developers: N/A > >> * Policies and guidelines: N/A (not a System Wide Change) > >> * Trademark approval: N/A (not needed for this Change) > >> > >> == Upgrade/compatibility impact == > >> The impact should be limited, as long as the users always update from > >> the previous version. That would ensure the existing databases on the > >> system are properly migrated. Therefore, we propose this as a Self > >> Contained Change, rather than a System Wide Change. > > > > Does it mean that people who upgrade from F31 to F33 will work just > > fine? > > That should, as long as the NSS databases had been created or accessed > with the default method (that is SQLite) on F31. On the other hand, if > a database is created explicitly as dbm, it needs to be converted before > upgrading to F33. > > If it is too worrisome, I'm willing to provide a script that checks if > the databases on the known locations are already converted. > I think it'd be worth doing this, and perhaps executing this as part of upgrading. -- 真実はいつも一つ！/ 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
SwapOnZRAM and how it affects earlyoom thresholds
part of some irc discussions on https://fedoraproject.org/wiki/Changes/KDEEarlyOOM raised my attention to related item, https://fedoraproject.org/wiki/Changes/SwapOnZRAM As it stands currently with earlyoom, it's default thresholds are 4% ram and 10% swap before it acts. That's fine and dandy. Upon reading the SwapOnZRAM feature proposal, I see it is advocating allocating 50% of ram for swap. I'd like folks to consider and evaluate how this impacts earlyoom. It effectively makes the earlyoom memory threshold double (right?). If so, at least think about lowering 4 to (2 or 3), since that will make earlyoom's behavior closer to before swaponzram was introduced. Thoughts? -- Rex ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, Jul 09, 2020 at 08:40:52AM -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 7:45:07 AM MST Igor Raits wrote: > > On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > > > Unless I'm mistaken, it should only be present if the user manually > > > installed > > > it, and opted into modularity, right? > > > > > > No, it should be installed by default. > > What was the point of breaking it out into a separate package, if it's still > going to be installed on end users' systems by default? The goal is to have continuity in behaviour and avoid surprises for users. Existing systems behave as before, new installations get the full set of packages available, but users who wish to may opt out. This is also what got approved by FESCo. > I can obviously see it > being removed on systems currently using modular repos as an issue, but I'm > not sure it makes sense to throw it on for systems not currently using it. It is being removed without taking into account if the user has any modular packages installed. But even if they don't, that's not what we want/agreed to do, see above. 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thursday, July 9, 2020 8:17:50 AM MST you wrote: > keep private mail private idiot You're responding to my post on a mailing list. I don't see any reason to keep this private. I'm not the only one on this list that you've attempted to contact directly with this sort of comment either, and I believe it's important that others are aware. > Am 09.07.20 um 17:09 schrieb John M. Harris Jr: > > On Thursday, July 9, 2020 7:57:25 AM MST Reindl Harald (privat) wrote: > >> my co-developer had a recursion in his code and after a few seconds the > >> machine was completly unresponsible due debugging the root cause > > > > That doesn't sound like anything to do with recursion > > stop telling people what things sound like when they know the truth It's true that I don't know your code, was just a guess. > > but either a memory > > leak, or unchecked allocation. It may help to limit the amount of memory > > that specific program can use, in order to help debug the issue. > > endless recursion of program code allocates endless memory, it's that > easy and it does it pretty quick Endless recursion will normally cause a stack overflow fairly quickly, and it doesn't necessarily allocate a lot more memory. I don't know what language you're using, but the only way that'd actually be "infinite" would be if it were fork()ing or exec*()ing another process. See below for my suggestions on protecting that, if you're interested. > >> even power-key took *15 minutes* for a clean shutdown while he was > >> tempted to hard power off the machine which is not much fun witch 32 GB > >> RAM and all sort of database services > > > > Yeah, OOM situations are never fun. However, with all sorts of database > > services, you wouldn't want something killing processes all willy nilly. > > that's why database services have OOMScoreAdjust=-1000 kid - they are > not killed willy nilly That'd be the case only if they're running as systemd units, not if they're spawned as a user process. For example, MySQL is spawned by Akonadi as the backend of KMail (and other KDE software). This wouldn't have an oom_score_adj set. > >> guess what was the solution: kill the fucking httpd worker before it > >> kills the system > > > > You can limit the process with cgroups, so that only the software you > > actually intend to limit is affected, and the rest works as you'd expect > > jesus christ you don't know *before* it happens what drives crazy and > putting arbitary limits everywhere does more harm If you're working on something that may "run out of control", you can apply cgroups yourself, to that process tree. You can always remove the limits when you're done working on it. The exact argument you've made against arbitrary limits is my argument against EarlyOOM. I hope that helps you understand where I'm coming from. -- John M. Harris, Jr. Splentity ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thursday, July 9, 2020 7:45:07 AM MST Igor Raits wrote: > On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > > Unless I'm mistaken, it should only be present if the user manually > > installed > > it, and opted into modularity, right? > > > No, it should be installed by default. What was the point of breaking it out into a separate package, if it's still going to be installed on end users' systems by default? I can obviously see it being removed on systems currently using modular repos as an issue, but I'm not sure it makes sense to throw it on for systems not currently using it. -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/8/20 11:15 PM, John M. Harris Jr wrote: >> * disk access is literally O(1) slower than RAM access > This is just false, and you can prove that on your own system using only > `dd`. > In fact, if your system is newer than my Lenovo ThinkPad X200 Tablet, you'll > probably have even faster reads/writes from/to disk. > Can you explain how you do this? How do you ensure dd is not using some cache? And how do you measure ram i/o with dd? As far as I understand dd is not a memory benchmarking tool, not even parallised to fully saturate the memory throughput. Just copying to/from ramdisk with dd gave me speeds of below 2 GB/s, but a streaming test [1] gives me 15 GB/s for copy using a single thread and 18 GB/s if I use both cores. Using dd to copy some file, calling time sync before and after, and adding the time after to the estimate by dd gives me an estimate of 30 MB/s for disk speed. So the ratio is only ~1000 but I am not sure how to do it with just dd ... But back to the point - 1000 is still way to slow and I love earlyOOM. I wrote a script myself before I learned about earlyOOM, and I think it is great to have earlyOOM enabled by default. [1] https://www.cs.virginia.edu/stream/FTP/Code/Versions/stream_mpi.c ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thursday, July 9, 2020 7:57:25 AM MST Reindl Harald (privat) wrote: > Am 09.07.20 um 16:53 schrieb John M. Harris Jr: > > On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > >> +1 This would be a genuine improvement for end users! > > > > In what way do you believe this will be an improvement for end users? By > > killing their software, while it's legitimately using RAM, as expected? > > How > > exactly is that beneficial? If anything, this is actively working against > > the best interests of the end user. > > could you just shutup about topics you don't understand? I understand exactly what EarlyOOM does, which is precisely why I take issue with enabling this by default. > my co-developer had a recursion in his code and after a few seconds the > machine was completly unresponsible due debugging the root cause That doesn't sound like anything to do with recursion, but either a memory leak, or unchecked allocation. It may help to limit the amount of memory that specific program can use, in order to help debug the issue. > even power-key took *15 minutes* for a clean shutdown while he was > tempted to hard power off the machine which is not much fun witch 32 GB > RAM and all sort of database services Yeah, OOM situations are never fun. However, with all sorts of database services, you wouldn't want something killing processes all willy nilly. > guess what was the solution: kill the fucking httpd worker before it > kills the system You can limit the process with cgroups, so that only the software you actually intend to limit is affected, and the rest works as you'd expect. -- John M. Harris, Jr. Splentity ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thu, Jul 9, 2020 at 7:51 am, John M. Harris Jr wrote: There's absolutely no justification for this, as I see it. You're willfully ignoring what everybody else is telling you: we don't want out-of-control applications to bring down the desktop. GNOME doesn't want it, and KDE doesn't want it either. Is it so hard to believe...? ___ 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: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 07:46 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote: > > On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr < > > joh...@splentity.com> > > wrote: > > > This is not something that's beneficial here, it's only > > > harming our users. > > > > That seems exceedingly myopic to me. I'm guessing you've not been > > following the last few years of security research, where attacking > > the > > firmware is now the best way to own a machine. And please don't > > lecture me on why BIOS is more secure than UEFI, "compatibility" > > mode > > is implemented *on top of* the UEFI bios these days, rather than as > > a > > completely different software stack. > > "Attacking" the firmware has always been the best option, even with > BIOS boot > systems. For example, coreboot is technically a hostile payload, to > the OEM. > That doesn't mean that it makes any sense to prevent the end user > from > actually owning the hardware they've purchased, and doing with it > what they > please. Yes, that's why "secure boot" should only be an option and the user must have the option to turn it off. Otherwise, it wouldn't be possible to do any kernel development on that computer. > > > > If you've got root, you can STILL do almost anything to the > > > hardware, > > > including disabling various "firmware protection technologies". > > > > I don't think you understand what enabling SecureBoot actually > > does. > > "Secure Boot" doesn't make root non-uid 0, and can't keep root from > controlling system devices, even uploading unsigned firmware to > peripherals. > At the point that anything but the end user gets root on a Fedora > install, all > of these "security gains" provided by creating needless headache for > those > running under "Secure Boot" are null and void. Yeah, for me, it's pretty weak as a mitigation effort, because it will usually only have some protective effect if someone already has root on your computer, and that's already pretty bad. You don't normally want to allow that to happen ever. And when someone has root, they can do pretty much anything. IMHO, it's a lot of effort and inconvenience for very little actual gain. But, that's why it should only be an option and not mandatory. But yes, it might make sense for certain use cases. Nikolay ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:25:36 AM MST Rex Dieter wrote: >> John M. Harris Jr wrote: >> >> >> > That's not what this discussion results from. This discussion results >> > from >> > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM >> > killing our applications at random, and ruining our desktop experience. >> >> >> This is full of inaccurate statements >> >> 1. The KDE SIG (at least some) was made aware of this feature and were >> ok >> with it. It wasn't someone outside deciding anything. > > What's the KDE SIG's rationale behind supporting this? This actively > limits the amount of RAM that end users are able to make use of. The more > RAM the end user has, the more RAM is not available for use, because > EarlyOOM will kill software long before it's able to be used. For example, > on my system, with 6 GiB of RAM, this will send SIGTERM while I still have > over half of a gigabyte of RAM, and SIGKILL while I still have over a > quarter of a gigabyte of RAM. There's absolutely no justification for > this, as I see it. > You're welcome to your opinion, so far I do not share it. One example: I've hit several times in the past where compiling something killed my box and made it unresponsive. I would have loved it for something to have bailed me out of those situations. I've been testing it on a laptop with only 4gb ram, and it's been working well for me so far. Though I honestly think I've not yet hit any thresholds , primarily only doing local package builds and web browsing. Also, you might want to double-check your math and the configuration values in account here, my default earlyoom config is set with -m 4 value, and your comment does not take into account swap (default is threshold of 10% free). -- Rex ___ 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 1855334] New: perl-Sereal-Encoder-4.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855334 Bug ID: 1855334 Summary: perl-Sereal-Encoder-4.016 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Sereal-Encoder Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 4.016 Current version/release in rawhide: 4.011-1.fc32 URL: http://search.cpan.org/dist/Sereal-Encoder/ 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/8065/ -- 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: PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-09 at 07:35 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote: > > I don't know where / which the fix should be: DNF, comps or both. > > Simply putting the fedora-repos-modular in comps won't help since > > DNF > > is only using them when running `group install/update/remove`. > > What's to fix? Sounds like a feature, not a bug. It's well reasoned > above, > nothing depends on it. While it is behaving as it technically should, this is unexpected for the users. That's the only reason why I brought it here. > -- > 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- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HMmoACgkQEV1auJxc Hh6K0g//b+BUTmjacqKE2nktWTdJGjmvqhVOuCvKp65i/EQV9CMtGidex3mEZnMN M/BT1eT8ZhLAh+4X1CVYxLzmknpOSKBbeK48kjBLzSXFvLRifgw7GXwnTkwp7TG7 jBlXI+k+qQZYx/Bsm09tgMNfiljHf0nsg7VpMkI4oVxmECx143LpNbZii8RI3dFc 0LX8vJ4KcEuE4Md3pORCOMGL6SDYrdBr/H0b9X2isY/JlsMWvIqMI1dZyodz5jMZ 2wCcscU7khpRNxmDI3xgnUgq9FwJnfKDciXG6EhUXTxA86kn1G7GvLaOw5zdZdDG 9mNjVaDLyL9Ik7fmbzY60/0mAYA4QK4L9s3yt/dVKDNP8LCCJR/ny+zMApimQ1jH Irgy4/XNJYWyhCARqGjoXGOLlguW3vjaTfA7+xZzvm1Hjk9D8fgAkvFQWwpzeFIm /Xj+nL4L35Zz5uOxYznUg/nmASV1jK+kvgGkf+RsGTx+MtYyURRekngNjVfT8BCb 3DRSmaE9EN9EH4A5ZBZNVATnhMGso6QB+B/HP5NUGBGKUlRtZ+uvGCV4c4omVZBE t5ep9yczF+uS5p+3YwzxT33AyVRnGYW2/uxuyXNEYz+yTCOAqCSk67/IpQe2wYfL 0oX7gu/1iNyZMYqdnnc+Crz7DbNKbmt/APbp2kP0Q5f4a7EYWCo= =j6pN -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
[Bug 1855332] New: perl-Sereal-4.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855332 Bug ID: 1855332 Summary: perl-Sereal-4.016 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Sereal Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 4.016 Current version/release in rawhide: 4.011-1.fc32 URL: http://search.cpan.org/dist/Sereal/ 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/7605/ -- 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 1855333] New: perl-Sereal-Decoder-4.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855333 Bug ID: 1855333 Summary: perl-Sereal-Decoder-4.016 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Sereal-Decoder Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 4.016 Current version/release in rawhide: 4.011-1.fc32 URL: http://search.cpan.org/dist/Sereal-Decoder/ 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/8066/ -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > +1 This would be a genuine improvement for end users! In what way do you believe this will be an improvement for end users? By killing their software, while it's legitimately using RAM, as expected? How exactly is that beneficial? If anything, this is actively working against the best interests of the end user. -- 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: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 07:38 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote: > > On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote: > > > > > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > > > > > > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr < > > > > joh...@splentity.com> > > > > wrote: > > > > > > > > > needlessly disables a lot of kernel functionality > > > > > > > > > > > > It disables functionality which can destroy platform security. > > > > > > It disables functionality that users need, such as inserting > > > their kernel > > > > > > modules on their own system, or hibernating to disk. Let's be > > > honest about > > > what this does. This is not something that's beneficial here, > > > it's only > > > harming our users. > > > > Some users, not all users. Beware of making sweeping > > generalizations. > > > > I've used Fedora since Fedora Core 5 across countless machines and > > never > > cared about inserting custom kernel modules. Hibernating to disk is > > not > > something I've used on my laptops in probably 10 years either, as > > suspend > > to ram is generally sufficient. Again just my personal experiance. > > > > There's always a tradeoff and it is likely to be different > > depending on > > each users needs. While SecureBoot will disable some functionality > > it is > > not unreasonable to think it is a net win out of the box for a > > potentially > > quite large portion of Fedora's userbase. > > > > Regards, > > Daniel > > Please keep in mind that it disables that functionality only because > of > 'lockdown' patches applied to the Fedora kernel, it's not a normal > part of the > Linux kernel when running under Secure Boot. I have no idea why the > decision > to hurt users was explicitly made here, it doesn't make a lot of > sense. IIRC, if you sign a kernel that can load unsigned modules, you can boot that kernel, then load a custom module, that boots a different kernel or OS (such as Windows) and claim that secure boot was on, even though you have modified and/or injected malicious code into the kernel. In other words, you can circumvent the whole point of using secure boot. If you want that, you might as well just disable secure boot. Otherwise it is a bit like locking your front door, while leaving your back door widely open. You can argue all they long that secure boot doesn't bring you that much security anyway (I'm in that camp, I don't think it's worth the trouble for my home systems, so I disable them even on those that use UEFI), but then, again, as long as it's not mandatory, so the user can choose to turn it off, it should be ok. Some people might decide to make an informed decision to enable it, and that's their decision to make. It's a tradeoff - extra lockdown for some extra security. Maybe only worth it for very important systems. Nikolay ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thursday, July 9, 2020 5:25:36 AM MST Rex Dieter wrote: > John M. Harris Jr wrote: > > > > That's not what this discussion results from. This discussion results > > from > > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing > > our applications at random, and ruining our desktop experience. > > > This is full of inaccurate statements > > 1. The KDE SIG (at least some) was made aware of this feature and were ok > with it. It wasn't someone outside deciding anything. What's the KDE SIG's rationale behind supporting this? This actively limits the amount of RAM that end users are able to make use of. The more RAM the end user has, the more RAM is not available for use, because EarlyOOM will kill software long before it's able to be used. For example, on my system, with 6 GiB of RAM, this will send SIGTERM while I still have over half of a gigabyte of RAM, and SIGKILL while I still have over a quarter of a gigabyte of RAM. There's absolutely no justification for this, as I see it. > 2. It's clear you don't like this feature, but characterizing it as random > and ruining things is going a bit far (to put it mildly). Not at all, see the above example. Most users have more RAM than I do, not less, and even then, it's hurting the UX. -- 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 Self-Contained Change proposal: NSS dbm support removal
Hello Igor, Sorry for the delay. Igor Raits writes: > On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/NSSDBMRemoval >> >> == Summary == >> Network Security Services (NSS) historically supports 2 different >> database backends, based on SQLite and dbm. Since Fedora 28, the >> SQLite backend has been used by default and the dbm backend has been >> deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format >> SQL]]). This Change is about removing the support for the dbm backend >> entirely. >> >> == Owner == >> * Name: [[User:ueno| Daiki Ueno]] >> * Email: du...@redhat.com >> >> == Detailed Description == >> Applications that use the NSS library often use a database for >> storage >> of keys, certificates and trust. NSS supports two different storage >> formats, one is based on SQLite and another one is based on dbm >> files. >> >> Today's default file format used by NSS, used when applications omit >> the type parameter, is the SQLite file format, and the older dbm >> format has been considered as deprecated since Fedora 28, because it >> has several drawbacks such as lack of support for parallel access to >> the storage. >> >> As the default change was made 2 years ago, and NSS provides a >> transparent migration mechanism from the dbm format to the SQLite >> format, the suggestion is to completely disable the dbm backend. >> >> == Benefit to Fedora == >> There are a few benefits: >> * By disabling the dbm database, the size of the library binary will >> be slightly smaller >> * The NSS developers will be able to focus on the new file format >> >> == Scope == >> * Proposal owners: >> A build time environment variable (NSS_DISABLE_DBM) needs to be set. >> >> * Other developers: N/A >> * Policies and guidelines: N/A (not a System Wide Change) >> * Trademark approval: N/A (not needed for this Change) >> >> == Upgrade/compatibility impact == >> The impact should be limited, as long as the users always update from >> the previous version. That would ensure the existing databases on the >> system are properly migrated. Therefore, we propose this as a Self >> Contained Change, rather than a System Wide Change. > > Does it mean that people who upgrade from F31 to F33 will work just > fine? That should, as long as the NSS databases had been created or accessed with the default method (that is SQLite) on F31. On the other hand, if a database is created explicitly as dbm, it needs to be converted before upgrading to F33. If it is too worrisome, I'm willing to provide a script that checks if the databases on the known locations are already converted. Regards, -- Daiki Ueno ___ 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: Including local repos in a mock build
On Thursday, July 9, 2020 2:17:06 PM CEST Sam Varshavchik wrote:
> Is there a better way to include local repos in mock builds than doing
> something like this in my /etc/mock/default.cfg:
>
> include('fedora-32-x86_64.cfg')
>
> config_opts['dnf.conf'] = config_opts['dnf.conf'] + """
>
> [my]
> name=My repository
> baseurl=http://jack/repos/$releasever/$basearch
> enabled=1
> gpgcheck=0
> metadata_expire=60
>
> """
The default.cfg is ought to be just a symlink to the config which represents
the system you are running mock on. E.g. `fedora-32-x86_64` on Feodra 32 x86_64
host.
Otherwise I think your approach is fairly "optimal". I'd though encourage
you to also change the `root` config option -- to not mix-up various kinds
of mock caches for the default f32 and customized f32 configs:
$ cat my_enhanced_mock.cfg
include('fedora-32-x86_64.cfg')
config_opts['root'] = "my-fedora-32-x86_64"
config_opts['dnf.conf'] = config_opts['dnf.conf'] + """
[my]
name=My repository
baseurl=http://jack/repos/$releasever/$basearch
enabled=1
gpgcheck=0
metadata_expire=60
"""
The default set of repositories should basically match the default
/etc/yum.repos.d content.
> I might be misremembering something, but I'm pretty sure that at some
> point in the past mock would read /etc/yum/repos.d, and grab stuff from
> my local repos without doing anything like that.
I don't think that was ever the case. Mock tries to mimic the default
distro buildsystem behavior (the same minimal buildroot, set of packages
available in repos, etc.), and including custom repos from /etc/yum.repos.d
would certainly break the packager's assumptions. Also, that repos would only
be useful for the `default.cfg`, nothing else.
Pavel
___
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: The future of legacy BIOS support in Fedora.
On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote: > On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr > wrote: > > This is not something that's beneficial here, it's only > > harming our users. > > > That seems exceedingly myopic to me. I'm guessing you've not been > following the last few years of security research, where attacking the > firmware is now the best way to own a machine. And please don't > lecture me on why BIOS is more secure than UEFI, "compatibility" mode > is implemented *on top of* the UEFI bios these days, rather than as a > completely different software stack. "Attacking" the firmware has always been the best option, even with BIOS boot systems. For example, coreboot is technically a hostile payload, to the OEM. That doesn't mean that it makes any sense to prevent the end user from actually owning the hardware they've purchased, and doing with it what they please. > > If you've got root, you can STILL do almost anything to the hardware, > > including disabling various "firmware protection technologies". > > > I don't think you understand what enabling SecureBoot actually does. "Secure Boot" doesn't make root non-uid 0, and can't keep root from controlling system devices, even uploading unsigned firmware to peripherals. At the point that anything but the end user gets root on a Fedora install, all of these "security gains" provided by creating needless headache for those running under "Secure Boot" are null and void. -- 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: PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" > > action on > > a system upgrade, because we want that package to be prensented on > > the > > system. However I worry that DNF does not possess a capability for > > doing > > it. (Except of injecting that command into some externally executed > > script.) > > Unless I'm mistaken, it should only be present if the user manually > installed > it, and opted into modularity, right? No, it should be installed by default. > -- > 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- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HLXMACgkQEV1auJxc Hh5HOA/7Bf+x4zEaow3IVuBEbDgg97oe76kivIOyHnCySWp8xPVCgHPAo4NnBem1 534aECZMKZO6zRfSVPjkvxiImUy51TKkMy//OOUl8YJrb/wD6fuUEr3BrMkvDbdC ztIswL7wnnPLAQIE36JbmzvOLcyfZUp867rgbB7nDCwZ+3GAX1u4q8UZXCn/4FZl z624gtab1VGqddvN38nih+nGPMTOXLGEafhGaz5Y9tuFcZKA1nfSPn8HDNNieNNK 3lii2e9WHFgWJc7pbahDGbJGRC1YK8wDLDtfcr7FG9VBtkyWsErjI1VEhd5YUCld ex8aFRvA5SnxuvZriyDWr+DTITQXmGEPYxbXSpCM7Tufl42ZYccWr1EV0w5bWjf3 jKkM/zzb2P8CGomA6XWNkO43fVwjG6LTHpsq1h4q8EomXUfRNh4UfMYtOC5U3Nj1 5sHaMJJzzPHtzpBLEeYX2ns323bEr59Nc3qsbmfI7hiyBZffXYC1/LkJIaMxW7Dy Fufswm13S06330VGt1QEaa379opyUkLcFMs8SdGjGY5RCTA2CEyEL0VbZuwSC+ql B7bK0MvzuPtZpZ6CRgJnd0gMlMo29NQ9GOetYzLgHk52TkvTpj35vPtcv4/klRVI lKxwyizOi2aAWB+tMq3LTfs3N48/XTygMIZcavOp2p6b/EJc//o= =oXCM -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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, Jul 9, 2020, at 10:36 AM, John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on > > a system upgrade, because we want that package to be prensented on the > > system. However I worry that DNF does not possess a capability for doing > > it. (Except of injecting that command into some externally executed > > script.) > > Unless I'm mistaken, it should only be present if the user manually installed > it, and opted into modularity, right? > The agreement by FESCo was to have it as an optional component, but installed by default, IIUC. It should be added to the relevant comps groups, but I think 'yum upgrade' needs to also learn about upgrading groups. (Side note, this is another example of where the 'yumdb' command would come in handy if there were a dnf equivalent; I wouldn't have been able to do those sqlite queries myself.) V/r, James Cassell ___ 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: The future of legacy BIOS support in Fedora.
On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote: > On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote: > > > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > > > > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr > > > wrote: > > > > > > > needlessly disables a lot of kernel functionality > > > > > > > > > > > > It disables functionality which can destroy platform security. > > > > > > It disables functionality that users need, such as inserting their kernel > > > > modules on their own system, or hibernating to disk. Let's be honest about > > what this does. This is not something that's beneficial here, it's only > > harming our users. > > > Some users, not all users. Beware of making sweeping generalizations. > > I've used Fedora since Fedora Core 5 across countless machines and never > cared about inserting custom kernel modules. Hibernating to disk is not > something I've used on my laptops in probably 10 years either, as suspend > to ram is generally sufficient. Again just my personal experiance. > > There's always a tradeoff and it is likely to be different depending on > each users needs. While SecureBoot will disable some functionality it is > not unreasonable to think it is a net win out of the box for a potentially > quite large portion of Fedora's userbase. > > Regards, > Daniel Please keep in mind that it disables that functionality only because of 'lockdown' patches applied to the Fedora kernel, it's not a normal part of the Linux kernel when running under Secure Boot. I have no idea why the decision to hurt users was explicitly made here, it doesn't make a lot of sense. -- 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on > a system upgrade, because we want that package to be prensented on the > system. However I worry that DNF does not possess a capability for doing > it. (Except of injecting that command into some externally executed > script.) Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right? -- 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote: > I don't know where / which the fix should be: DNF, comps or both. > Simply putting the fedora-repos-modular in comps won't help since DNF > is only using them when running `group install/update/remove`. What's to fix? Sounds like a feature, not a bug. It's well reasoned above, nothing depends on it. -- 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
El mar., 30 jun. 2020 a las 10:26, Ben Cotton ()
escribió:
> https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
>
> == Summary ==
> As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install
> earlyoom package, and enable it by default. If both RAM and swap go below
> 10% free, earlyoom issues SIGTERM to the process with the largest
> oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL
> to the process with the largest oom_score. The idea is to recover from out
> of memory situations sooner, rather than the typical complete system hang
> in which the user has no other choice but to force power off.
>
> == Owner ==
> * Name: [[User:bcotton|Ben Cotton]]
> * Email: bcot...@redhat.com
>
> == Detailed Description ==
> Shamelessly copied from Workstation, which did it in the last release:
>
> Certain workloads have heavy memory demands, quickly consume all of RAM,
> and start to heavily page out to swap. (Heavy paging, is often called "swap
> thrashing" for added descriptive effect, probably because it's noticeable
> and annoying). Incidental swap usage is a good thing, it frees up memory
> for active pages used by a process. Heavy swap usage quickly leads to a
> very negative UX, because it's slow, even on modern SSDs. Due to installer
> defaults, the swap partition is made the same size as available memory (at
> install time), which can be huge. This just extends swap thrashing time.
>
> On the one hand, we want this resource hungry job to complete. On the
> other hand, we want our system to be responsive while that other work is
> going on. But once the GUI stutters or even comes to an apparent stand
> still (hang), we're really wishing the kernel oom-killer would kick in and
> free up memory, so we can start over (maybe using memory or thread limiting
> options - which arguably should be more intelligently figured out, and that
> too is a work in progress but beyond the scope of this feature).
>
> However, once in a heavy swap scenario, it's relatively common the system
> gets stuck in it, where GUI interactivity is terrible to non-existent, and
> also the kernel oom-killer doesn't trigger. From a certain point of view,
> this is working as intended. The kernel oom-killer is concerned about
> keeping the kernel running. It's not at all concerned about user space
> responsiveness.
>
> Instead of the system becoming completely unresponsive for tens of
> minutes, hours or days, this feature expects that an offending process
> (determined by oom_score, same as the kernel oom-killer) will be killed off
> within seconds or a few minutes.
>
> == Benefit to Fedora ==
>
> KDE users will be able to take advantage of the benefits Workstation users
> got from enabling earlyOOM in Fedora 32:
>
> * improved user experience by more quickly regaining control over one's
> system, rather than having to force power off in low-memory situations
> where there's aggressive swapping. Once a system becomes unresponsive, it's
> completely reasonable for the user to assume the system is lost, but that
> includes high potential for data loss.
> * reducing forced poweroff as the main work around will increase data
> collection, improving understanding of low memory situations and how to
> handle them better
> * earlyoom first sends SIGTERM to the chosen process, so it has a chance
> of a proper shutdown, unlike the kernel's oom-killer
>
> == Scope ==
> * Proposal owners:
> ** Modify {{code|
> https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in}} to
> include earlyoom package for in {{code|kde-desktop}} section.
> ** Add {{code|
> https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-kde.preset}}
> to include:
>
> # enable earlyoom by default on KDE
> enable earlyoom.service
>
>
> * Other developers: None, unless KDE-based Spins/Labs want to opt out
>
> * Release engineering: N/A
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
> earlyoom.service will be enabled on upgrade. An upgraded system should
> exhibit the same behaviors as a newly-installed system.
>
> == How To Test ==
> * Fedora 31/32 KDE users can test today:
> ** {{code|sudo dnf install earlyoom}}
> ** {{code|sudo systemctl enable --now earlyoom}}
>
> And then attempt to cause an out of memory situation. Examples:
> ** {{code|tail /dev/zero}}
> ** https://lkml.org/lkml/2019/8/4/15
>
> == User Experience ==
> earlyoom sends SIGTERM to processes based on oom_score when both memory
> and swap have less than 10% free and SIGKILL when below 5%.
>
> == Dependencies ==
> None
>
> == Contingency Plan ==
>
> * Contingency mechanism: (What to do? Who will do it?) Owner reverts
> changes
> * Contingency deadline: Final freeze
> * Blocks release? No
>
> == Documentation ==
> * {{code|man earlyoom}}
> * https://github.com/rfjakob/earlyoom
> * https://www.kernel.org/doc/gorman/html/understand/understand016.html
>
> == Release Notes ==
> The earlyoom service is now enabled by
Re: Bodhi 5.4.0 in production
On 22. 06. 20 9:53, Clement Verna wrote: One high level feature worth noting : * you can now associate BZ tickets to the automatically created rawhide updates. The bugs mentioned with the format "fix(es)|close(s) (fedora|epel|rh|rhbz)#BUG_ID" in the changelog will be associated to the update and automatically closed. More info https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates Finally I got to testing this. The bugzilla was added to the update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c1be13ded8 But it was not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1851519 Should I report this as a bug or am i doing something wrong? The commit is: https://src.fedoraproject.org/rpms/python-tox/c/d154cf5aabe445914123b41239243811eeac93b7?branch=master But the build was done from one clenaup commit above this. Is that relevant? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
Przemek Klosowski via devel wrote: > * disk access is literally O(1) slower than RAM access This notation is meaningless. By the definition of the O notation, O(1)=O(1)=O(k) for any constant k. 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: mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'
On Thu, 2020-07-09 at 00:07 +0200, Sandro Mani wrote:
> I'm working on updating the mingw toolchain [1], and am hitting the
> situation [2] where I build with -fstack-protector in the ldflags, can
> confirm that -lssp and -lssp_nonshared are automatically added to the
> ldflags (seen via gcc -v [3] and strace), but I still get i.e. with this
> minimal testcase:
>
> #include
> int main () {
> return closedir (NULL);
> }
>
> $ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector
> /usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld:
> /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib32_libmingwex_a-dirent.o):(.text+0x22f):
>
> undefined reference to `__strcpy_chk'
> collect2: error: ld returned 1 exit status
Perhaps mingw-crt should be built with -fno-stack-protector?
> OTOH, if I write
>
> $ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector
> /usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll
>
> it links correctly.
>
> The only other thing which came to mind to verify is that the import
> library references the correct dll, and this appears to be the case:
>
> $ i686-w64-mingw32-dlltool -I
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libssp.dll.a
> libssp-0.dll
>
> I'd appreciate any pointers as I'm pretty much in the dark here.
>
> [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-7.0.0/builds/
>
> [2] Specifically when building mingw-gdb, which adds
> -D_FORTIFY_SOURCES=2 internally, hence adding -fstack-protector to the
> ldflags
>
> [3] I.e. I gtt COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe'
> '-fstack-protector' '-mtune=generic' '-march=pentiumpro'
> /usr/libexec/gcc/i686-w64-mingw32/10.1.1/collect2 -plugin
> /usr/libexec/gcc/i686-w64-mingw32/10.1.1/liblto_plugin.so
> -plugin-opt=/usr/libexec/gcc/i686-w64-mingw32/10.1.1/lto-wrapper
> -plugin-opt=-fresolution=/tmp/cckKHr8u.res
> -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname
> -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
> -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
> -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
> -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
> -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
> -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
> -plugin-opt=-pass-through=-lmsvcrt
> --sysroot=/usr/i686-w64-mingw32/sys-root -m i386pe -Bdynamic -o test.exe
> /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o
> /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtbegin.o
> -L/usr/lib/gcc/i686-w64-mingw32/10.1.1
> -L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib/../lib
>
> -L/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib
> -L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib
> -L/usr/i686-w64-mingw32/sys-root/mingw/lib /tmp/ccpeowDx.o
> /usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll -lssp_nonshared
> -lssp -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread
> -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh
> -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtend.o
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
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: Using "rawhide" for the dist-git branch for Fedora Rawhide
On Tue, Jul 07, 2020 at 09:44:47PM +0200, Markus Larsson wrote: > > > On 7 July 2020 21:20:22 CEST, Matthew Miller wrote: > >On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote: > >> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git > >> branch for Fedora Rawhide "rawhide" to clarify the purpose of that > >> branch. There was also some feedback that Rawhide might not be the best > >> name and it could be renamed. In that case, the branch could be named as > >> this. This is just the first step to check if there is enough support > >> for this to move forward. The next step would be to start a change > >> process. > > > >I'm in favor of this. "Master" is not a good, functional description of the > >Rawhide branch. It was just taking the default. Plus, as we're investigating > >a new git system _and_ looking at packaging workflow improvements all around > >anyway, that seems like the time. +1 > >I don't have any strong opinion on the "Rawhide" name, although it has > >always seemed strange to me, because of course fedoras are made of felt, not > >rawhide. And I guess the same "hey, while we're changing things" sentiment > >applies here. > > > > I thought Rawhide was a reference to the wild west via the tv-show by that > name, isn't that the case? > As for naming, I have no emotional connection to the name rawhide and doesn't > see any problems with changing it. I would suggest that if it changes maybe > not Felt or Wool but something more descriptive like Edge, Next or Volatile. Yeah, that's how I understood the reference. Right now I don't see a particularly strong reason to change the name, so I'm mildly negative. But if enough people find the name offensive, I'll reconsider. 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
John M. Harris Jr wrote: > That's not what this discussion results from. This discussion results from > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing > our applications at random, and ruining our desktop experience. This is full of inaccurate statements 1. The KDE SIG (at least some) was made aware of this feature and were ok with it. It wasn't someone outside deciding anything. 2. It's clear you don't like this feature, but characterizing it as random and ruining things is going a bit far (to put it mildly). -- Rex ___ 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: Using "rawhide" for the dist-git branch for Fedora Rawhide
On Wed, Jul 08, 2020 at 11:31:20AM -0400, Matthew Miller wrote: > On Wed, Jul 08, 2020 at 03:48:23PM +0200, Till Maas wrote: > > Just had another idea, how about instead of branch down from the rawhide > > branch to new branched to make Rawhide always use the fxy version that > > it develops. So instead of creating branched f33 later we would rename > > master to f33 now and then once we need to branch we branch of Rawhide > > as f34? There could still be a symbolic ref called rawhide for the > > latest rawhide for convenience. What do you think? > > I do like this, because it reflects the actual process. However, it does ask > something of our git forge web front end: what would it show by default? I don't see much benefit from this. First, I disagree that it reflects the process better. In almost all cases I know development is done in the master branch, and changes from there are often either fast-forwarded or cherry-picked into the other branches. Second, I don't see what improvement this would bring. If we were to change the branching pattern, that we have been successfully using for years and that people are accustomed to, there should be some clear reason. A change of the branching pattern is not helpful to this change, because we would still need *some* constant name for the master/rawhide/latest branch, so the new renamed name will still be visible to users and used for various purposes. And mixing the two makes the (already complicated) process of renaming more likely to fail. 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote: > One just noticed that `dnf autoremove` is trying to remove `fedora- > repos-modular` and `fedora-repos-rawhide-modular`. > [...] > I don't know where / which the fix should be: DNF, comps or both. > Simply putting the fedora-repos-modular in comps won't help since DNF > is only using them when running `group install/update/remove`. > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.) -- Petr signature.asc Description: 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
Including local repos in a mock build
Is there a better way to include local repos in mock builds than doing
something like this in my /etc/mock/default.cfg:
include('fedora-32-x86_64.cfg')
config_opts['dnf.conf'] = config_opts['dnf.conf'] + """
[my]
name=My repository
baseurl=http://jack/repos/$releasever/$basearch
enabled=1
gpgcheck=0
metadata_expire=60
"""
I might be misremembering something, but I'm pretty sure that at some point
in the past mock would read /etc/yum/repos.d, and grab stuff from my local
repos without doing anything like that.
pgpINhtBkRQAI.pgp
Description: 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: Suppress "running pip install with root privileges" warning in RPM macros?
On 2020-07-07 19:54, Miro Hrončok wrote: 1) Add a custom --no-warn-root-privileges option 2) Hide the warning when $RPM_BUILD_ROOT is set. 3) Introduce an environment variable (e.g. PIP_NOWARN_ROOT) 4) Introduce our warning upstream, but make it opt-in only. 5) Hide the warning when --root is set. What do you think? I like option 5 as well. It's just a warning, not an error, because there are cases where you "know what you're doing", such as containers/VMs, where "sudo pip" may be appropriate. All uses of --root that come to my mind are such cases. Users who follow tutorials without "knowing what they're doing" are very unlikely to use --root. ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
One just noticed that `dnf autoremove` is trying to remove `fedora-
repos-modular` and `fedora-repos-rawhide-modular`.
tl;dr. fedora-repos-modular inherit installation reason from fedora-
repos (DEPENDENCY) and nothing depends on fedora-repos-modular so it is
not needed anymore (from the solver POV).
The fedora-repos is being pulled in by fedora-release-common (that is
brought by fedora-release-workstation or others). fedora-repos is not
part of the @core group in comps so its reason recorded in DNF DB is 1.
enum class TransactionItemReason : int {
UNKNOWN = 0,
DEPENDENCY = 1,
USER = 2,
CLEAN = 3, // hawkey compatibility
WEAK_DEPENDENCY = 4,
GROUP = 5
};
On my laptop:
❯ sqlite3 /var/lib/dnf/history.sqlite
sqlite> select trans_id,name,epoch,version,release,reason from
trans_item join rpm on rpm.item_id=trans_item.item_id where name like
'fedora-release%' or name like 'fedora-repos%';
1|fedora-release-common|0|33|0.8|1
1|fedora-release-identity-workstation|0|33|0.8|1
1|fedora-release-workstation|0|33|0.8|5
1|fedora-repos|0|33|0.6|1
1|fedora-repos-rawhide|0|33|0.6|1
21|fedora-release-common|0|33|0.9|1
21|fedora-release-common|0|33|0.8|1
21|fedora-release-identity-workstation|0|33|0.9|1
21|fedora-release-identity-workstation|0|33|0.8|1
21|fedora-release-workstation|0|33|0.9|5
21|fedora-release-workstation|0|33|0.8|5
143|fedora-repos-modular|0|33|0.8|1
143|fedora-repos-rawhide-modular|0|33|0.8|1
143|fedora-repos|0|33|0.8|1
143|fedora-repos|0|33|0.6|1
143|fedora-repos-rawhide|0|33|0.8|1
143|fedora-repos-rawhide|0|33|0.6|1
The packages that have been brought by the obsoletes inherit reason
(DEPENDENCY in this case) and since nothing depends on those they are
automatically cleaned up on the autoremove.
I don't know where / which the fix should be: DNF, comps or both.
Simply putting the fedora-repos-modular in comps won't help since DNF
is only using them when running `group install/update/remove`.
So sending this email just in case somebody will see this interesting
behavior.
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8G97AACgkQEV1auJxc
Hh6SkBAAo4iTvTmSImNbSRAZe6VzKfUJ1gBPjgMITEueM7pxa8zlZ7g2bOpl1UiI
TD+DKI953Qk2gZcN+WBvkQO13Cef/FD/lp6nGXvyo87mOs2ThSc+a6UgufEBceVY
Z5kGCoCQnfA6JkBtRtFdMbsCvVKtSRSOFJXlW7DCybLGKizUlFPqHdug0qxGpoO2
XWldoX0Bw0F11Pr2FqujZXlcfXe5G51lkfPFnChc0a4O0+d0/AsWZJ0dM0l1ff6l
GT43t+boiw9Dwp8KEBZTh7uTWQAeLAo9UxGIs2T2oZikHNwSSo13N6nwcS6x2XYd
AaHVET5dn4tITH9WjiknS9IHy06D5MZ8pWBRs46aav52Ro6GxNYeALYdhjaM2heG
mMGkjAWkXJ0qtaRR9qi68CfQiDfQjzYe0JXEHJTrLV+Pv42OrJJJoq7NWGOJbqV0
T9DYJoO63W74q/rttMNVMIBG8GtzbTBqoxuP9ooykpAzRv2LPn1Jc1L3eEBXSO0w
QW0SH5i6v6OgajCrc813TytboOua9zDZ55ENP0dJNXjqAiznZJjqrYG3RWUJH4cA
qx6xygK3OvZHm9vuL4VnXCp4wW/TDGf8MNGF0hoF75IbRN1+nrAAtGorx9BdV2g+
SvTV1Cs9CPyOKy0Q2brILtBZq6em6JNzkFAMg5h9xoce4brbyA8=
=UXSc
-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
