Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Saturday, July 18, 2020 6:33:11 PM MST Brandon Nielsen wrote: > What about the case of the developer whose code accidentally does > something that blows through all available memory, leading to swap > thrashing. I've been there. The system is very much unusable, to the > point where a user without the knowledge of the magic sysrq key will > almost certainly be reaching for the power button. Well, sysrq is disabled by default in Fedora anyway. I get what you mean, however, as I also re-enable it. > Or when a compile takes more memory than you expect, leading to the > same? Again, I've been there. The system is absolutely unusable for any > regular user use-case I can think of. This is another example that came up, and cgroups can help with that as well. > Decompression "bomb" (malicious or otherwise) on a memory taxed system? > Again, definitely unusable. > > Web browsers are definitely not the only way thrashing can be > encountered. While I agree resource limits via cgroups or other method > are needed, an EarlyOOM emergency brake is definitely welcome as well. > The kernel OOM killer is certainly not adequate for an interactive user > session in my experience. Killing users' programs needlessly is not welcome, at least not by me, and I'd certainly hope others wouldn't stand for it either. The correct solution is to prevent the few programs that this is an issue with from eating all of our RAM, not killing everything but those. The kernel OOM killer does its job, and it does it well. The goal is to ensure the kernel can keep doing its job, it's not going to try to figure out what you intend for userspace, as well it shouldn't. -- 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
[389-devel] 389 DS nightly 2020-07-19 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/19/report-389-ds-base-1.4.4.4-20200718git654d0ff.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
[Bug 1853570] Upgrade perl-Image-ExifTool to 12.00
https://bugzilla.redhat.com/show_bug.cgi?id=1853570 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Image-ExifTool-12.00-1 |perl-Image-ExifTool-12.00-1 |.fc32 |.fc32 ||perl-Image-ExifTool-12.00-1 ||.fc31 --- Comment #9 from Fedora Update System --- FEDORA-2020-0a45a95c41 has been pushed to the Fedora 31 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-13c6cbc484 python-gnupg-0.4.6-1.el8 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f1d845c76 python-rsa-3.4.2-15.el8 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9239b6fa50 botan2-2.12.1-2.el8 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ff58160b15 libslirp-4.3.1-1.el8 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-672e6676c7 seamonkey-2.53.3-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-12d0e14fab cacti-1.2.13-1.el8 cacti-spine-1.2.13-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1c906e59bb mbedtls-2.16.7-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-442e619b4a singularity-3.6.0-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-31b5963358 tor-0.4.3.6-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a0f28fffcf bashtop-0.9.24-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-cf34e230c7 clamav-0.102.4-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing mono-6.8.0-3.el8 ncl-6.6.2-12.el8 Details about builds: mono-6.8.0-3.el8 (FEDORA-EPEL-2020-09dffd1659) Cross-platform, Open Source, .NET development framework Update Information: Upgrade Mono from 6.6 to 6.8 ChangeLog: * Sat Jul 18 2020 Timotheus Pokorra - 6.8.0-3 - Non-Bootstrap build of Mono 6.8 for Epel 8 * Fri Jul 17 2020 Timotheus Pokorra - 6.8.0-2 - Bootstrap build for Mono 6.8 for Epel 8 * Thu Jul 16 2020 Timotheus Pokorra - 6.6.0-9 - Upgrade to Mono 6.6.0.166 References: [ 1 ] Bug #1858448 - Upgrade Mono from 6.6 to 6.8 in Epel8 https://bugzilla.redhat.com/show_bug.cgi?id=1858448 ncl-6.6.2-12.el8 (FEDORA-EPEL-2020-b7ff36d3e7) NCAR Command Language and NCAR Graphics Update Information: Fix segfault reading grib files ChangeLog: * Sat Jul 18 2020 Orion Poplawski - 6.6.2-12 - Change link order to fix issue with gdal and g2clib (bz#1856959) * Thu Jun 25 2020 Orion Poplawski - 6.6.2-11 - Rebuild for hdf5 1.10.6 References: [ 1 ] Bug #1856959 - NCL error while trying to read GRIB2 files https://bugzilla.redhat.com/show_bug.cgi?id=1856959 ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/18/20 5:09 PM, John M. Harris Jr wrote: On Saturday, July 18, 2020 3:25:35 AM MST Benjamin Berg wrote: But thrashing scenarios are exactly that, *technically* running but *practically* dead. Thrashing doesn't mean the system is unusable, or anything of the sort. It's only an issue if you're thrashing for too long. I think it only makes sense to continue a discussion if you acknowledge the existence and really understand the scenario described here: https://lkml.org/lkml/2019/8/4/15 I've linked to that very thread several times in this thread. The bug here is in the web browsers that cause that behavior. The solution is to either fix the web browsers or limit the amount of memory they can run away with. What about the case of the developer whose code accidentally does something that blows through all available memory, leading to swap thrashing. I've been there. The system is very much unusable, to the point where a user without the knowledge of the magic sysrq key will almost certainly be reaching for the power button. Or when a compile takes more memory than you expect, leading to the same? Again, I've been there. The system is absolutely unusable for any regular user use-case I can think of. Decompression "bomb" (malicious or otherwise) on a memory taxed system? Again, definitely unusable. Web browsers are definitely not the only way thrashing can be encountered. While I agree resource limits via cgroups or other method are needed, an EarlyOOM emergency brake is definitely welcome as well. The kernel OOM killer is certainly not adequate for an interactive user session in my experience. ___ 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: 20200718.n.1 changes
OLD: Fedora-Rawhide-20200717.n.0 NEW: Fedora-Rawhide-20200718.n.1 = SUMMARY = Added images:5 Dropped images: 0 Added packages: 4 Dropped packages:0 Upgraded packages: 168 Downgraded packages: 0 Size of added packages: 154.61 KiB Size of dropped packages:0 B Size of upgraded packages: 4.48 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -118.88 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200718.n.1.ppc64le.raw.xz Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200718.n.1.ppc64le.tar.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200718.n.1.ppc64le.qcow2 Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200718.n.1.ppc64le.tar.xz Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200718.n.1.ppc64le.vmdk = DROPPED IMAGES = = ADDED PACKAGES = Package: rust-block-buffer0.7-0.7.3-1.fc33 Summary: Fixed size buffer for block processing of data RPMs:rust-block-buffer0.7+default-devel rust-block-buffer0.7-devel Size:22.30 KiB Package: rust-block-cipher-0.7.1-1.fc33 Summary: Traits for description of block ciphers RPMs:rust-block-cipher+blobby-devel rust-block-cipher+default-devel rust-block-cipher+dev-devel rust-block-cipher+std-devel rust-block-cipher-devel Size:46.17 KiB Package: rust-digest0.8-0.8.1-1.fc33 Summary: Traits for cryptographic hash functions RPMs:rust-digest0.8+blobby-devel rust-digest0.8+default-devel rust-digest0.8+dev-devel rust-digest0.8+std-devel rust-digest0.8-devel Size:45.79 KiB Package: rust-generic-array0.12-0.12.3-1.fc33 Summary: Generic types implementing functionality of arrays RPMs:rust-generic-array0.12+default-devel rust-generic-array0.12+serde-devel rust-generic-array0.12-devel Size:40.34 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: akonadi-calendar-tools-20.04.3-1.fc33 Old package: akonadi-calendar-tools-20.04.2-1.fc33 Summary: Akonadi Calendar Tools RPMs: akonadi-calendar-tools Size: 1.22 MiB Size change: -909 B Changelog: * Fri Jul 10 2020 Rex Dieter - 20.04.3-1 - 20.04.3 Package: akonadi-import-wizard-20.04.3-1.fc33 Old package: akonadi-import-wizard-20.04.2-1.fc33 Summary: Akonadi Import Wizard RPMs: akonadi-import-wizard akonadi-import-wizard-devel Size: 2.80 MiB Size change: -2.50 KiB Changelog: * Fri Jul 10 2020 Rex Dieter - 20.04.3-1 - 20.04.3 Package: akonadiconsole-20.04.3-1.fc33 Old package: akonadiconsole-20.04.2-1.fc33 Summary: Akonadi developer tool RPMs: akonadiconsole Size: 1.61 MiB Size change: -411 B Changelog: * Fri Jul 10 2020 Rex Dieter - 20.04.3-1 - 20.04.3 Package: akregator-20.04.3-1.fc33 Old package: akregator-20.04.2-1.fc33 Summary: Feed Reader RPMs: akregator akregator-libs Size: 8.23 MiB Size change: -4.31 KiB Changelog: * Fri Jul 10 2020 Rex Dieter - 20.04.3-1 - 20.04.3 Package: ark-20.04.3-1.fc33 Old package: ark-20.04.1-1.fc33 Summary: Archive manager RPMs: ark ark-libs Size: 7.09 MiB Size change: -8.96 KiB Changelog: * Fri Jun 12 2020 Rex Dieter - 20.04.2-1 - 20.04.2 * Fri Jul 10 2020 Rex Dieter - 20.04.3-1 - 20.04.3 Package: armadillo-9.900.2-1.fc33 Old package: armadillo-9.900.1-1.fc33 Summary: Fast C++ matrix library with syntax similar to MATLAB and Octave RPMs: armadillo armadillo-devel Size: 10.92 MiB Size change: -3.00 KiB Changelog: * Fri Jul 17 2020 Jos?? Matos - 9.900.2-1 - update to 9.900.2 Package: awscli-1.18.99-1.fc33 Old package: awscli-1.18.98-1.fc33 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.81 MiB Size change: 167 B Changelog: * Fri Jul 17 2020 Gwyn Ciesla - 1.18.99-1 - 1.18.99 Package: ceph-2:15.2.4-5.fc33 Old package: ceph-2:15.2.4-1.fc33 Summary: User space components of the Ceph file system RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm ceph-mgr-dashboard ceph-mgr-diskprediction-cloud ceph-mgr-diskprediction-local ceph-mgr-k8sevents ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts ceph-radosgw ceph-resource-agents ceph-selinux ceph-test cephadm cephfs-java cephfs-shell libcephfs-devel libcephfs2 libcephfs_jni-devel libcephfs_jni1 librados-devel librados2 libradospp-devel libradosstriper-devel libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados python3-rbd python3-rgw rados-objclass
[Bug 1853574] Devel::Cover produces warning about build vs runtime perl mismatch
https://bugzilla.redhat.com/show_bug.cgi?id=1853574 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Devel-Cover-1.33-5.fc3 ||2 Resolution|--- |ERRATA Last Closed||2020-07-19 01:09:09 --- Comment #3 from Fedora Update System --- FEDORA-2020-fc31c17b0a 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
Re: Remove all non UK/USA English spell checker variants from default Fedora installation
On Sat, 2020-07-18 at 18:45 -0500, Dennis Gilmore wrote:
> Just like there is many different dialects of Spanish, and other
> languages the same is true of English, many parts of the language are
> shared, and the most critical part for most people is making sure
> that
> things like Paper settings, date, and number formats are correct for
> their location. It is also critical that the local nuances though
> looking at what is in place on disk all the other languages are
> symlinks to en_GB except for en_CA and en_US
yes, all others languages are symlinks , therefore aren't useful.
I remove them every time that they are installed, with this simple
script [1] .
It very annoying Firefox or Evolution offer 22 languages the check
spell when they are really 3 ...
[1]
(cd /usr/share/myspell; find -type l -exec rm {} \;)
> Dennis
>
> On Sat, Jul 18, 2020 at 7:45 AM Germano Massullo
> wrote:
> > All desktop oriented Fedora installers install on the system
> > packages:
> > hunspell
> > hunspell-en
> > hunspell-en-GB
> > hunspell-en-US
> >
> > When a user opens the language list of the spell checker, is has
> > ~24 different English options, like English (Antigua and Barbuda),
> > English (Australia), English (Bahamas), English (Belize), etc. (See
> > screenshot [1])
> > People who are not native English speakers have this list even
> > bigger because they will have their own language entry, plus
> > others.
> >
> > Since the huge list is brought by hunspell-en, can we just ship
> > Fedora with hunspell-en-GB and hunspell-en-US ?
> > Another option could be to move all non GB/USA English variants to
> > other hunspell-en-* packages as I said in ticket [2]
> >
> >
> > [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536
> > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241
> > ___
> > 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
--
Sérgio M. B.
___
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
[SONAME BUMP] capnproto 0.8.0
Hey all, capnproto 0.8.0 has been pushed into Rawhide, and with it, a soname bump from 0.7.0 to 0.8.0 has occurred. Based on the repoquery, only three packages are dependent on it: * mir * rr * sonic-visualiser I've triggered rebuilds for all of them accordingly. -- 真実はいつも一つ！/ 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: Remove all non UK/USA English spell checker variants from default Fedora installation
Just like there is many different dialects of Spanish, and other languages the same is true of English, many parts of the language are shared, and the most critical part for most people is making sure that things like Paper settings, date, and number formats are correct for their location. It is also critical that the local nuances though looking at what is in place on disk all the other languages are symlinks to en_GB except for en_CA and en_US Dennis On Sat, Jul 18, 2020 at 7:45 AM Germano Massullo wrote: > > All desktop oriented Fedora installers install on the system packages: > hunspell > hunspell-en > hunspell-en-GB > hunspell-en-US > > When a user opens the language list of the spell checker, is has ~24 > different English options, like English (Antigua and Barbuda), English > (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1]) > People who are not native English speakers have this list even bigger because > they will have their own language entry, plus others. > > Since the huge list is brought by hunspell-en, can we just ship Fedora with > hunspell-en-GB and hunspell-en-US ? > Another option could be to move all non GB/USA English variants to other > hunspell-en-* packages as I said in ticket [2] > > > [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536 > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241 > ___ > 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: How do Fedora developers get access to devtoolset for testing.
Steven Munroe wrote: > Kevin Kofler wrote: >>http://mirror.centos.org/centos/7/sclo/x86_64/rh/ > > I was looking for ppc64le but I think found a source at: > > https://cbs.centos.org/koji/buildinfo?buildID=27175 The official location for ppc64le appears to be: http://mirror.centos.org/altarch/7/sclo/ppc64le/rh/ 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: F33 Change proposal: Replace Linux kernel with BSD kernel
Andy Mender wrote: > And I thought it's an April Fools' follow-up to the "ditch rpm in favor of > dpkg" Do you want me to resubmit https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default ? ;-) 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Saturday, July 18, 2020 3:25:35 AM MST Benjamin Berg wrote: > On Fri, 2020-07-17 at 19:44 -0700, John M. Harris Jr wrote: > > On Friday, July 17, 2020 10:06:53 AM MST Benjamin Berg wrote: > > > What we achieve by killing a process is that we give the kernel more > > > flexibility in how it manages the available memory. It really doesn't > > > matter what you kill, all that matters is that some memory is free'ed > > > up again. > > > > It does matter what you kill, because you're wiping out users' data and > > stopping software the user intended to have run. The kernel is already > > more > > than capable of freeing memory for itself, that's not what this Change is > > for either. This Change is to abuse the OOM killer to run in non-OOM > > scenarios using a userspace daemon. > > No, an OOM scenario from a kernel point of view means, that it has no > other choice than to kill a process. Users' processes should NEVER be killed, unless there is no other choice to keep the system running. > You *really* need to accept that the kernel OOM killer is insufficient > in many scenarios. It is only the last line of defence, that is solely > concerned about whether the system is *technically* capable of running. It's more than sufficient for the goal you listed, which is to keep the kernel working. > But thrashing scenarios are exactly that, *technically* running but > *practically* dead. Thrashing doesn't mean the system is unusable, or anything of the sort. It's only an issue if you're thrashing for too long. > I think it only makes sense to continue a discussion if you acknowledge > the existence and really understand the scenario described here: > https://lkml.org/lkml/2019/8/4/15 I've linked to that very thread several times in this thread. The bug here is in the web browsers that cause that behavior. The solution is to either fix the web browsers or limit the amount of memory they can run away with. -- 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: Remove all non UK/USA English spell checker variants from default Fedora installation
Kevin, It's not compared to other languages but to other spellings of the same language. Why should it be UK/US and not US only? Because there are millions of people using British spelling instead of US spelling. Not only in Britain but around the world; and many other spellings root from the British variation. Unless it takes a lot of space, what's the harm in keeping it? Kind regards, Silvia FAS: Lailah On Sat, 18 Jul 2020 at 15:22, Kevin Kofler wrote: > Germano Massullo wrote: > > Since the huge list is brought by hunspell-en, can we just ship Fedora > > with hunspell-en-GB and hunspell-en-US ? > > I would even argue for shipping en_US only. It is the default language of > the distribution. Why would British be any more worth shipping than any > other language out there? > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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: if we want to advocate btrfs
On Sat, Jul 18, 2020 at 12:51 PM Andy Mender wrote: > > On Sun, 12 Jul 2020 at 18:09, Chris Murphy wrote: >> >> On Sun, Jul 12, 2020 at 5:39 AM Andy Mender wrote: >> > >> >On updates, a single automatic corrupted snapshot can >> > potentially hose the entire snapshotted volume. >> >> How do you mean? If this is a sort of superficial corruption like a >> bad/failed/partial update, inconsistency between package manager and >> what's installed - this can be self-contained to a specific snapshot. >> One possible idea for updates is snapshot and do the update out of >> band (not the current running sysroot) on a snapshot. If the update >> fails for whatever reason, destroy the snapshot. Corruption that >> affects multiple subvolumes wouldn't be related to snapshotting, but >> the shared trees: extent, chunk, csum, uuid, etc. trees. > > > I'm sorry, I should've been a little more specific. What I meant was that a > corrupted snapshot can potentially impact the subvolume and put it in a state > in which simply deleting the latest snapshot is not going to help or can't > easily be done. It depends on the nature of the corruption. If it's file system corruption, e.g. due to some kind of hardware problem, then yeah it could affect any number of things and not be isolated to a particular subvolume. Whereas if I make a snapshot and intentionally corrupt it, e.g. by deleting half the files in it, and truncating the rest - all of those changes are isolated to the snapshot and in no way affect the original subvolume. >> >> >> >Also, if your system is almost broken after the change, >> > no snapshot will help. >> >> I'm not sure about the nature of the brokenness in your example. Btrfs >> does have a concept of a volume wide snapshot, which is the seed >> device. The file system is merely marked read-only, but can have a >> second device added that accepts all writes. If this two device volume >> were to become irreversibly confused, it'd still be possible to revert >> to the read-only device - even temporarily - as a kind of "recovery" >> boot. With extreme prejudice, a true factory reset is possible by >> wiping the read-write 2nd device and starting over. It's also possible >> to use it for replication - by adding a 2nd device and removing the >> 1st, an exact copy is made. This is a whole separate ball of wax, and >> while there are ideas how it might be leveraged, there's no plan to do >> so yet. >> > I agree, but it requires adding a second device and sometimes that's not > possible or tricky. Yeah, anyone using that particular feature would have something like an A/B partition setup as the two devices. The A partition would be the read-only "recovery" image, and the second device is just a second partition that accepts the changes from A. And in fact, you can boot either A or B. Or you could even boot C, made from A and a ramdisk as a volatile 2nd device. >I extrapolated a lot, but sometimes btrfs tools are marketed as a "catch all" >which can save the user from accidental installations or updates and that's >not always true. Do you have an example? I'm not sure I follow. In my case, I'm not using any automated tools. I don't consistently take snapshots before updates. If I don't make a snapshot, and foul an update somehow, Btrfs offers no magic solution for that. If I do make a snapshot first - I can do (and have done) truly vile and malicious things like rm -rf / and watch everything pancake; but I can pull the plug, boot, point to the snapshot as the new root, and the system boots fine. The messed up original root subvolume can just be deleted. -- 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: How do Fedora developers get access to devtoolset for testing.
Kevin Kofler wrote: >http://mirror.centos.org/centos/7/sclo/x86_64/rh/ I was looking for ppc64le but I think found a source at: https://cbs.centos.org/koji/buildinfo?buildID=27175 Thanks. ___ 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: Needs help to finalize partio.spec
On 2020-07-18 12:11 p.m., chedi toueiti wrote:
The error in your build.log ()
error: Installed (but unpackaged) file(s) found:
/usr/lib64/python/site-packages/partedit.py
/usr/lib64/python/site-packages/partinspect.py
/usr/lib64/python/site-packages/partjson.py Installed (but unpackaged)
file(s) found: /usr/lib64/python/site-packages/partedit.py
/usr/lib64/python/site-packages/partinspect.py
/usr/lib64/python/site-packages/partjson.py
Indicate that you have installed some files but did not list them in
the %files section, alghouth,
These paths are not the standard install paths for python files.
That is what I figure out after considering the Fedora Python guideline.
going by the line #Remove files from unversioned python directory rm
-f %{buildroot}%{python_sitearch}/*.py
I think you were intending to delete them to but |the macro
*%{python3_sitearch}* ||expands to
*/usr/lib64/python3.X/site-packages*|**on 64bit architectures (e.g.
x86_64) and *|/usr/lib/python3.X/site-packages|* on 32bit.
so maybe update your install script or replace the deletion line as
following
*rm -f %{buildroot}/usr/lib64/python/site-packages/*.py*
That suggestion did the trick as seen on the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=47394295
Thank you for your help.
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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: Ditch RPM in favor of DPKG
On Saturday, 18 July 2020 at 12:19, Nico Kadel-Garcia wrote: > On Sat, Jul 18, 2020 at 1:21 AM Anthony F McInerney wrote: > > On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr > > wrote: > >> > >> On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote: > >> > there was no reason not to replac it with regular apt > >> > >> Nico touched on these already, but that's simply not possible. > >> Rather, it's possible, but would immediately break your system upon > >> installing software using apt. > > I responded to what he claimed later was a "joke". It was a bait and > switch. The boy is trolling. Oh, come on. Are you serious? This was an actual implemented change to switch Fedora apt package from apt-rpm, which was dead upstream to the Debian apt to make building of Debian packages on Fedora easier. No trolling. The only joke was in the subject and it seems people are still falling for it. Please just stop putting your foot in it[1]. [1] Strange idiom, that one. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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 1858528] New: perl-File-Path-2.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858528 Bug ID: 1858528 Summary: perl-File-Path-2.17 is available Product: Fedora Version: rawhide Status: NEW Component: perl-File-Path Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.17 Current version/release in rawhide: 2.16-440.fc32 URL: http://search.cpan.org/dist/File-Path/ 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/2897/ -- 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: Needs help to finalize partio.spec
The error in your build.log ()
error: Installed (but unpackaged) file(s) found:
/usr/lib64/python/site-packages/partedit.py
/usr/lib64/python/site-packages/partinspect.py
/usr/lib64/python/site-packages/partjson.py
Installed (but unpackaged) file(s) found:
/usr/lib64/python/site-packages/partedit.py
/usr/lib64/python/site-packages/partinspect.py
/usr/lib64/python/site-packages/partjson.py
Indicate that you have installed some files but did not list them in
the %files section, alghouth,
These paths are not the standard install paths for python files.
going by the line
#Remove files from unversioned python directory
rm -f %{buildroot}%{python_sitearch}/*.py
I think you were intending to delete them to but the macro
*%{python3_sitearch}* expands to */usr/lib64/python3.X/site-packages*
on 64bit architectures (e.g. x86_64) and
*/usr/lib/python3.X/site-packages* on 32bit.
so maybe update your install script or replace the deletion line as following
*rm -f %{buildroot}/usr/lib64/python/site-packages/*.py*
On Sat, Jul 18, 2020 at 7:47 PM Luya Tshimbalanga
wrote:
> Hello team,
>
> I am about to package partio[1], a component used by openshadinglanguage
> (a new dependency for Blender) but hit an issue relate to an
> non-versioned python files. Will someone show pointer?
>
> Thanks in advance.
>
> Reference:
>
> [1]
>
> https://download.copr.fedorainfracloud.org/results/luya/openshadinglanguage/fedora-rawhide-x86_64/01559509-partio/partio.spec
>
> COPR:
>
> https://download.copr.fedorainfracloud.org/results/luya/openshadinglanguage/fedora-rawhide-x86_64/01559509-partio/
>
> --
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
> ___
> 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
>
--
*Chedi Toueiti*
* Due to the constant fluctuation in customer personalities, we cannot be
responsible for the mental stability of any one member of our staff.
** My opinions may have changed, but not the fact that I am right.
*** I always try to go the extra mile at work, but my boss always finds me
and brings me back.
___
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: if we want to advocate btrfs
On Sun, 12 Jul 2020 at 18:09, Chris Murphy wrote: > On Sun, Jul 12, 2020 at 5:39 AM Andy Mender > wrote: > > > >On updates, a single automatic corrupted snapshot can > > potentially hose the entire snapshotted volume. > > How do you mean? If this is a sort of superficial corruption like a > bad/failed/partial update, inconsistency between package manager and > what's installed - this can be self-contained to a specific snapshot. > One possible idea for updates is snapshot and do the update out of > band (not the current running sysroot) on a snapshot. If the update > fails for whatever reason, destroy the snapshot. Corruption that > affects multiple subvolumes wouldn't be related to snapshotting, but > the shared trees: extent, chunk, csum, uuid, etc. trees. > I'm sorry, I should've been a little more specific. What I meant was that a corrupted snapshot can potentially impact the subvolume and put it in a state in which simply deleting the latest snapshot is not going to help or can't easily be done. > > >Also, if your system is almost broken after the change, > > no snapshot will help. > > I'm not sure about the nature of the brokenness in your example. Btrfs > does have a concept of a volume wide snapshot, which is the seed > device. The file system is merely marked read-only, but can have a > second device added that accepts all writes. If this two device volume > were to become irreversibly confused, it'd still be possible to revert > to the read-only device - even temporarily - as a kind of "recovery" > boot. With extreme prejudice, a true factory reset is possible by > wiping the read-write 2nd device and starting over. It's also possible > to use it for replication - by adding a 2nd device and removing the > 1st, an exact copy is made. This is a whole separate ball of wax, and > while there are ideas how it might be leveraged, there's no plan to do > so yet. > > I agree, but it requires adding a second device and sometimes that's not possible or tricky. I extrapolated a lot, but sometimes btrfs tools are marketed as a "catch all" which can save the user from accidental installations or updates and that's not always true. ___ 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
Needs help to finalize partio.spec
Hello team, I am about to package partio[1], a component used by openshadinglanguage (a new dependency for Blender) but hit an issue relate to an non-versioned python files. Will someone show pointer? Thanks in advance. Reference: [1] https://download.copr.fedorainfracloud.org/results/luya/openshadinglanguage/fedora-rawhide-x86_64/01559509-partio/partio.spec COPR: https://download.copr.fedorainfracloud.org/results/luya/openshadinglanguage/fedora-rawhide-x86_64/01559509-partio/ -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ 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: Self Introduction Ludovic Hirlimann
On Fri, 17 Jul 2020 at 16:14, Ludovic Hirlimann via devel < devel@lists.fedoraproject.org> wrote: > Hi, > > > I'm ludo. I've been involved with opensource for a long time now (using > my first linux in 1996). I have been a mozilla employee for 10 years (as > the Thunderbird QA lead and then as an IT staffer). I'm back to linux > since 2015 (used FreeBSD and MacOSX since 2000). I choose Fedora as my > distribution of choice and been running it since version 21. I like > opendata and have particpated in musicbrainz and still participate to > openstreetmap. I've always like maps and thus I'd like to join de Fedora > packaging community to maintain, or help maintain two packages that are > Map related : josm and qgis. > > I don't have much experience in maintaining packages but I'm more than > willing to learn. > > Have a nice day. > > Ludovic > > -- > https://www.hirlimann.net/Ludovic/carnet/ > Maps are super fun! Welcome aboard! :) ___ 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: F33 Change proposal: Replace Linux kernel with BSD kernel
On Sat, 18 Jul 2020 at 04:53, John M. Harris Jr wrote: > On Thursday, July 16, 2020 2:37:55 PM MST Ben Cotton wrote: > > > F33 Change proposal: Replace Linux kernel with BSD kernel - System-Wide > > Well, which BSD kernel? ;) > > > This email just serves as a neat example of that potential new format for > Change proposals. > And I thought it's an April Fools' follow-up to the "ditch rpm in favor of dpkg" ___ 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: Remove all non UK/USA English spell checker variants from default Fedora installation
On Sat, 18 Jul 2020 at 14:44, Germano Massullo wrote: > All desktop oriented Fedora installers install on the system packages: > hunspell > hunspell-en > hunspell-en-GB > hunspell-en-US > > When a user opens the language list of the spell checker, is has ~24 > different English options, like English (Antigua and Barbuda), English > (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1]) > People who are not native English speakers have this list even bigger > because they will have their own language entry, plus others. > I never quite understood the necessity for all of those extra English language packages since early Windows versions. I assumed there was some forced name overlap with locale packages so that for instance locale "English (Antigua and Barbuda)" knows that it should look for the "English (Antigua and Barbuda)" language package. > Since the huge list is brought by hunspell-en, can we just ship Fedora > with hunspell-en-GB and hunspell-en-US ? > Another option could be to move all non GB/USA English variants to other > hunspell-en-* packages as I said in ticket [2] > > > [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536 > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241 > I see there is a bit of a chicken and egg problem with the GB/US hunspell-en variants, because they're pulled in as dependencies of hunspell-en, right? I think your idea (shipping only the GB/US variants instead of the main hunspell-en package) makes sense. ~Andy ___ 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: Remove all non UK/USA English spell checker variants from default Fedora installation
Le samedi 18 juillet 2020 à 15:21 +0200, Kevin Kofler a écrit : > Germano Massullo wrote: > > Since the huge list is brought by hunspell-en, can we just ship > > Fedora > > with hunspell-en-GB and hunspell-en-US ? > > I would even argue for shipping en_US only. It is the default > language of > the distribution. Why would British be any more worth shipping than > any other language out there? Practically some people do care about original English. And, there is little to win deployment side, all those spellcheckers share a common trunk, the only annoying cost of more English variants is their footprint in language selectors Regards, -- Nicolas Mailhot ___ 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: Remove all non UK/USA English spell checker variants from default Fedora installation
Germano Massullo wrote: > Since the huge list is brought by hunspell-en, can we just ship Fedora > with hunspell-en-GB and hunspell-en-US ? I would even argue for shipping en_US only. It is the default language of the distribution. Why would British be any more worth shipping than any other language out there? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Remove all non UK/USA English spell checker variants from default Fedora installation
All desktop oriented Fedora installers install on the system packages: hunspell hunspell-en hunspell-en-GB hunspell-en-US When a user opens the language list of the spell checker, is has ~24 different English options, like English (Antigua and Barbuda), English (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1]) People who are not native English speakers have this list even bigger because they will have their own language entry, plus others. Since the huge list is brought by hunspell-en, can we just ship Fedora with hunspell-en-GB and hunspell-en-US ? Another option could be to move all non GB/USA English variants to other hunspell-en-* packages as I said in ticket [2] [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241 ___ 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: How do Fedora developers get access to devtoolset for testing.
Steven Munroe wrote: > So my project (pveclib) was requested for el7/8 which means building with > devtoolset-9. > > With a spec file enabled for el7, the local rpmbuild's fail if you don't > have devtoolset installed. The error message was less than helpful. > > So if you can use fedpkg scratch-build devtoolset is preinstalled. > > But if you have bugs in your spec file (and as a newbie, I often do) then > you also get failures with less than helpful status. > > FAILED: BuildError: error building package (arch ppc64le), mock exited > with status 1; see build.log or root.log for more information > > In my case I had to remove all the el7 bits from my spec file and test > with rpmbuild to find the problem. > > So having devtoolset installed locally would be helpful. http://mirror.centos.org/centos/7/sclo/x86_64/rh/ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Fri, 2020-07-17 at 19:44 -0700, John M. Harris Jr wrote: > On Friday, July 17, 2020 10:06:53 AM MST Benjamin Berg wrote: > > What we achieve by killing a process is that we give the kernel more > > flexibility in how it manages the available memory. It really doesn't > > matter what you kill, all that matters is that some memory is free'ed > > up again. > > It does matter what you kill, because you're wiping out users' data and > stopping software the user intended to have run. The kernel is already more > than capable of freeing memory for itself, that's not what this Change is for > either. This Change is to abuse the OOM killer to run in non-OOM scenarios > using a userspace daemon. No, an OOM scenario from a kernel point of view means, that it has no other choice than to kill a process. You *really* need to accept that the kernel OOM killer is insufficient in many scenarios. It is only the last line of defence, that is solely concerned about whether the system is *technically* capable of running. But thrashing scenarios are exactly that, *technically* running but *practically* dead. I think it only makes sense to continue a discussion if you acknowledge the existence and really understand the scenario described here: https://lkml.org/lkml/2019/8/4/15 Benjamin signature.asc Description: This is a digitally signed message part ___ 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: Ditch RPM in favor of DPKG
On Sat, Jul 18, 2020 at 1:21 AM Anthony F McInerney wrote: > > > > On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr wrote: >> >> On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote: >> > there was no reason not to replac it with regular apt >> >> Nico touched on these already, but that's simply not possible. Rather, it's >> possible, but would immediately break your system upon installing software >> using apt. I responded to what he claimed later was a "joke". It was a bait and switch. The boy is trolling. ___ 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 Sat, 2020-07-18 at 05:07 +0900, Alexey A. wrote: > > And this will turn bad quickly, as it will eventually > > include the executables/libraries that must be loaded as they are doing > > work! > > > So, we don't want to get the kernel into the situation where it must > > remove executables/libraries from main memory. If that happens, you can > > end up hitting the disk for *every* function call. > > BTW, with prelockd[1] executables/libraries will not be removed from > memory. This daemon can mlock executables/libraries in memory. > > Effects: > - OOM killer comes faster. > - Fast system reclaiming after OOM. Interesting, I had not seen that. I wonder how much memory that amounts to in the usual scenarios. Could be interesting to compare this to the point where EarlyOOM or similar would kick in. That said, I am sure that it is really effective at preventing many really bad thrashing scenarios. Benjamin > This daemon was written recently, published today. > > 1. https://github.com/hakavlad/prelockd > > вт, 14 июл. 2020 г. в 17:19, Benjamin Berg : > > On Mon, 2020-07-13 at 19:25 -0600, Chris Murphy wrote: > > > On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg wrote: > > > > If MemAvailable drops below 250MiB (roughly 6GiB * 4%), then this means > > > > that we have less than 500MiB left for file caches. If we can't swap > > > > (remember, swap is already pretty full too), then a big chunk of these > > > > caches need to be dropped to make the memory available to applications. > > > > > > I regularly see impressively low MemAvailable before earlyoom does > > > SIGTERM, it's almost always swap available (amount of total that's not > > > used) that's the defining factor. Well below 100MiB. This doesn't tend > > > to last very long. Once memory is under this kind of pressure, so is > > > swap, and as swap on zram is so fast, it gets to threshold fast as > > > well. > > > > Yep, EarlyOOM doesn't apply the limit if there is swap available. That > > makes a lot of sense. When swap page is available, the kernel has the > > choice which memory to reclaim (anonymous pages, i.e. swap, or file > > backed pages, i.e. drop caches). So MemAvailable may drop much lower > > temporarily and depending on the workload. > > > > You could say that when swap is available you assume the kernel has the > > ability to keep the system running reasonably well. Once swap runs out, > > the kernel stops having a choice. It can only make room by reclaiming > > important caches. And this will turn bad quickly, as it will eventually > > include the executables/libraries that must be loaded as they are doing > > work! > > > > So, we don't want to get the kernel into the situation where it must > > remove executables/libraries from main memory. If that happens, you can > > end up hitting the disk for *every* function call. > > > > Benjamin > > ___ > > 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 signature.asc Description: This is a digitally signed message part ___ 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 1858481] New: perl-Module-CoreList-5.20200717 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858481 Bug ID: 1858481 Summary: perl-Module-CoreList-5.20200717 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Module-CoreList Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, spo...@gmail.com, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20200717 Current version/release in rawhide: 5.20200603-1.fc33 URL: http://search.cpan.org/dist/Module-CoreList/ 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/3080/ -- 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
Self Introduction: Christoph Karl
Hallo, my name is Christoph Karl. I am a long time Fedora user, but I plan to change to CentOS 8. So I would like to see some more packages in the EPEL repo. So I plan to help with this as a co-maintainer. I have a little bit experience with packaging, but I am on may way learning more. First packages should/will be qjackctl and qsynth. Best regards Christoph ___ 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
corsepiu pushed to perl-HTTP-Entity-Parser (f31). "Cleanup merger."
Notification time stamped 2020-07-18 08:41:03 UTC From 0c808496d81c2b290ebe4b3973516344a5cb184e Mon Sep 17 00:00:00 2001 From: Ralf Corsépius Date: Jul 18 2020 08:30:34 + Subject: Cleanup merger. --- diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec index c01adbb..0ba5da8 100644 --- a/perl-HTTP-Entity-Parser.spec +++ b/perl-HTTP-Entity-Parser.spec @@ -72,9 +72,6 @@ data and application/json. * Sat Jul 18 2020 Ralf Corsépius - 0.23-1 - Update to 0.23. -* Tue Jun 23 2020 Jitka Plesnikova - 0.22-3 -- Perl 5.32 rebuild - * Thu Jan 30 2020 Fedora Release Engineering - 0.22-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/0c808496d81c2b290ebe4b3973516344a5cb184e?branch=f31 ___ 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
corsepiu pushed to perl-HTTP-Entity-Parser (f31). "Perl 5.32 rebuild"
Notification time stamped 2020-07-18 08:41:03 UTC
From f2ccc41c43d738d0117f0cddef65524325318bc6 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: Jun 23 2020 09:02:37 +
Subject: Perl 5.32 rebuild
---
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index 4597902..f5c8536 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Entity-Parser
Version:0.22
-Release:2%{?dist}
+Release:3%{?dist}
Summary:PSGI compliant HTTP Entity Parser
License:GPL+ or Artistic
URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
%{_mandir}/man3/*
%changelog
+* Tue Jun 23 2020 Jitka Plesnikova - 0.22-3
+- Perl 5.32 rebuild
+
* Thu Jan 30 2020 Fedora Release Engineering -
0.22-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/f2ccc41c43d738d0117f0cddef65524325318bc6?branch=f31
___
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
corsepiu pushed to perl-HTTP-Entity-Parser (f31). "Update to 0.23."
Notification time stamped 2020-07-18 08:41:03 UTC
From f62d0c6b4d95c0c05725f7fdb4ac57a6dd69eac7 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Jul 18 2020 07:30:49 +
Subject: Update to 0.23.
---
diff --git a/.gitignore b/.gitignore
index f19a402..49b9a90 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.22.tar.gz
+/HTTP-Entity-Parser-0.23.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index f5c8536..c01adbb 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Entity-Parser
-Version:0.22
-Release:3%{?dist}
+Version:0.23
+Release:1%{?dist}
Summary:PSGI compliant HTTP Entity Parser
License:GPL+ or Artistic
URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
%{_mandir}/man3/*
%changelog
+* Sat Jul 18 2020 Ralf Corsépius - 0.23-1
+- Update to 0.23.
+
* Tue Jun 23 2020 Jitka Plesnikova - 0.22-3
- Perl 5.32 rebuild
diff --git a/sources b/sources
index b6f2c3f..449fdea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.22.tar.gz) =
fc54b92af197ec4dbdb1069f5a7a8db0892483f80a3737f4914cb6d03dd0ec01b2b215bed96b6736474d2d484516071926774610ace475199cae44174cc2abd0
+SHA512 (HTTP-Entity-Parser-0.23.tar.gz) =
7ae384ae91b5519b9953f7186a898c8821d600c6ff2d2c659003dc23307cd01a5a241d3470509bafde72db6e611a74a56bb48b1ddc9d8c0bd12662e660febd25
https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/f62d0c6b4d95c0c05725f7fdb4ac57a6dd69eac7?branch=f31
___
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
corsepiu pushed to perl-HTTP-Entity-Parser (f31). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild (..more)"
Notification time stamped 2020-07-18 08:41:03 UTC
From 83d4e589dc97d5049ad4684b562f057bf2093b60 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering
Date: Jan 30 2020 00:57:51 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
Signed-off-by: Fedora Release Engineering
---
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index 403ea89..4597902 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Entity-Parser
Version:0.22
-Release:1%{?dist}
+Release:2%{?dist}
Summary:PSGI compliant HTTP Entity Parser
License:GPL+ or Artistic
URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
%{_mandir}/man3/*
%changelog
+* Thu Jan 30 2020 Fedora Release Engineering -
0.22-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
+
* Wed Nov 20 2019 Ralf Corsépius - 0.22-1
- Update to 0.22.
https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/83d4e589dc97d5049ad4684b562f057bf2093b60?branch=f31
___
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
corsepiu pushed to perl-HTTP-Entity-Parser (f32). "Cleanup merger."
Notification time stamped 2020-07-18 08:37:08 UTC From 0c808496d81c2b290ebe4b3973516344a5cb184e Mon Sep 17 00:00:00 2001 From: Ralf Corsépius Date: Jul 18 2020 08:30:34 + Subject: Cleanup merger. --- diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec index c01adbb..0ba5da8 100644 --- a/perl-HTTP-Entity-Parser.spec +++ b/perl-HTTP-Entity-Parser.spec @@ -72,9 +72,6 @@ data and application/json. * Sat Jul 18 2020 Ralf Corsépius - 0.23-1 - Update to 0.23. -* Tue Jun 23 2020 Jitka Plesnikova - 0.22-3 -- Perl 5.32 rebuild - * Thu Jan 30 2020 Fedora Release Engineering - 0.22-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/0c808496d81c2b290ebe4b3973516344a5cb184e?branch=f32 ___ 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
corsepiu pushed to perl-HTTP-Entity-Parser (f32). "Perl 5.32 rebuild"
Notification time stamped 2020-07-18 08:37:08 UTC
From f2ccc41c43d738d0117f0cddef65524325318bc6 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: Jun 23 2020 09:02:37 +
Subject: Perl 5.32 rebuild
---
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index 4597902..f5c8536 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Entity-Parser
Version:0.22
-Release:2%{?dist}
+Release:3%{?dist}
Summary:PSGI compliant HTTP Entity Parser
License:GPL+ or Artistic
URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
%{_mandir}/man3/*
%changelog
+* Tue Jun 23 2020 Jitka Plesnikova - 0.22-3
+- Perl 5.32 rebuild
+
* Thu Jan 30 2020 Fedora Release Engineering -
0.22-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/f2ccc41c43d738d0117f0cddef65524325318bc6?branch=f32
___
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
corsepiu pushed to perl-HTTP-Entity-Parser (f32). "Update to 0.23."
Notification time stamped 2020-07-18 08:37:08 UTC
From f62d0c6b4d95c0c05725f7fdb4ac57a6dd69eac7 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Jul 18 2020 07:30:49 +
Subject: Update to 0.23.
---
diff --git a/.gitignore b/.gitignore
index f19a402..49b9a90 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.22.tar.gz
+/HTTP-Entity-Parser-0.23.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index f5c8536..c01adbb 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Entity-Parser
-Version:0.22
-Release:3%{?dist}
+Version:0.23
+Release:1%{?dist}
Summary:PSGI compliant HTTP Entity Parser
License:GPL+ or Artistic
URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
%{_mandir}/man3/*
%changelog
+* Sat Jul 18 2020 Ralf Corsépius - 0.23-1
+- Update to 0.23.
+
* Tue Jun 23 2020 Jitka Plesnikova - 0.22-3
- Perl 5.32 rebuild
diff --git a/sources b/sources
index b6f2c3f..449fdea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.22.tar.gz) =
fc54b92af197ec4dbdb1069f5a7a8db0892483f80a3737f4914cb6d03dd0ec01b2b215bed96b6736474d2d484516071926774610ace475199cae44174cc2abd0
+SHA512 (HTTP-Entity-Parser-0.23.tar.gz) =
7ae384ae91b5519b9953f7186a898c8821d600c6ff2d2c659003dc23307cd01a5a241d3470509bafde72db6e611a74a56bb48b1ddc9d8c0bd12662e660febd25
https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/f62d0c6b4d95c0c05725f7fdb4ac57a6dd69eac7?branch=f32
___
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 1858476] New: perl-CPAN-Perl-Releases-5.20200717 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858476 Bug ID: 1858476 Summary: perl-CPAN-Perl-Releases-5.20200717 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPAN-Perl-Releases Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20200717 Current version/release in rawhide: 5.20200607-1.fc33 URL: http://search.cpan.org/dist/CPAN-Perl-Releases/ 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/5881/ -- 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
corsepiu pushed to perl-HTTP-Entity-Parser (master). "Update to 0.23."
Notification time stamped 2020-07-18 07:31:17 UTC
From f62d0c6b4d95c0c05725f7fdb4ac57a6dd69eac7 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Jul 18 2020 07:30:49 +
Subject: Update to 0.23.
---
diff --git a/.gitignore b/.gitignore
index f19a402..49b9a90 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.22.tar.gz
+/HTTP-Entity-Parser-0.23.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index f5c8536..c01adbb 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Entity-Parser
-Version:0.22
-Release:3%{?dist}
+Version:0.23
+Release:1%{?dist}
Summary:PSGI compliant HTTP Entity Parser
License:GPL+ or Artistic
URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
%{_mandir}/man3/*
%changelog
+* Sat Jul 18 2020 Ralf Corsépius - 0.23-1
+- Update to 0.23.
+
* Tue Jun 23 2020 Jitka Plesnikova - 0.22-3
- Perl 5.32 rebuild
diff --git a/sources b/sources
index b6f2c3f..449fdea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.22.tar.gz) =
fc54b92af197ec4dbdb1069f5a7a8db0892483f80a3737f4914cb6d03dd0ec01b2b215bed96b6736474d2d484516071926774610ace475199cae44174cc2abd0
+SHA512 (HTTP-Entity-Parser-0.23.tar.gz) =
7ae384ae91b5519b9953f7186a898c8821d600c6ff2d2c659003dc23307cd01a5a241d3470509bafde72db6e611a74a56bb48b1ddc9d8c0bd12662e660febd25
https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/f62d0c6b4d95c0c05725f7fdb4ac57a6dd69eac7?branch=master
___
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 1858467] New: perl-Compress-Bzip2-2.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858467 Bug ID: 1858467 Summary: perl-Compress-Bzip2-2.28 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Compress-Bzip2 Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.28 Current version/release in rawhide: 2.27-2.fc33 URL: http://search.cpan.org/dist/Compress-Bzip2/ 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/2709/ -- 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 1858048] rt-5.0.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858048 Ralf Corsepius changed: What|Removed |Added Depends On||1858466 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1858466 [Bug 1858466] Review Request: perl-Path-Dispatcher - Flexible and extensible dispatch -- 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
