[Bug 1909780] perl-System-Info-0.060 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909780 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- 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: Orphaning nodeja-svgo
On 12/22/20 9:25 AM, Luya Tshimbalanga wrote: Due to multiple missing nodejs dependencies needed for nodejs-svgo, I had to orphan it. That plugin was intended for Inkscape sgvo. Maintainers are welcome to grab it. https://src.fedoraproject.org/rpms/nodejs-svgo How does this compare to Scour ? Is this a better alternative: https://github.com/juanfran/svgo-inkscape In the long run, might https://github.com/svgpp/svgpp be a place to add SVG cleaning functionality? ___ 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
Orphaning nodeja-svgo
Due to multiple missing nodejs dependencies needed for nodejs-svgo, I had to orphan it. That plugin was intended for Inkscape sgvo. Maintainers are welcome to grab it. https://src.fedoraproject.org/rpms/nodejs-svgo -- 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
[389-devel] 389 DS nightly 2020-12-22 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/12/22/report-389-ds-base-1.4.4.9-1.fc33.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: TBB soname bump
On Mon, Dec 21, 2020 at 3:12 PM Florian Weimer wrote: > To be honest, creating a custom Fedora version of tbb that does not > match neither the old nor the new version does not sound particularly > attractive. Agreed. With a compatibility package, however, we'll have to be vigilant that no executable can pull in both the old and new versions through different library dependencies. > We need a compatibility package for downstream use anyway (although > probably only for supporting existing binaries, not for building new > things). That is, if the transition happens for Fedora 34. I expect > Thomas Rodgers will contact you about this topic in the new year. Okay, I will be happy to talk to him about it. This looks like a disruptive update, so the more eyes on it the better. A COPR build of tbb 2021.1.1 is available for anyone who wants to try it out: https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ -- Jerry James http://www.jamezone.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
[Bug 1909364] perl-CPANPLUS-0.9910 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909364 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2020-8e0d016a7b has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8e0d016a7b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e0d016a7b 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: Non-responsive maintainer check for slaanesh
Slaanesh is still active. The best way to contact him is through e-mail. On 2020-12-21 1:05 p.m., Robert Scheck wrote: Hello all, given the lack of any response over a timeframe of 1+ months at https://bugzilla.redhat.com/show_bug.cgi?id=1896375 for libtelnet, I am hereby starting (as suggested by Stephen Smoogen at Freenode IRC #fedora-apps) week #0 of https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ via https://bugzilla.redhat.com/show_bug.cgi?id=1909867 now. As part of the process: Does anyone know how to contact the maintainer using other ways? Thank you. Regards, Robert ___ 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 -- 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
[Bug 1909364] perl-CPANPLUS-0.9910 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909364 --- Comment #5 from Fedora Update System --- FEDORA-2020-8dc1b2602a has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8dc1b2602a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8dc1b2602a 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
Neal Gompa writes: On Mon, Dec 21, 2020 at 1:14 PM Marius Schwarz wrote: > > If something really needs to change, it is the 50+ MB repo database that > gets downloaded. It takes ages on slow connections to download > and than you want to increase the size of the rpms too.. Doesn't sound > like a good idea. > You should be getting delta fetching of repository metadata with zchunk metadata, which we've had enabled since Fedora 30: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata Is this not working for you or something? Well, I don't know what's working for me, or not working for me. All I know is that: 1) I'm rsyncing the updates repo to my LAN, and other machines in my lan have the default updates repo disablde and a replacement repo pointing at my local copy. 2) Even on the LAN, an update downloads something from the local repo, giving me a zippy progress indication of the download. After the download it sits for a noticeable amount of time before it decides exactly what it's going to update and then gives me the list. This is especially noticable for a Fedora VM guest that I'm running in a VM that's emulating an aarch64 platform. In the emulated aarch64 VM downloading of RPMs goes a bit slow, but the subsequent pause after download is quite noticable. Except for rsyncing a mirror of the updates repo locally and then pointing everyone to my local mirror, I am not doing any other customization and that's the behavior I've seen. Having said all that, I don't find the update process to be that much of a pain point right now, and in any dire need of improvement. It works. It is fairly reliable. A bit slow, but who cares. The important thing is that except for a burst of segfaults downloading rpms earlier this year (haven't had any in a while) it's been rock stable and hiccups are very, very rare. I don't exactly see what's the big value-added from the described feature enhancement, I'd only want to make sure it's just as stable. pgpZBUJUKA6HS.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
[Bug 1909508] perl-Module-CoreList-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909508 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2020-d971f57a54 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d971f57a54` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d971f57a54 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 1909508] perl-Module-CoreList-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909508 --- Comment #4 from Fedora Update System --- FEDORA-2020-bac5ecd005 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-bac5ecd005` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bac5ecd005 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 1909507] perl-CPAN-Perl-Releases-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909507 --- Comment #4 from Fedora Update System --- FEDORA-2020-28a677bff8 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-28a677bff8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-28a677bff8 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 1909507] perl-CPAN-Perl-Releases-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909507 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2020-039eaf42c6 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-039eaf42c6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-039eaf42c6 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c82583d07e pngcheck-2.4.0-5.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fe42686452 mbedtls-2.16.9-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing gaupol-1.8-3.el8 ike-scan-1.9.4-29.el8 mac-robber-1.02-19.el8 pdns-4.4.0-2.el8 poly2tri-0.0-21.20130501hg26242d0aa7b8.el8 systemd-extras-247.2-1.el8 Details about builds: gaupol-1.8-3.el8 (FEDORA-EPEL-2020-3b16651d4a) Editor for text-based subtitle files Update Information: Initial package for EPEL8 ChangeLog: ike-scan-1.9.4-29.el8 (FEDORA-EPEL-2020-d06644c785) IKE protocol tool to discover, fingerprint and test IPsec VPN servers Update Information: Update to upstream details ChangeLog: * Mon Dec 21 2020 Fabian Affolter - 1.9.4-29 - Update to upstream details * Tue Jul 28 2020 Fedora Release Engineering - 1.9.4-28 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jan 29 2020 Fedora Release Engineering - 1.9.4-27 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild mac-robber-1.02-19.el8 (FEDORA-EPEL-2020-0d9972ef1d) Tool to create a timeline of file activity for mounted file systems Update Information: Introduce package to solve sleuthkit dependency ChangeLog: pdns-4.4.0-2.el8 (FEDORA-EPEL-2020-4f95e55920) A modern, advanced and high performance authoritative-only nameserver Update Information: - Update to 4.4.0 Release notes: https://doc.powerdns.com/authoritative/changelog/4.4.html#change-4.4.0 ChangeLog: * Mon Dec 21 2020 Morten Stevens - 4.4.0-2 - Fix building on RHEL8 * Mon Dec 21 2020 Morten Stevens - 4.4.0-1 - Update to 4.4.0 * Sat Dec 5 2020 Jeff Law - 4.3.1-3 - Fix missing #include for gcc-11 * Thu Sep 24 2020 Adrian Reber - 4.3.1-2 - Rebuilt for protobuf 3.13 poly2tri-0.0-21.20130501hg26242d0aa7b8.el8 (FEDORA-EPEL-2020-0db9409558) A 2D constrained Delaunay triangulation library Update Information: Introduce poly2tri package for EPEL 8 ChangeLog: References: [ 1 ] Bug #1908933 - Please build poly2tri for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1908933 systemd-extras-247.2-1.el8 (FEDORA-EPEL-2020-4f83029b1a) System and Service Manager (optional components) Update Information: Changes with 247* `systemd-networkd`'s `.network` files gained support for explicitly configuring the multicast membership entries of bridge devices in the `[BridgeMDB]` section. It also gained support for the PIE queuing discipline in the `[FlowQueuePIE]` sections.* `systemd-networkd`'s `.netdev` files may now be used to create "BareUDP" tunnels, configured in the new `[BareUDP]` setting. * `systemd-networkd`'s `Gateway=` setting in `.network` files now accepts the special values "_dhcp4" and "_ipv6ra" to configure additional, locally defined, explicit routes to the gateway acquired via DHCP or IPv6 Router Advertisements. The old setting "_dhcp" is deprecated, but still accepted for backwards compatibility.*
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-bc6881c4f5 pngcheck-2.4.0-5.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dddcb59a9c phpldapadmin-1.2.5-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83291355d7 openssl11-1.1.1g-2.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599 openjpeg2-2.3.1-10.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing ike-scan-1.9.4-29.el7 Details about builds: ike-scan-1.9.4-29.el7 (FEDORA-EPEL-2020-e145b0a3d9) IKE protocol tool to discover, fingerprint and test IPsec VPN servers Update Information: Update to upstream details ChangeLog: * Mon Dec 21 2020 Fabian Affolter - 1.9.4-29 - Update to upstream details * Tue Jul 28 2020 Fedora Release Engineering - 1.9.4-28 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jan 29 2020 Fedora Release Engineering - 1.9.4-27 - 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, 2020-12-21 at 12:48 -0500, Colin Walters wrote: > > On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote: > > > > > > == Summary == > > > > RPM Copy on Write provides a better experience for Fedora Users as > > it > > reduces the amount of I/O and offsets CPU cost of package > > decompression. RPM Copy on Write uses reflinking capabilities in > > btrfs, which is the default filesystem in Fedora 33. > > A bunch of points here: > > - No, it's the default for one Edition. Others don't default to > it. And even for Workstation we can't *require* it because it's > definitely supported to use other filesystems and storage layouts. > > - Orthogonal to this, I'd also note that xfs supports reflinks too. > > Combining those I'd say instead e.g.: "Most Fedora Editions default > to a filesystem that support reflinks, e.g. btrfs or xfs" (actually I > think IoT defaults to ext4 for...probably they didn't consider it?) Thanks for surfacing this, we'll make the language clearer. About XFS: it should work, but we haven't tested it extensively, and this work has been developed primarily with btrfs in mind. > - When talking about RPMs we need to think about container images, > which use overlayfs by default, which defers to the underlying > filesystem for reflinks - so should be fine, but should be explicitly > written down (and tested) If reflinking isn't possible (which can also happen if e.g. the package cache and the system are on different filesystems) things work as normal, albeit with a performance penalty (because more I/O is required to install the package). I'll let Matthew weigh in on the other points you raised. Thanks for the feedback! 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: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, 2020-12-21 at 12:54 -0400, Robert Marcano via devel wrote: > On 12/21/20 12:28 PM, Ben Cotton wrote: > > ... > > > > === New process === > > > > # Resolve packaging request into a list of packages and operations > > # Download and '''decompress''' packages into a '''locally > > optimized''' rpm file > > # Install and/or upgrade packages sequentially using RPM files, > > using > > '''reference linking''' (reflinking) to reuse data already on disk. > > This sound great because free space requirements can be reduced, > specially when installing new packages. > > I have experimented building very small appliances using btrfs > compression on things like /usr/share. So I think this could disrupt > this because if I am correct the extends will be first downloaded to > a > temporary directory without compression enabled. For CoW to be beneficial, the package cache should be on the same filesystem used for the bulk of the system. In this scenario, compression should work just fine, as long as it's enabled on the appropriate subvolumes. > I am happy with an option to disable this behavior. To be clear, for this Change we do not plan to enable CoW by default. If would be a user opt-in via the dnf-plugin-cow package. 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: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, 2020-12-21 at 09:53 -0800, Kevin Fenzi wrote: > Cool. A few questions inline... > > On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/RPMCoW > > > > > > == Summary == > > > > RPM Copy on Write provides a better experience for Fedora Users as > > it > > reduces the amount of I/O and offsets CPU cost of package > > decompression. RPM Copy on Write uses reflinking capabilities in > > btrfs, which is the default filesystem in Fedora 33. > > What happens if you enable this on non btrfs installs? > Does it just not work gracefully? Does it fail somehow? It would be slower but still works; see note #5 > https://fedoraproject.org/wiki/Changes/RPMCoW#Notes Of note, even on systems with Btrfs/XFS that support reflinks, falling back to copying is still needed for e.g. files in /boot or /boot/EFI -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 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 1909889] New: perl-DateTime-TimeZone-2.45 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909889 Bug ID: 1909889 Summary: perl-DateTime-TimeZone-2.45 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-TimeZone 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: 2.45 Current version/release in rawhide: 2.44-1.fc34 URL: http://search.cpan.org/dist/DateTime-TimeZone/ 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/2801/ -- 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 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 2:20 pm, Aleksei Bavshin wrote: It's just that as a maintainer of one of those alternative desktop environments I have no idea how to make that work in default configuration. You're going to want to create a new systemd scope for each application that you launch. I'd start by reading https://lwn.net/Articles/834329/ for an overview. https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/libgnome-desktop/gnome-systemd.c shows how we do it. If you use glib, then https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1596 will make this a lot easier! ___ 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 CoreOS rawhide stream
We've recently started a rawhide "mechanical" stream of Fedora CoreOS (mechanical streams are streams that are meant for developers and that don't use RPM lockfiles). You can see the first build here: https://builds.coreos.fedoraproject.org/browser?stream=rawhide This will allow us to more easily track breaking changes in rawhide and work with maintainers and upstreams to resolve them earlier in the process. (Yes, this is long overdue -- better late than never!) Cheers! Jonathan ___ 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 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On 12/21/20 1:53 PM, Neal Gompa wrote: On Mon, Dec 21, 2020 at 4:52 PM Aleksei Bavshin wrote: On 12/21/20 8:28 AM, Ben Cotton wrote: == Documentation == https://www.freedesktop.org/software/systemd/man/systemd-oomd.html https://www.freedesktop.org/software/systemd/man/oomctl.html https://www.freedesktop.org/software/systemd/man/oomd.conf.html Be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). If you're using a desktop environment like GNOME, it already spawns many session components with the systemd user manager. This makes me slightly very concerned. According to cgls, I have most of the apps running directly under user-$UID.slice -> session-X.scope. That includes a compositor (sway) and a few applications that consume uncomfortably close to 100% of available memory (firefox, thunderbird, clangd, gcc, etc...). My understanding is that unless I configure all of the above to run under dedicated scopes, an attempt to run a memory-intensive task would make systemd-oomd terminate the whole user slice with all my apps. Is there anything that could be improved for that scenario? I don't expect that all our desktop users would start using `systemd-run --scope --user` to launch their applications. My understanding is that we intend to do exactly that for you automatically when you open an application through a desktop file. So it should be fine from that perspective. Should I mention that this is happening not in GNOME and neither make nor vim are using desktop files to start subprocesses? And there are dozens of application launchers in Fedora repositories that aren't aware of systemd or cgroups. I'm raising that point because I'd like to have at least a set of recommendations for any alternative environments. So far it seems like the impact outside of major DEs and standard desktop workflows wasn't considered. Don't take this as an antagonism to the proposal, I see the benefits of systemd-oomd and will likely use it myself with a few shell aliases, patches and config changes. It's just that as a maintainer of one of those alternative desktop environments I have no idea how to make that work in default configuration. -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 1:51 pm, Aleksei Bavshin wrote: This makes me slightly very concerned. According to cgls, I have most of the apps running directly under user-$UID.slice -> session-X.scope. That includes a compositor (sway) and a few applications that consume uncomfortably close to 100% of available memory (firefox, thunderbird, clangd, gcc, etc...). Hm good point. I think only GNOME and KDE create systemd scopes when launching apps; systemd-oomd is not going to work well in other desktops. Probably other desktop spins should opt-out of this change for now. Michael ___ 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: TBB soname bump
* Jerry James: > Yes, only libtbb itself changed soname. Upstream has removed a number > of deprecated interfaces, including the task class. That removal > breaks quite a few Fedora packages. I will not update right away. We > will have to decide how to deal with the breakage. In the short term, > I suspect we will have to either make a compatibility tbb package for > packages that cannot update yet, or patch the removed interfaces back > in. > > More information about the deprecation can be found here: > - https://github.com/oneapi-src/oneTBB/issues/243 > - > https://www.threadingbuildingblocks.org/docs/help/reference/appendices/deprecated_features/outdated_and_redundant.html Thanks. To be honest, creating a custom Fedora version of tbb that does not match neither the old nor the new version does not sound particularly attractive. > Any advice on how to proceed will be gratefully received. Regards, We need a compatibility package for downstream use anyway (although probably only for supporting existing binaries, not for building new things). That is, if the transition happens for Fedora 34. I expect Thomas Rodgers will contact you about this topic in the new year. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 4:52 PM Aleksei Bavshin wrote: > > > > On 12/21/20 8:28 AM, Ben Cotton wrote: > > == Documentation == > > > > https://www.freedesktop.org/software/systemd/man/systemd-oomd.html > > https://www.freedesktop.org/software/systemd/man/oomctl.html > > https://www.freedesktop.org/software/systemd/man/oomd.conf.html > > > Be aware that if you intend to enable monitoring and actions on user.slice, > > user-$UID.slice, or their ancestor cgroups, it is highly recommended that > > your programs be managed by the systemd user manager to prevent running too > > many processes under the same session scope (and thus avoid a situation > > where memory intensive tasks trigger systemd-oomd to kill everything under > > the cgroup). If you're using a desktop environment like GNOME, it already > > spawns many session components with the systemd user manager. > > This makes me slightly very concerned. According to cgls, I have most of > the apps running directly under user-$UID.slice -> session-X.scope. That > includes a compositor (sway) and a few applications that consume > uncomfortably close to 100% of available memory (firefox, thunderbird, > clangd, gcc, etc...). > > My understanding is that unless I configure all of the above to run > under dedicated scopes, an attempt to run a memory-intensive task would > make systemd-oomd terminate the whole user slice with all my apps. > > Is there anything that could be improved for that scenario? I don't > expect that all our desktop users would start using `systemd-run --scope > --user` to launch their applications. > My understanding is that we intend to do exactly that for you automatically when you open an application through a desktop file. So it should be fine from that perspective. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On 12/21/20 8:28 AM, Ben Cotton wrote: == Documentation == https://www.freedesktop.org/software/systemd/man/systemd-oomd.html https://www.freedesktop.org/software/systemd/man/oomctl.html https://www.freedesktop.org/software/systemd/man/oomd.conf.html Be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). If you're using a desktop environment like GNOME, it already spawns many session components with the systemd user manager. This makes me slightly very concerned. According to cgls, I have most of the apps running directly under user-$UID.slice -> session-X.scope. That includes a compositor (sway) and a few applications that consume uncomfortably close to 100% of available memory (firefox, thunderbird, clangd, gcc, etc...). My understanding is that unless I configure all of the above to run under dedicated scopes, an attempt to run a memory-intensive task would make systemd-oomd terminate the whole user slice with all my apps. Is there anything that could be improved for that scenario? I don't expect that all our desktop users would start using `systemd-run --scope --user` to launch their applications. -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital 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
Flint soname bump
Greetings all, Flint 2.7.0 is out and has bumped the soname. In about a week, I will build it and rebuild all dependent packages, namely: - antic - arb - e-antic - eclib - normaliz - polymake - pynac - sagemath - Singular Regards, -- Jerry James http://www.jamezone.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: TBB soname bump
I'm very sorry for the delay, Florian. I got buried under $DAYJOB work that had to be done before everybody disappeared for Christmas, and have let Fedora slide. I'm catching up now. On Wed, Dec 9, 2020 at 1:51 PM Florian Weimer wrote: > Which parts changed soname? Only libtbb.so.12 (from libtbb.so.2)? > Do you know why? Yes, only libtbb itself changed soname. Upstream has removed a number of deprecated interfaces, including the task class. That removal breaks quite a few Fedora packages. I will not update right away. We will have to decide how to deal with the breakage. In the short term, I suspect we will have to either make a compatibility tbb package for packages that cannot update yet, or patch the removed interfaces back in. More information about the deprecation can be found here: - https://github.com/oneapi-src/oneTBB/issues/243 - https://www.threadingbuildingblocks.org/docs/help/reference/appendices/deprecated_features/outdated_and_redundant.html Any advice on how to proceed will be gratefully received. Regards, -- Jerry James http://www.jamezone.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: List of long term FTBFS packages to be retired in February
On Mon, 21 Dec 2020 at 15:10, Miro Hrončok wrote: > Dear maintainers. > > Based on the current fail to build from source policy, the following > packages > will be retired from Fedora 34 approximately one week before branching > (February > 2021). > > Policy: > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > Note that some listed packages are orphaned and hence may be retired even > sooner. > > The packages in rawhide were not successfully built at least since Fedora > 32. > > This report is based on dist tags. > > Packages collected via: > > https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb > > If you see a package that was built, please let me know. > If you see a package that should be exempted from the process, please let > me > know and we can work together to get a FESCo approval for that. > > If you see a package that can be rebuilt, please do so. > > Package (co)maintainers Latest > build > > === > VirtualGL gsgatlin Fedora > 31 > > If there are no takers, I would be interested in VirtualGL. Cheers, 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: auditd spamming of dmesg
On Mon, 2020-12-21 at 12:14 -0600, Richard Shaw wrote: > It looks like this has been a problem for a while but I only just now > noticed. > Is it really necessary to have all the audit: messages in dmesg? It > makes it nearly unreadable. I revisited https://bugzilla.redhat.com/show_bug.cgi?id=1227379 , you have two options auditctl -e 0 or audit=0 on boot kernel command line and since sydtemd v246 [1] you may have the solution but I haven't tested yet [1] https://github.com/eworm-de/systemd/commit/511e03a3eedb7613beb0ba59f98fdc1dd753aced > Thanks, > Richard > > ___devel mailing list -- > devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 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
HEADS UP -- Hydrogen SONAME bump
Hi, I'm updating Hydrogen drum machine to the latest version in rawhide. It bumps SONAME in libhydrogen-core.so To my knowledge nothing requires this library, it seems an internal use only lib. Ciao Guido FAS: tartina 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
Non-responsive maintainer check for slaanesh
Hello all, given the lack of any response over a timeframe of 1+ months at https://bugzilla.redhat.com/show_bug.cgi?id=1896375 for libtelnet, I am hereby starting (as suggested by Stephen Smoogen at Freenode IRC #fedora-apps) week #0 of https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ via https://bugzilla.redhat.com/show_bug.cgi?id=1909867 now. As part of the process: Does anyone know how to contact the maintainer using other ways? Thank you. Regards, Robert pgpZa5y1Ws8eb.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
[Bug 1909861] New: perl-Date-HolidayParser-0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909861 Bug ID: 1909861 Summary: perl-Date-HolidayParser-0.43 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Date-HolidayParser 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: 0.43 Current version/release in rawhide: 0.41-22.fc33 URL: http://search.cpan.org/dist/Date-HolidayParser/ 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/7053/ -- 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 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 2:35 PM Anita Zhang wrote: > > I think so. I designed the systemd-oomd interface to be general enough to > eventually support sending d-bus signals in addition to or in place of > killing cgroups with SIGKILL. But I'm uncertain if it can be implemented > before the freeze. We don't have this implemented with earlyoom today, so no worries. It just would have been very helpful to have it since it makes things nicer for Flatpaks and such. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, 2020-12-21 at 12:44 -0600, Michael Catanzaro wrote: > On Mon, Dec 21, 2020 at 9:59 am, Davide Cavalca via devel > wrote: > > We had thought about that, but one concern was migrating custom > > configuration that one might have for earlyoom, which could be > > tricky. > > If we're ok with unconditionally migrating to oomd with its default > > config, that should be pretty straightforward to do. > > Yup, that's fine. It's expected that custom configuration goes away > during a major architectural change like this. > In that case we should document how to preserve earlyoom in the F34 release notes, similar to how we have documentation on how to opt out of systemd-resolved: have a systemd preset that explicitly enables earlyoom and disables oomd. And update the Change Proposal to include modifying the default presets? -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 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: auditd spamming of dmesg
On Mon, Dec 21, 2020 at 1:43 PM Gary Buhrmaster wrote: > On Mon, Dec 21, 2020 at 7:25 PM Richard Shaw wrote: > > > I would say so... > > > > $ dmesg | grep -c audit > > 767 > > > > $ dmesg | grep -cv audit > > 30 > > > > You will likely have to share some of the audit > entries. > I don't want to paste too much of that, but based on skimming through they almost all seem to be about ssh connections, which I don't think belong in dmesg at all... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: auditd spamming of dmesg
On Mon, Dec 21, 2020 at 7:25 PM Richard Shaw wrote: > I would say so... > > $ dmesg | grep -c audit > 767 > > $ dmesg | grep -cv audit > 30 > You will likely have to share some of the audit entries. That last time I recall seeing so many audit entries in dmesg I had set selinux to be permissive, and (due to other changes) had not relabeled a filesystem, resulting in a lot of audit messages. ___ 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 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
I think so. I designed the systemd-oomd interface to be general enough to eventually support sending d-bus signals in addition to or in place of killing cgroups with SIGKILL. But I'm uncertain if it can be implemented before the freeze. ___ 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
Review request/swap: python-subprocess-tee
Hi, This package is a new dependency of python-molecule. Can someone take a look and review it please. https://bugzilla.redhat.com/show_bug.cgi?id=1901747 Happy to review in exchange. -- *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: auditd spamming of dmesg
On Mon, Dec 21, 2020 at 12:54 PM Alexander Ploumistos < alex.ploumis...@gmail.com> wrote: > Hello Richard, > > Right after logging in (and starting Firefox), dmesg returns 1176 > lines, of which 25 are audit messages. It's pretty much the same ratio > on a second desktop and slightly higher (46/724) on a server running > multiple services, but I would call neither nearly unreadable. Are you > seeing something different? Maybe there's some other issue? > I would say so... $ dmesg | grep -c audit 767 $ dmesg | grep -cv audit 30 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: full file paths in the dependency metadata [was Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)]
On Mon, Dec 21, 2020 at 2:14 PM Matthew Miller wrote: > > On Mon, Dec 21, 2020 at 01:47:19PM -0500, Neal Gompa wrote: > > As someone who has to package for multiple distributions, I would > > oppose any attempt to cripple DNF to stop supporting file dependencies > > properly. I *aggressively* use file dependencies to avoid having to > > litter my spec files with package name dependencies across RH/Fedora, > > SUSE, Mandriva/Mageia, and others. > > Do you have examples outside of /etc, /usr/bin, /usr/sbin? > Mostly stuff in /usr/libexec and /usr/lib(64). > Also, if you _are_ using arbitrary file dependencies, that renders the other > part about opportunistic download of these deps kind of moot, since they'll > have to be frequently, right? > For packages I maintain in Fedora *itself*, I don't need to do this, but for packages I maintain *outside* of Fedora, I *must*. > Again, I'm not kidding about 95% of the dep points being filenames. It's > huge! I don't think that's a good price at all to make everyone pay > constantly for packaging convenience. Better to convince packagers to put in > cross-distro "Provides" or something. > Yes, I know. I've looked at the metadata myself before... The fact that I can't get openSUSE to properly fully enable the Python module dependency generator (that I maintain upstream in rpm!) after almost two years of trying should be indication enough of how difficult what you're asking really is. -- 真実はいつも一つ！/ 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: full file paths in the dependency metadata [was Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)]
On Mon, Dec 21, 2020 at 01:47:19PM -0500, Neal Gompa wrote: > As someone who has to package for multiple distributions, I would > oppose any attempt to cripple DNF to stop supporting file dependencies > properly. I *aggressively* use file dependencies to avoid having to > litter my spec files with package name dependencies across RH/Fedora, > SUSE, Mandriva/Mageia, and others. Do you have examples outside of /etc, /usr/bin, /usr/sbin? Also, if you _are_ using arbitrary file dependencies, that renders the other part about opportunistic download of these deps kind of moot, since they'll have to be frequently, right? Again, I'm not kidding about 95% of the dep points being filenames. It's huge! I don't think that's a good price at all to make everyone pay constantly for packaging convenience. Better to convince packagers to put in cross-distro "Provides" or something. -- 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: Upcoming Fedora 34 deadlines
As a reminder, Fedora 34 Change proposals for System-Wide Changes or Changes requiring a mass rebuild are due on Tuesday 29 December. Self-contained Change proposals are due on 19 January. The full Fedora 34 schedule is on Fedora People: https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html I will be out of the office from 23 December until 4 January. I will check email and look for submitted proposals occasionally, but if you have a pressing question, please ping me on IRC (bcotton)/Matrix (@funnelfiasco:matrix.org). -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-annou...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upcoming Fedora 34 deadlines
As a reminder, Fedora 34 Change proposals for System-Wide Changes or Changes requiring a mass rebuild are due on Tuesday 29 December. Self-contained Change proposals are due on 19 January. The full Fedora 34 schedule is on Fedora People: https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html I will be out of the office from 23 December until 4 January. I will check email and look for submitted proposals occasionally, but if you have a pressing question, please ping me on IRC (bcotton)/Matrix (@funnelfiasco:matrix.org). -- 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
Re: auditd spamming of dmesg
Hello Richard, Right after logging in (and starting Firefox), dmesg returns 1176 lines, of which 25 are audit messages. It's pretty much the same ratio on a second desktop and slightly higher (46/724) on a server running multiple services, but I would call neither nearly unreadable. Are you seeing something different? Maybe there's some other issue? ___ 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 1909829] New: perl-ExtUtils-MakeMaker-7.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909829 Bug ID: 1909829 Summary: perl-ExtUtils-MakeMaker-7.58 is available Product: Fedora Version: rawhide Status: NEW Component: perl-ExtUtils-MakeMaker Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 7.58 Current version/release in rawhide: 7.56-1.fc34 URL: http://search.cpan.org/dist/ExtUtils-MakeMaker/ 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/2867/ -- 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: full file paths in the dependency metadata [was Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)]
On Mon, Dec 21, 2020 at 1:42 PM Matthew Miller wrote: > > On Mon, Dec 21, 2020 at 07:14:08PM +0100, Marius Schwarz wrote: > > delta rpms safe so much time in form of bandwidth on the client side. > > If something really needs to change, it is the 50+ MB repo database > > that gets downloaded. It takes ages on slow connections to download > > This needs a followup. I didn't push on it because the DNF team was > super-busy with modularity, but if someone wants to pick this up, it'd be a > significant improvement: > > https://pagure.io/packaging-committee/issue/714 > > In short, 95% of the dependency data is full filename paths. That's not > hyperbole. It's literally 95% by count. Actually probably even more by > _space_ since they tend to be long. > > Only a tiny fraction of packages use these at all, and almost all of the > packages using file deps outside of /usr/bin, /usr/sbin, or /etc could use > something else — and of the few using something else, many are actually > doing so only in error. > > It remains convenient to be able to do > >dnf install /usr/share/fonts/jetbrains-mono-fonts/JetBrainsMono-Regular.ttf > > or whatever, but that seems like it could be covered by a DNF plugin. > > Previously, there was a chicken-and-egg scenario where the DNF folks didn't > want to touch this while people were still making packages relying on this > feature, but since 2018 that's a "SHOULD NOT" in the guidelines. So, I > think there's room to move forward, should anyone like to take this on. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies > The main problem is that wiring libsolv to callback to opportunistically fetch and repopulate the solver cache has not been figured out for libdnf. Once we do that, we don't need to do any more work. Most cases will automatically only fetch primary.xml and filelists.xml will only be fetched as requested. This is the behavior that YUM v3 had, and it wasn't ported to DNF because we lacked a mechanism to do this. In *theory*, such a mechanism exists now in libsolv, though the API is sufficiently confusing that I'm not sure how to do it exactly. As someone who has to package for multiple distributions, I would oppose any attempt to cripple DNF to stop supporting file dependencies properly. I *aggressively* use file dependencies to avoid having to litter my spec files with package name dependencies across RH/Fedora, SUSE, Mandriva/Mageia, and others. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Monday, December 21, 2020 11:28:51 AM EST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/RPMCoW [snip] > # The file format for RPMs is different with Copy on Write. The > headers are identical, but the payload is different. There is also a > footer. > ## Files are converted (“transcoded”) locally during download using > /usr/bin/rpm2extents (part of rpm codebase). The format > is not intended to be “portable” - i.e. copying the files from the > cache is not supported. I currently download once and upgrade three different systems by rsync-ing the cache. Do I understand that this will no longer be supported or work? -- Garry T. Williams ___ 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020, at 1:07 PM, Neal Gompa wrote: > > Sure, this makes some degree of sense, but it doesn't reduce the IOPS > for actually *doing* the installation. Yes it does. It avoids writing the compressed data and then copying it back out uncompressed, which is the same amount of savings as the reflink approach. (It's also equally incompatible with deltarpm) > This is also a flaw with RPM-OSTree, since you have to fetch > everything individually No - static deltas exist, plus layered RPMs work on the wire the same. But this isn't really relevant here. > and construct the root by shifting hardlinks > or reflinks around. Adding a hardlink indeed requires updating inodes proportional to the number of files, but that's more an implementation of the transactional update approach, not of the "download and unpack in parallel" part which is more what we're discussing here. (Though they are entangled a bit) Anyways, I'd still stand by my summary that the much lower tech "files in temporary directory that get rename()d" approach would be all of *more* efficient on disk, simpler to implement and much less disruptive than an RPM format change. (The main cost would be a new temporary directory path that would need cleanup as part of e.g. `yum clean` etc.) ___ 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 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 9:59 am, Davide Cavalca via devel wrote: We had thought about that, but one concern was migrating custom configuration that one might have for earlyoom, which could be tricky. If we're ok with unconditionally migrating to oomd with its default config, that should be pretty straightforward to do. Yup, that's fine. It's expected that custom configuration goes away during a major architectural change like this. ___ 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
full file paths in the dependency metadata [was Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)]
On Mon, Dec 21, 2020 at 07:14:08PM +0100, Marius Schwarz wrote: > delta rpms safe so much time in form of bandwidth on the client side. > If something really needs to change, it is the 50+ MB repo database > that gets downloaded. It takes ages on slow connections to download This needs a followup. I didn't push on it because the DNF team was super-busy with modularity, but if someone wants to pick this up, it'd be a significant improvement: https://pagure.io/packaging-committee/issue/714 In short, 95% of the dependency data is full filename paths. That's not hyperbole. It's literally 95% by count. Actually probably even more by _space_ since they tend to be long. Only a tiny fraction of packages use these at all, and almost all of the packages using file deps outside of /usr/bin, /usr/sbin, or /etc could use something else — and of the few using something else, many are actually doing so only in error. It remains convenient to be able to do dnf install /usr/share/fonts/jetbrains-mono-fonts/JetBrainsMono-Regular.ttf or whatever, but that seems like it could be covered by a DNF plugin. Previously, there was a chicken-and-egg scenario where the DNF folks didn't want to touch this while people were still making packages relying on this feature, but since 2018 that's a "SHOULD NOT" in the guidelines. So, I think there's room to move forward, should anyone like to take this on. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies -- 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: What is the most time consuming task for you as packager?
On Thu, Dec 17, 2020 at 09:21:15PM +0100, Fabio Valentini wrote: > As Miro mentioned, I've also developed scripts to handle this "does > this update break anything" for the Stewardship / Java SIG, because - > at least at first - we didn't have big enough egos / enough confidence > to just push updates to rawhide without testing excessively them > first: > https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py > > This first builds (one or more) packages from src.fpo dist-git forks > that were prepared for PRs in COPR, recursively or non-recursively > queries dependent packages for all of them, and rebuilds them in COPR. > Assuming that there's a copr-cli command for querying build successes, > they could be compared with the latest status of those packages in > koschei, and have it print new build failures. Right now, I compare > the results manually. > > Would something like this fit your definition of "does-it-blend" script? What format is '--from-git' in? Say I have a fork with a branch I want to test, what do I pass it? This is indeed the sort of thing I was thinking of (I think). kevin 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
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 1:14 PM Marius Schwarz wrote: > > Am 21.12.20 um 18:53 schrieb Kevin Fenzi: > > But in general perhaps we should decide how much value drpms provide > > these days and either make sure we are making more of them, or drop > > them. > delta rpms safe so much time in form of bandwidth on the client side. > > If something really needs to change, it is the 50+ MB repo database that > gets downloaded. It takes ages on slow connections to download > and than you want to increase the size of the rpms too.. Doesn't sound > like a good idea. > You should be getting delta fetching of repository metadata with zchunk metadata, which we've had enabled since Fedora 30: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata Is this not working for you or something? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 01:07:42PM -0500, Neal Gompa wrote: > As an aside, I *really* hate this split of terminology we have among > Editions, Spins, and Labs. It's confusing to everyone. :( The website hasn't been changed, but officially all of these are Fedora Solutions, with only Editions being a special case. Other outputs can call themselves Spin, Lab, Image, or whatever, as they like for their own marketing. https://docs.fedoraproject.org/en-US/council/policy/guiding-policy/#_what_does_this_mean -- 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
auditd spamming of dmesg
It looks like this has been a problem for a while but I only just now noticed. Is it really necessary to have all the audit: messages in dmesg? It makes it nearly unreadable. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 12:59 PM Davide Cavalca via devel wrote: > > On Mon, 2020-12-21 at 10:57 -0600, Michael Catanzaro wrote: > > On Mon, Dec 21, 2020 at 11:28 am, Ben Cotton > > wrote: > > > == Upgrade/compatibility impact == > > > > > > Existing systems running earlyoom will not be modified. One can > > > transition to systemd-oomd via: > > > > > > sudo systemctl disable --now earlyoom > > > sudo systemctl enable --now systemd-oomd > > > Systems that were previously not running earlyoom will have > > > systemd-oomd enabled by default. > > > > I suggest we enable systemd-oomd for everyone on upgrade, to follow > > our > > design goal of ensuring upgraded systems match fresh installs as > > closely as practical. > > We had thought about that, but one concern was migrating custom > configuration that one might have for earlyoom, which could be tricky. > If we're ok with unconditionally migrating to oomd with its default > config, that should be pretty straightforward to do. > I think I'd rather unconditionally just move everything to oomd. It's easier to focus on shoring up the experience with oomd than to worry about earlyoom vs oomd experiences forever. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
Am 21.12.20 um 18:53 schrieb Kevin Fenzi: But in general perhaps we should decide how much value drpms provide these days and either make sure we are making more of them, or drop them. delta rpms safe so much time in form of bandwidth on the client side. If something really needs to change, it is the 50+ MB repo database that gets downloaded. It takes ages on slow connections to download and than you want to increase the size of the rpms too.. Doesn't sound like a good idea. best regards, Marius Schwarz ___ 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 12:49 PM Colin Walters wrote: > > > > On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote: > > > > > > > > == Summary == > > > > RPM Copy on Write provides a better experience for Fedora Users as it > > reduces the amount of I/O and offsets CPU cost of package > > decompression. RPM Copy on Write uses reflinking capabilities in > > btrfs, which is the default filesystem in Fedora 33. > > A bunch of points here: > > - No, it's the default for one Edition. Others don't default to it. And > even for Workstation we can't *require* it because it's definitely supported > to use other filesystems and storage layouts. > > - Orthogonal to this, I'd also note that xfs supports reflinks too. > > Combining those I'd say instead e.g.: "Most Fedora Editions default to a > filesystem that support reflinks, e.g. btrfs or xfs" (actually I think IoT > defaults to ext4 for...probably they didn't consider it?) > It'd be more accurate to say most Fedora variants default to Btrfs. The only exceptions right now are Cloud, Server, and CoreOS. But yes, Fedora Server's current default of XFS on LVM means it also supports reflinks. As an aside, I *really* hate this split of terminology we have among Editions, Spins, and Labs. It's confusing to everyone. :( > - When talking about RPMs we need to think about container images, which use > overlayfs by default, which defers to the underlying filesystem for reflinks > - so should be fine, but should be explicitly written down (and tested) > > - Generally incompatible RPM payload changes cause pain proportional to how > far they're "not backported", e.g. if support for this isn't in Fedora N-1 > (e.g. Fedora 32) it will be harder for current Koji/mock model. Nowadays > many more people use podman than mock, which e.g. if using a RHEL8 host will > naturally avoid the dependency on an updated RPM. But > Incomplete statement here? That said, we don't have a problem in the Koji/Mock model anymore, as bootstrap mode is now activated. Additionally, Mock uses systemd-nspawn by default for all cases except for with Koji (which overrides this because it can't handle nspawn mode at the moment). > > # Decompression happens inline with download. > > rpm-ostree does this by default today BTW (rpms are unpacked into local > ostree commits in parallel even). > > > ## Regular RPMs use a compressed .cpio based payload. In contrast, > > extent based RPMs contain uncompressed data aligned to the fundamental > > page size of the architecture, e.g. 4KiB on x86_64. This alignment is > > required for FICLONERANGE to work. Only files are > > represented in the payload, other directory entries like symlinks, > > device nodes etc are constructed entirely from rpm header information. > > This is the core change; some interesting tradeoffs here. Python projects in > particular ship a lot of files smaller than 4k (classic example is > `__init__.py` which is zero sized). And ppc64le is 64KiB pages right? So > there will be "zero space" to align, right? Would need some math to see how > much this would add up to, although I guess the implementation could instead > use holes? > > > Files are referenced by their digest, so identical files are > > de-duplicated. > > But just inside a single RPM, right? It's interesting to compare with ostree > which does this by default; conceptually this is using reflinks inside a > single RPM to do what ostree does system wide with hardlinks. > > BTW we learned a few things, notably zero sized files are tricky because > there can be a *lot* of them - see e.g. > https://github.com/ostreedev/ostree/pull/2197 > That one was too many hardlinks, but how well do filesystems like btrfs/xfs > handle thousands of reflinks instead? The Python __init__.py thing is such a > pathological case... > > > # Disk space requirements are expected to be marginally higher than > > before: all new packages or updates will consume their installed size > > before installation instead of about half their size (regular rpms > > with payloads still cost space). > > This won't matter much for small updates but could be quite noticeable for > larger system upgrades. > > This all said the more I think about this, wouldn't it be way simpler to > change rpm to support a "temporary root directory", e.g. `/usr/.rpmtemp` or > whatever. Then dnf/zypper/etc cam do the unpack-and-download model without > any format changes to RPM - instead of reflinking it'd just be rename() into > place. This is effectively what rpm-ostree is doing today except with ostree > commits instead of a temporary directory. Sure, this makes some degree of sense, but it doesn't reduce the IOPS for actually *doing* the installation. My understanding is that this Change is intended to reduce the thrashing when doing package transactions. This is also a flaw with RPM-OSTree, since you have to fetch everything individually and construct the root by shifting hardlinks or reflinks
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, 2020-12-21 at 10:57 -0600, Michael Catanzaro wrote: > On Mon, Dec 21, 2020 at 11:28 am, Ben Cotton > wrote: > > == Upgrade/compatibility impact == > > > > Existing systems running earlyoom will not be modified. One can > > transition to systemd-oomd via: > > > > sudo systemctl disable --now earlyoom > > sudo systemctl enable --now systemd-oomd > > Systems that were previously not running earlyoom will have > > systemd-oomd enabled by default. > > I suggest we enable systemd-oomd for everyone on upgrade, to follow > our > design goal of ensuring upgraded systems match fresh installs as > closely as practical. We had thought about that, but one concern was migrating custom configuration that one might have for earlyoom, which could be tricky. If we're ok with unconditionally migrating to oomd with its default config, that should be pretty straightforward to do. 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: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, 2020-12-21 at 18:00 +0100, Tomasz Torcz wrote: > On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/RPMCoW > > # dnf-plugin-reflink (a new package): > > https://github.com/facebookincubator/dnf-plugin-cow/ > > Does not exists, but I've just noticed it mentioned in Current > Status > on Wiki: > 3.2 Github repo needs to be published Yeah, apologies for that, we wanted to get the Change proposal out asap to start the discussion and gather feedback, but a few of the pieces are still in the works. Specifically, the repo is currently pending internal review and should be out soon. 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: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
Cool. A few questions inline... On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/RPMCoW > > > == Summary == > > RPM Copy on Write provides a better experience for Fedora Users as it > reduces the amount of I/O and offsets CPU cost of package > decompression. RPM Copy on Write uses reflinking capabilities in > btrfs, which is the default filesystem in Fedora 33. What happens if you enable this on non btrfs installs? Does it just not work gracefully? Does it fail somehow? I think we need to be sure it doesn't actually do anything bad for other non CoW filesystems. ...snip... > ### Signature 8 bytes at the end of the file, used to differentiate > between traditional RPMs and extent based. So, there's no change to rpm building or signing, as all thats done in transcoding them on download? > === Notes === > > # The headers are preserved bit for bit during transcoding. This > preserves signatures. The signatures cover the main header blob, and > the main header blob ensures the integrity of data in two ways: > ## Each file with content has a digest. Originally this was md5, but > today it’s usually sha256. In normal RPM this is only used to verify > the integrity of files, e.g. rpm -V. With CoW we use this > as a content key. > ## There is/are one or two digests (PAYLOADDIGEST and > PAYLOADDIGESTALT) covering the payload archive > (compressed cpio). The header value is preserved, but transcoded RPMs > do not preserve the original structure so RPM’s pre-installation > verification (controlled by %_pkgverify_level will fail. > dnf-plugin-cow disables this check in dnf because it > verifies the whole file digest which is captured during Could rpm learn about this and still do it's verify in this case? > download/transcoding. The second one is likely used for delta rpm. > # This is untested, and possibly incompatible with delta RPM (drpm). > The process for reconstructing an rpm to install from a delta is > expensive from both a CPU and I/O perspective, while only providing > marginal benefits on download size. It is expected that having delta > rpm enabled (which is the default) will be handled gracefully. I imagine drpms could still be used, just once you have constructed the final rpm, you transcode it as if you just downloaded it? But in general perhaps we should decide how much value drpms provide these days and either make sure we are making more of them, or drop them. ...snip... > === Performance Metrics === > > Ballpark performance difference is about half the duration for file > download+install time. A lot of rpms are very small, so it’s difficult > to see/measure. Larger RPMs give much clearer signal. > > (Actual numbers/charts will be supplied in Jan 2021) Nice! kevin 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
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote: > > > > == Summary == > > RPM Copy on Write provides a better experience for Fedora Users as it > reduces the amount of I/O and offsets CPU cost of package > decompression. RPM Copy on Write uses reflinking capabilities in > btrfs, which is the default filesystem in Fedora 33. A bunch of points here: - No, it's the default for one Edition. Others don't default to it. And even for Workstation we can't *require* it because it's definitely supported to use other filesystems and storage layouts. - Orthogonal to this, I'd also note that xfs supports reflinks too. Combining those I'd say instead e.g.: "Most Fedora Editions default to a filesystem that support reflinks, e.g. btrfs or xfs" (actually I think IoT defaults to ext4 for...probably they didn't consider it?) - When talking about RPMs we need to think about container images, which use overlayfs by default, which defers to the underlying filesystem for reflinks - so should be fine, but should be explicitly written down (and tested) - Generally incompatible RPM payload changes cause pain proportional to how far they're "not backported", e.g. if support for this isn't in Fedora N-1 (e.g. Fedora 32) it will be harder for current Koji/mock model. Nowadays many more people use podman than mock, which e.g. if using a RHEL8 host will naturally avoid the dependency on an updated RPM. But > # Decompression happens inline with download. rpm-ostree does this by default today BTW (rpms are unpacked into local ostree commits in parallel even). > ## Regular RPMs use a compressed .cpio based payload. In contrast, > extent based RPMs contain uncompressed data aligned to the fundamental > page size of the architecture, e.g. 4KiB on x86_64. This alignment is > required for FICLONERANGE to work. Only files are > represented in the payload, other directory entries like symlinks, > device nodes etc are constructed entirely from rpm header information. This is the core change; some interesting tradeoffs here. Python projects in particular ship a lot of files smaller than 4k (classic example is `__init__.py` which is zero sized). And ppc64le is 64KiB pages right? So there will be "zero space" to align, right? Would need some math to see how much this would add up to, although I guess the implementation could instead use holes? > Files are referenced by their digest, so identical files are > de-duplicated. But just inside a single RPM, right? It's interesting to compare with ostree which does this by default; conceptually this is using reflinks inside a single RPM to do what ostree does system wide with hardlinks. BTW we learned a few things, notably zero sized files are tricky because there can be a *lot* of them - see e.g. https://github.com/ostreedev/ostree/pull/2197 That one was too many hardlinks, but how well do filesystems like btrfs/xfs handle thousands of reflinks instead? The Python __init__.py thing is such a pathological case... > # Disk space requirements are expected to be marginally higher than > before: all new packages or updates will consume their installed size > before installation instead of about half their size (regular rpms > with payloads still cost space). This won't matter much for small updates but could be quite noticeable for larger system upgrades. This all said the more I think about this, wouldn't it be way simpler to change rpm to support a "temporary root directory", e.g. `/usr/.rpmtemp` or whatever. Then dnf/zypper/etc cam do the unpack-and-download model without any format changes to RPM - instead of reflinking it'd just be rename() into place. This is effectively what rpm-ostree is doing today except with ostree commits instead of a temporary directory. ___ 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 11:58 AM Michael Catanzaro wrote: > > > On Mon, Dec 21, 2020 at 11:39 am, Neal Gompa wrote: > > This is very exciting! There is one thing, though: we need a libdnf > > plugin for PackageKit to use too. "DNF plugins" are at the Python > > layer, and libdnf has its own plugin system that C/C++ consumers can > > use. So if both a libdnf and a dnf plugin exist, then the experience > > is consistent between PK and DNF. > > > > But that leads to my other question: why not just integrate this into > > libdnf and turn it into an option that can be activated in > > /etc/dnf/dnf.conf? That seems to be the most straightforward way to do > > this. > > From the change proposal: > > # Current implementation of dnf-plugin-cow is in Python, > but it looks possible to implement this in libdnf instead > which would make it work in packagekit > Gah! I missed that. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/RPMCoW > # dnf-plugin-reflink (a new package): > https://github.com/facebookincubator/dnf-plugin-cow/ Does not exists, but I've just noticed it mentioned in Current Status on Wiki: 3.2 Github repo needs to be published -- Tomasz Torcz “If you try to upissue this patchset I shall be seeking to...@pipebreaker.pl an IP-routable hand grenade.” — Andrew Morton (LKML) ___ 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 11:39 am, Neal Gompa wrote: This is very exciting! There is one thing, though: we need a libdnf plugin for PackageKit to use too. "DNF plugins" are at the Python layer, and libdnf has its own plugin system that C/C++ consumers can use. So if both a libdnf and a dnf plugin exist, then the experience is consistent between PK and DNF. But that leads to my other question: why not just integrate this into libdnf and turn it into an option that can be activated in /etc/dnf/dnf.conf? That seems to be the most straightforward way to do this. From the change proposal: # Current implementation of dnf-plugin-cow is in Python, but it looks possible to implement this in libdnf instead which would make it work in packagekit ___ 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 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 11:28 am, Ben Cotton wrote: == Upgrade/compatibility impact == Existing systems running earlyoom will not be modified. One can transition to systemd-oomd via: sudo systemctl disable --now earlyoom sudo systemctl enable --now systemd-oomd Systems that were previously not running earlyoom will have systemd-oomd enabled by default. I suggest we enable systemd-oomd for everyone on upgrade, to follow our design goal of ensuring upgraded systems match fresh installs as closely as practical. Michael ___ 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On 12/21/20 12:28 PM, Ben Cotton wrote: ... === New process === # Resolve packaging request into a list of packages and operations # Download and '''decompress''' packages into a '''locally optimized''' rpm file # Install and/or upgrade packages sequentially using RPM files, using '''reference linking''' (reflinking) to reuse data already on disk. This sound great because free space requirements can be reduced, specially when installing new packages. I have experimented building very small appliances using btrfs compression on things like /usr/share. So I think this could disrupt this because if I am correct the extends will be first downloaded to a temporary directory without compression enabled. I am happy with an option to disable this behavior. The outcome is intended to be the same, but the order of operations is different. # Decompression happens inline with download. This has a positive effect on resource usage: downloads are typically limited by bandwidth. Decompression and writing the full data into a single file per rpm is essentially free. Additionally: if there is more than one download at a time, a multi-CPU system can be better utilized. All compression types supported in RPM work because this uses the rpm I/O functions. # RPMs are cached on local storage between downloading and installation time as normal. This allows DNF to defer actual RPM installation to when all the RPM are available. This is unchanged. # The file format for RPMs is different with Copy on Write. The headers are identical, but the payload is different. There is also a footer. ## Files are converted (“transcoded”) locally during download using /usr/bin/rpm2extents (part of rpm codebase). The format is not intended to be “portable” - i.e. copying the files from the cache is not supported. ## Regular RPMs use a compressed .cpio based payload. In contrast, extent based RPMs contain uncompressed data aligned to the fundamental page size of the architecture, e.g. 4KiB on x86_64. This alignment is required for FICLONERANGE to work. Only files are represented in the payload, other directory entries like symlinks, device nodes etc are constructed entirely from rpm header information. Files are referenced by their digest, so identical files are de-duplicated. ## The footer currently has three sections ### Table of original (rpm) file digests, used to validate the integrity of the download in dnf. ### Table of digest → offset used when actually installing files. ### Signature 8 bytes at the end of the file, used to differentiate between traditional RPMs and extent based. === Notes === # The headers are preserved bit for bit during transcoding. This preserves signatures. The signatures cover the main header blob, and the main header blob ensures the integrity of data in two ways: ## Each file with content has a digest. Originally this was md5, but today it’s usually sha256. In normal RPM this is only used to verify the integrity of files, e.g. rpm -V. With CoW we use this as a content key. ## There is/are one or two digests (PAYLOADDIGEST and PAYLOADDIGESTALT) covering the payload archive (compressed cpio). The header value is preserved, but transcoded RPMs do not preserve the original structure so RPM’s pre-installation verification (controlled by %_pkgverify_level will fail. dnf-plugin-cow disables this check in dnf because it verifies the whole file digest which is captured during download/transcoding. The second one is likely used for delta rpm. # This is untested, and possibly incompatible with delta RPM (drpm). The process for reconstructing an rpm to install from a delta is expensive from both a CPU and I/O perspective, while only providing marginal benefits on download size. It is expected that having delta rpm enabled (which is the default) will be handled gracefully. # Disk space requirements are expected to be marginally higher than before: all new packages or updates will consume their installed size before installation instead of about half their size (regular rpms with payloads still cost space). # rpm-plugin-reflink will fall back to simple file copying when the destination path is not on the same filesystem/subvolume. A common example is /boot and/or /boot/efi. # The system will still work on other filesystem types, but will ''always'' fall back to simple copying. This is expected to be slightly slower than not enabling CoW because the source for copying will be the decompressed data. # For systems that enable transparent filesystem compression: every file will continue to be decompressed from the original rpm, and then transparently re-compressed by the filesystem. There is no effective change here. There is a future project to investigate alternate distribution mechanics to provide parallel versions of file content pre-compressed in a filesystem specific format, reducing both CPU costs and I/O. It is expected that this will result in slightly higher network utilization because filesystem
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 11:29 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/EnableSystemdOomd > > == Summary == > > Provide a better experience for Fedora users in out-of-memory (OOM) > situations by enabling > [https://www.freedesktop.org/software/systemd/man/systemd-oomd.html > systemd-oomd] by default. Actions taken by systemd-oomd operate on a > per-cgroup level, aligning well with the life cycle of systemd units. > systemd-oomd primarily uses [https://facebookmicrosites.github.io/psi/ > Linux pressure stall information (PSI)] to make decisions based on > wasted productivity due to resource shortages; in addition to that, it > also supports swap based actions. > > == Owners == > > * Name: [[User:anitazha|Anita Zhang]], [[User:Dcavalca|Davide > Cavalca]], [[User:Salimma|Michel Salim]], [[User:Htejun|Tejun Heo]], > [[User:3ki|Rik van Riel]] > * Email: the.anita...@gmail.com, dcava...@fb.com, > mic...@michel-slm.name, hte...@fb.com, r...@fb.com > > > == Detailed description == > > The primary mechanism used by systemd-oomd for detecting when the > system is out of memory is memory pressure. Memory pressure measures > the percentage of time a cgroup has “wasted” due to lack of memory. > This includes time spent reclaiming free memory, faulting in recently > resident pages, and loading in anonymous pages from swap. When a > monitored cgroup’s memory pressure exceeds the specified thresholds, > systemd-oomd will perform action(s) on the targeted cgroup’s > descendants, starting from the cgroups with the most reclaim scans. > Reclaim activity is used here, rather than the largest consumer, as it > reflects values set in the cgroup memory controller for memory > protection (such as memory.low). > > For memory pressure configuration, this will be > ManagedOOMMemoryPressure=kill and ManagedOOMMemoryPressureLimit=4% on > user@.service to have systemd-oomd send SIGKILLs to all processes > under a selected cgroup when total memory pressure on all tasks > exceeds 4% for 10 seconds. > > For swap based actions, systemd-oomd will monitor the system-wide swap > space and act when available swap falls below the configured > threshold, starting with the cgroups with the highest swap usage to > the least. Keeping some amount of swap (if enabled) available will > prevent the kernel OOM killer from killing processes unpredictably and > spending an unbounded amount of time afterwards. > > For swap configuration, this will be SwapUsedLimitPercent=90% in > oomd.conf and ManagedOOMSwap=kill on -.slice (root cgroup slice) to > have systemd-oomd send SIGKILLs to all processes under a cgroup when > swap used exceeds 90%. > > > == Benefit to Fedora == > > * Addressing the issue of improving user feedback in > https://pagure.io/fedora-workstation/issue/202, systemd-oomd currently > logs to the journal if pressure or swap action is about to occur. > There are also debug logs, for each process that is sent a SIGKILL, > that can be bumped up in priority. Further notification mechanisms > (i.e. over dbus) can also be implemented depending on feedback. > * While systemd-oomd is simpler in configuration to the oomd used at > Facebook, the algorithm is largely the same. As such, the following > case study can be used as an example of how PSI and cgroup killing can > release memory not normally resolved with process killing and lead to > better utilization: > https://facebookincubator.github.io/oomd/docs/oomd-casestudy.html > * OOM killing in userspace, before the kernel OOM killer kicks in, has > been shown to be effective at keeping a system functional. An OOM kill > in the kernel is slow, possibly leading to an unbounded amount of time > swapping in and out pages and evicting the page cache. > * PSI based actions, versus looking at raw memory consumption numbers, > better reflect memory protection policies set for cgroup resource > control limits (e.g. memory.low). > > == Scope == > > * Proposal owners: > ** Implement and land additional refinements to systemd-oomd > *** Remove swap as a hard requirement to running systemd-oomd > *** Expand ManagedOOM*= properties to user units (currently only > usable on system units) > *** Configurable memory pressure time window knob > ** Enable oomd by default with sensible configuration > ** Test days > ** Aid with documentation > * Other developers: > ** systemd: review PRs as needed > * Release engineering: https://pagure.io/releng/issue/9913 > * Policies and guidelines: N/A > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > Existing systems running earlyoom will not be modified. One can > transition to systemd-oomd via: > > sudo systemctl disable --now earlyoom > sudo systemctl enable --now systemd-oomd > Systems that were previously not running earlyoom will have > systemd-oomd enabled by default. > > == How to test == > > systemd 247 build for Fedora includes all the artifacts for > systemd-oomd. It is disabled by default but can be started with: > > sudo
Re: Preview appdata file?
gnome-software doesn't ingest the appdata file directly, it is instead looking at bundled data from appstream-builder. I think the local file gnome-software wants to ingest should be created by running appstream-builder on the RPM of the program with your updated appdata file. -Ian On Mon, Dec 21, 2020 at 4:23 PM Richard Shaw wrote: > Well no so fast... I've made a number of changes and it doesn't appear to > show any of them, it's still using data from somewhere other than the local > file. > > This is getting really frustrating. > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 11:29 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/RPMCoW > > > == Summary == > > RPM Copy on Write provides a better experience for Fedora Users as it > reduces the amount of I/O and offsets CPU cost of package > decompression. RPM Copy on Write uses reflinking capabilities in > btrfs, which is the default filesystem in Fedora 33. > > == Owners == > > * Name: [[User:malmond|Matthew Almond]], [[User:dcavalca|Davide Cavalca]] > * Email: malm...@fb.com, dcava...@fb.com > > > == Detailed description == > > Installing and upgrading software packages is a standard part of > managing the lifecycle of any operating system. For the entire > lifecycle of Fedora, all software is packaged and distributed using > the RPM file fomat. This proposal changes how software is downloaded > and installed, leaving the distribution process unmodified. > > === Current process === > > # Resolve packaging request into a list of packages and operations > # Download and verify new packages > # Install and/or upgrade packages sequentially using RPM files, > decompressing, and writing a copy of the new files to storage. > > === New process === > > # Resolve packaging request into a list of packages and operations > # Download and '''decompress''' packages into a '''locally optimized''' rpm > file > # Install and/or upgrade packages sequentially using RPM files, using > '''reference linking''' (reflinking) to reuse data already on disk. > > The outcome is intended to be the same, but the order of operations is > different. > > # Decompression happens inline with download. This has a positive > effect on resource usage: downloads are typically limited by > bandwidth. Decompression and writing the full data into a single file > per rpm is essentially free. Additionally: if there is more than one > download at a time, a multi-CPU system can be better utilized. All > compression types supported in RPM work because this uses the rpm I/O > functions. > # RPMs are cached on local storage between downloading and > installation time as normal. This allows DNF to defer actual RPM > installation to when all the RPM are available. This is unchanged. > # The file format for RPMs is different with Copy on Write. The > headers are identical, but the payload is different. There is also a > footer. > ## Files are converted (“transcoded”) locally during download using > /usr/bin/rpm2extents (part of rpm codebase). The format > is not intended to be “portable” - i.e. copying the files from the > cache is not supported. > ## Regular RPMs use a compressed .cpio based payload. In contrast, > extent based RPMs contain uncompressed data aligned to the fundamental > page size of the architecture, e.g. 4KiB on x86_64. This alignment is > required for FICLONERANGE to work. Only files are > represented in the payload, other directory entries like symlinks, > device nodes etc are constructed entirely from rpm header information. > Files are referenced by their digest, so identical files are > de-duplicated. > ## The footer currently has three sections > ### Table of original (rpm) file digests, used to validate the > integrity of the download in dnf. > ### Table of digest → offset used when actually installing files. > ### Signature 8 bytes at the end of the file, used to differentiate > between traditional RPMs and extent based. > > === Notes === > > # The headers are preserved bit for bit during transcoding. This > preserves signatures. The signatures cover the main header blob, and > the main header blob ensures the integrity of data in two ways: > ## Each file with content has a digest. Originally this was md5, but > today it’s usually sha256. In normal RPM this is only used to verify > the integrity of files, e.g. rpm -V. With CoW we use this > as a content key. > ## There is/are one or two digests (PAYLOADDIGEST and > PAYLOADDIGESTALT) covering the payload archive > (compressed cpio). The header value is preserved, but transcoded RPMs > do not preserve the original structure so RPM’s pre-installation > verification (controlled by %_pkgverify_level will fail. > dnf-plugin-cow disables this check in dnf because it > verifies the whole file digest which is captured during > download/transcoding. The second one is likely used for delta rpm. > # This is untested, and possibly incompatible with delta RPM (drpm). > The process for reconstructing an rpm to install from a delta is > expensive from both a CPU and I/O perspective, while only providing > marginal benefits on download size. It is expected that having delta > rpm enabled (which is the default) will be handled gracefully. > # Disk space requirements are expected to be marginally higher than > before: all new packages or updates will consume their installed size > before installation instead of about half their size (regular rpms > with payloads still cost space). > # rpm-plugin-reflink will fall back to simple file > copying when the destination path is not on
Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
https://fedoraproject.org/wiki/Changes/EnableSystemdOomd == Summary == Provide a better experience for Fedora users in out-of-memory (OOM) situations by enabling [https://www.freedesktop.org/software/systemd/man/systemd-oomd.html systemd-oomd] by default. Actions taken by systemd-oomd operate on a per-cgroup level, aligning well with the life cycle of systemd units. systemd-oomd primarily uses [https://facebookmicrosites.github.io/psi/ Linux pressure stall information (PSI)] to make decisions based on wasted productivity due to resource shortages; in addition to that, it also supports swap based actions. == Owners == * Name: [[User:anitazha|Anita Zhang]], [[User:Dcavalca|Davide Cavalca]], [[User:Salimma|Michel Salim]], [[User:Htejun|Tejun Heo]], [[User:3ki|Rik van Riel]] * Email: the.anita...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, hte...@fb.com, r...@fb.com == Detailed description == The primary mechanism used by systemd-oomd for detecting when the system is out of memory is memory pressure. Memory pressure measures the percentage of time a cgroup has “wasted” due to lack of memory. This includes time spent reclaiming free memory, faulting in recently resident pages, and loading in anonymous pages from swap. When a monitored cgroup’s memory pressure exceeds the specified thresholds, systemd-oomd will perform action(s) on the targeted cgroup’s descendants, starting from the cgroups with the most reclaim scans. Reclaim activity is used here, rather than the largest consumer, as it reflects values set in the cgroup memory controller for memory protection (such as memory.low). For memory pressure configuration, this will be ManagedOOMMemoryPressure=kill and ManagedOOMMemoryPressureLimit=4% on user@.service to have systemd-oomd send SIGKILLs to all processes under a selected cgroup when total memory pressure on all tasks exceeds 4% for 10 seconds. For swap based actions, systemd-oomd will monitor the system-wide swap space and act when available swap falls below the configured threshold, starting with the cgroups with the highest swap usage to the least. Keeping some amount of swap (if enabled) available will prevent the kernel OOM killer from killing processes unpredictably and spending an unbounded amount of time afterwards. For swap configuration, this will be SwapUsedLimitPercent=90% in oomd.conf and ManagedOOMSwap=kill on -.slice (root cgroup slice) to have systemd-oomd send SIGKILLs to all processes under a cgroup when swap used exceeds 90%. == Benefit to Fedora == * Addressing the issue of improving user feedback in https://pagure.io/fedora-workstation/issue/202, systemd-oomd currently logs to the journal if pressure or swap action is about to occur. There are also debug logs, for each process that is sent a SIGKILL, that can be bumped up in priority. Further notification mechanisms (i.e. over dbus) can also be implemented depending on feedback. * While systemd-oomd is simpler in configuration to the oomd used at Facebook, the algorithm is largely the same. As such, the following case study can be used as an example of how PSI and cgroup killing can release memory not normally resolved with process killing and lead to better utilization: https://facebookincubator.github.io/oomd/docs/oomd-casestudy.html * OOM killing in userspace, before the kernel OOM killer kicks in, has been shown to be effective at keeping a system functional. An OOM kill in the kernel is slow, possibly leading to an unbounded amount of time swapping in and out pages and evicting the page cache. * PSI based actions, versus looking at raw memory consumption numbers, better reflect memory protection policies set for cgroup resource control limits (e.g. memory.low). == Scope == * Proposal owners: ** Implement and land additional refinements to systemd-oomd *** Remove swap as a hard requirement to running systemd-oomd *** Expand ManagedOOM*= properties to user units (currently only usable on system units) *** Configurable memory pressure time window knob ** Enable oomd by default with sensible configuration ** Test days ** Aid with documentation * Other developers: ** systemd: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9913 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == Existing systems running earlyoom will not be modified. One can transition to systemd-oomd via: sudo systemctl disable --now earlyoom sudo systemctl enable --now systemd-oomd Systems that were previously not running earlyoom will have systemd-oomd enabled by default. == How to test == systemd 247 build for Fedora includes all the artifacts for systemd-oomd. It is disabled by default but can be started with: sudo systemctl enable --now systemd-oomd At this point you can decide which units to set properties on. For example, to enable swap-based killing on all units below the root slice: sudo systemctl edit --force -- -.slice [Slice] ManagedOOMSwap=kill # save and
Disabling Python Dependency Generator Challenges
Hello,
I'm trying to build a fedora package for EPEL8 on Copr and I'm wondering
where its pikepdf dependency is coming from.
I conditionally disable the python dependency generator with a 0%{?epel}
guard
(cf.
https://github.com/gsauthof/copr-fedora/blob/c4bf0d2031b529e637d085a84837325dde36f1c2/python-img2pdf/python-img2pdf.spec#L62-L72
):
%if 0%{?epel} == 0
# this is basically equivalent to adding Requires: for
# pikepdf
# pillow
#
# the generator is enabled by default, since f30 or so
%{?python_enable_dependency_generator}
%else
%{?python_disable_dependency_generator}
Requires: python3-pillow
%endif
The guard seems to work (because e.g. the in the same way disabled tests
aren't executed, as I can see from the build.log.
However, the final rpm package still depends on pikepdf:
python3.6dist(pikepdf)
(cf. the end of
https://download.copr.fedorainfracloud.org/results/gsauthof/fedora/epel-8-x86_64/01843500-python-img2pdf/build.log.gz
)
Thus, it looks like disabling the dependency generator with the
python_disable_dependency_generator macro didn't work?
Best regards
Georg
--
'There have been no suggestions that Jay-Z's fellow rapper 50
Cent could be considering a move into a different currency.'
(Rapper Jay-Z dissing the dollar. 2007,
http://news.bbc.co.uk/2/hi/7097736.stm )
___
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 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
https://fedoraproject.org/wiki/Changes/RPMCoW == Summary == RPM Copy on Write provides a better experience for Fedora Users as it reduces the amount of I/O and offsets CPU cost of package decompression. RPM Copy on Write uses reflinking capabilities in btrfs, which is the default filesystem in Fedora 33. == Owners == * Name: [[User:malmond|Matthew Almond]], [[User:dcavalca|Davide Cavalca]] * Email: malm...@fb.com, dcava...@fb.com == Detailed description == Installing and upgrading software packages is a standard part of managing the lifecycle of any operating system. For the entire lifecycle of Fedora, all software is packaged and distributed using the RPM file fomat. This proposal changes how software is downloaded and installed, leaving the distribution process unmodified. === Current process === # Resolve packaging request into a list of packages and operations # Download and verify new packages # Install and/or upgrade packages sequentially using RPM files, decompressing, and writing a copy of the new files to storage. === New process === # Resolve packaging request into a list of packages and operations # Download and '''decompress''' packages into a '''locally optimized''' rpm file # Install and/or upgrade packages sequentially using RPM files, using '''reference linking''' (reflinking) to reuse data already on disk. The outcome is intended to be the same, but the order of operations is different. # Decompression happens inline with download. This has a positive effect on resource usage: downloads are typically limited by bandwidth. Decompression and writing the full data into a single file per rpm is essentially free. Additionally: if there is more than one download at a time, a multi-CPU system can be better utilized. All compression types supported in RPM work because this uses the rpm I/O functions. # RPMs are cached on local storage between downloading and installation time as normal. This allows DNF to defer actual RPM installation to when all the RPM are available. This is unchanged. # The file format for RPMs is different with Copy on Write. The headers are identical, but the payload is different. There is also a footer. ## Files are converted (“transcoded”) locally during download using /usr/bin/rpm2extents (part of rpm codebase). The format is not intended to be “portable” - i.e. copying the files from the cache is not supported. ## Regular RPMs use a compressed .cpio based payload. In contrast, extent based RPMs contain uncompressed data aligned to the fundamental page size of the architecture, e.g. 4KiB on x86_64. This alignment is required for FICLONERANGE to work. Only files are represented in the payload, other directory entries like symlinks, device nodes etc are constructed entirely from rpm header information. Files are referenced by their digest, so identical files are de-duplicated. ## The footer currently has three sections ### Table of original (rpm) file digests, used to validate the integrity of the download in dnf. ### Table of digest → offset used when actually installing files. ### Signature 8 bytes at the end of the file, used to differentiate between traditional RPMs and extent based. === Notes === # The headers are preserved bit for bit during transcoding. This preserves signatures. The signatures cover the main header blob, and the main header blob ensures the integrity of data in two ways: ## Each file with content has a digest. Originally this was md5, but today it’s usually sha256. In normal RPM this is only used to verify the integrity of files, e.g. rpm -V. With CoW we use this as a content key. ## There is/are one or two digests (PAYLOADDIGEST and PAYLOADDIGESTALT) covering the payload archive (compressed cpio). The header value is preserved, but transcoded RPMs do not preserve the original structure so RPM’s pre-installation verification (controlled by %_pkgverify_level will fail. dnf-plugin-cow disables this check in dnf because it verifies the whole file digest which is captured during download/transcoding. The second one is likely used for delta rpm. # This is untested, and possibly incompatible with delta RPM (drpm). The process for reconstructing an rpm to install from a delta is expensive from both a CPU and I/O perspective, while only providing marginal benefits on download size. It is expected that having delta rpm enabled (which is the default) will be handled gracefully. # Disk space requirements are expected to be marginally higher than before: all new packages or updates will consume their installed size before installation instead of about half their size (regular rpms with payloads still cost space). # rpm-plugin-reflink will fall back to simple file copying when the destination path is not on the same filesystem/subvolume. A common example is /boot and/or /boot/efi. # The system will still work on other filesystem types, but will ''always'' fall back to simple copying. This is expected to be slightly slower than not enabling CoW
Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
https://fedoraproject.org/wiki/Changes/EnableSystemdOomd == Summary == Provide a better experience for Fedora users in out-of-memory (OOM) situations by enabling [https://www.freedesktop.org/software/systemd/man/systemd-oomd.html systemd-oomd] by default. Actions taken by systemd-oomd operate on a per-cgroup level, aligning well with the life cycle of systemd units. systemd-oomd primarily uses [https://facebookmicrosites.github.io/psi/ Linux pressure stall information (PSI)] to make decisions based on wasted productivity due to resource shortages; in addition to that, it also supports swap based actions. == Owners == * Name: [[User:anitazha|Anita Zhang]], [[User:Dcavalca|Davide Cavalca]], [[User:Salimma|Michel Salim]], [[User:Htejun|Tejun Heo]], [[User:3ki|Rik van Riel]] * Email: the.anita...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, hte...@fb.com, r...@fb.com == Detailed description == The primary mechanism used by systemd-oomd for detecting when the system is out of memory is memory pressure. Memory pressure measures the percentage of time a cgroup has “wasted” due to lack of memory. This includes time spent reclaiming free memory, faulting in recently resident pages, and loading in anonymous pages from swap. When a monitored cgroup’s memory pressure exceeds the specified thresholds, systemd-oomd will perform action(s) on the targeted cgroup’s descendants, starting from the cgroups with the most reclaim scans. Reclaim activity is used here, rather than the largest consumer, as it reflects values set in the cgroup memory controller for memory protection (such as memory.low). For memory pressure configuration, this will be ManagedOOMMemoryPressure=kill and ManagedOOMMemoryPressureLimit=4% on user@.service to have systemd-oomd send SIGKILLs to all processes under a selected cgroup when total memory pressure on all tasks exceeds 4% for 10 seconds. For swap based actions, systemd-oomd will monitor the system-wide swap space and act when available swap falls below the configured threshold, starting with the cgroups with the highest swap usage to the least. Keeping some amount of swap (if enabled) available will prevent the kernel OOM killer from killing processes unpredictably and spending an unbounded amount of time afterwards. For swap configuration, this will be SwapUsedLimitPercent=90% in oomd.conf and ManagedOOMSwap=kill on -.slice (root cgroup slice) to have systemd-oomd send SIGKILLs to all processes under a cgroup when swap used exceeds 90%. == Benefit to Fedora == * Addressing the issue of improving user feedback in https://pagure.io/fedora-workstation/issue/202, systemd-oomd currently logs to the journal if pressure or swap action is about to occur. There are also debug logs, for each process that is sent a SIGKILL, that can be bumped up in priority. Further notification mechanisms (i.e. over dbus) can also be implemented depending on feedback. * While systemd-oomd is simpler in configuration to the oomd used at Facebook, the algorithm is largely the same. As such, the following case study can be used as an example of how PSI and cgroup killing can release memory not normally resolved with process killing and lead to better utilization: https://facebookincubator.github.io/oomd/docs/oomd-casestudy.html * OOM killing in userspace, before the kernel OOM killer kicks in, has been shown to be effective at keeping a system functional. An OOM kill in the kernel is slow, possibly leading to an unbounded amount of time swapping in and out pages and evicting the page cache. * PSI based actions, versus looking at raw memory consumption numbers, better reflect memory protection policies set for cgroup resource control limits (e.g. memory.low). == Scope == * Proposal owners: ** Implement and land additional refinements to systemd-oomd *** Remove swap as a hard requirement to running systemd-oomd *** Expand ManagedOOM*= properties to user units (currently only usable on system units) *** Configurable memory pressure time window knob ** Enable oomd by default with sensible configuration ** Test days ** Aid with documentation * Other developers: ** systemd: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9913 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == Existing systems running earlyoom will not be modified. One can transition to systemd-oomd via: sudo systemctl disable --now earlyoom sudo systemctl enable --now systemd-oomd Systems that were previously not running earlyoom will have systemd-oomd enabled by default. == How to test == systemd 247 build for Fedora includes all the artifacts for systemd-oomd. It is disabled by default but can be started with: sudo systemctl enable --now systemd-oomd At this point you can decide which units to set properties on. For example, to enable swap-based killing on all units below the root slice: sudo systemctl edit --force -- -.slice [Slice] ManagedOOMSwap=kill # save and
Orphaned trac-accountmanager-plugin and trac-spamfilter-plugin
Hi all, neither trac-accountmanager-plugin nor trac-spamfilter-plugin work with the development (1.5.x) build of trac currently in Fedora 33 and Rawhide. This may change at some point but as I can't use them with trac on my Fedora 33 server, I've decided to abandon my own use of trac. Hence I have orphaned the plugins. Good luck to anyone that wants to take them over. Paul. ___ 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: Preview appdata file?
Well no so fast... I've made a number of changes and it doesn't appear to show any of them, it's still using data from somewhere other than the local file. This is getting really frustrating. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1909780] New: perl-System-Info-0.060 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909780 Bug ID: 1909780 Summary: perl-System-Info-0.060 is available Product: Fedora Version: rawhide Status: NEW Component: perl-System-Info Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.060 Current version/release in rawhide: 0.059-5.fc33 URL: http://search.cpan.org/dist/System-Info/ 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/15552/ -- 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
Fedora-Rawhide-20201221.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 14/180 (x86_64), 8/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201219.n.1): ID: 744998 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/744998 ID: 745002 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/745002 ID: 745005 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/745005 ID: 745007 Test: x86_64 Workstation-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/745007 ID: 745008 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/745008 ID: 745010 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/745010 ID: 745012 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/745012 ID: 745019 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/745019 ID: 745212 Test: aarch64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/745212 Old failures (same test failed in Fedora-Rawhide-20201219.n.1): ID: 744980 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/744980 ID: 745020 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/745020 ID: 745029 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/745029 ID: 745034 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/745034 ID: 745081 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/745081 ID: 745108 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/745108 ID: 745128 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/745128 ID: 745183 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/745183 ID: 745210 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/745210 ID: 745221 Test: aarch64 universal install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/745221 ID: 745237 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/745237 ID: 745243 Test: aarch64 universal install_serial_console@uefi URL: https://openqa.fedoraproject.org/tests/745243 ID: 745246 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/745246 Soft failed openQA tests: 18/180 (x86_64), 14/122 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20201219.n.1): ID: 744949 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/744949 ID: 744950 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/744950 ID: 744957 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/744957 ID: 744961 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/744961 ID: 744965 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/744965 ID: 744966 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/744966 ID: 744979 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/744979 ID: 744988 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/744988 ID: 745051 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/745051 ID: 745060 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/745060 ID: 745061 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/745061 ID: 745069 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/745069 ID: 745080 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/745080 ID: 745086 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/745086 ID: 745100 Test: aarch64 Server-raw_xz-raw.xz
Re: Preview appdata file?
Found it... gnome-software --local-filename=... Thanks, Richard > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Preview appdata file?
In the past when I've created an appdata file for a project I was able to kill gnome-software and restart with --prefer-local so I could see that it showed up correctly. This seems to no longer work and google has not been helpful. Any workaround? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
On 21. 12. 20 14:54, Miro Hrončok wrote: For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Pro tip: Put ^((?!nodejs).) in the search bar to filter out nodejs packages. -- 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
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 34 approximately one week before branching (February 2021). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Note that some listed packages are orphaned and hence may be retired even sooner. The packages in rawhide were not successfully built at least since Fedora 32. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers Latest build === VirtualGL gsgatlin Fedora 31 boo elsupergomez, tpokorra Fedora 31 gmpcorphan Fedora 31 jboss-servlet-2.5-api dmoluguw, orphan Fedora 31 js-html5shivorphan Fedora 31 js-respond orphan Fedora 31 nodejs-info-symbol orphan Fedora 31 nodejs-interpretnodejs-sig, orphan Fedora 31 nodejs-net-browserify-alt orphan Fedora 31 nodejs-win-spawnnodejs-sig, orphan Fedora 31 rubygem-net-ssh-multi maxamillion, orphan, tdawson Fedora 31 sugar-flipstickscallkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-getiabookscallkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-infoslicercallkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-labyrinth callkalpa, chimosky, pbrobinsonFedora 31 sugar-ruler callkalpa, chimoskyFedora 31 sugar-starchart callkalpa, chimosky, orphanFedora 31 sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-visualmatch chimosky, orphan Fedora 31 sugar-yupanacallkalpa, chimosky, orphanFedora 31 The following packages require above mentioned packages: Depending on: js-html5shiv (1) copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup) copr-frontend-1.171-1.fc34.noarch requires js-html5shiv Depending on: nodejs-info-symbol (2) nodejs-log-utils (maintained by: orphan) nodejs-log-utils-0.2.1-6.fc32.noarch requires npm(info-symbol) nodejs-time-diff (maintained by: orphan) nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol) Depending on: nodejs-interpret (1) nodejs-shelljs (maintained by: fab, nodejs-sig, patches) nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret) Affected (co)maintainers (directly and indirectly): callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks, sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks, sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart, sugar-getiabooks clime: js-html5shiv copr-sig: js-html5shiv dmoluguw: jboss-servlet-2.5-api dturecek: js-html5shiv elsupergomez: boo fab: nodejs-interpret frostyx: js-html5shiv gsgatlin: VirtualGL maxamillion: rubygem-net-ssh-multi msuchy: js-html5shiv nodejs-sig: nodejs-win-spawn, nodejs-interpret patches: nodejs-interpret pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides, sugar-infoslicer, sugar-getiabooks praiskup: js-html5shiv tdawson: rubygem-net-ssh-multi tpokorra: boo tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks, sugar-flipsticks ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-12-21.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainers Status Change RxCpp orphan 4 weeks ago apache-commons-chain orphan 2 weeks ago apivizlef, orphan 4 weeks ago apper kde-sig, orphan, rhughes 4 weeks ago aseman-qt-tools orphan 0 weeks ago atanuaorphan 3 weeks ago atool lef, orphan 0 weeks ago banshee-community-extensions elsupergomez, orphan, tpokorra 0 weeks ago bfast orphan 4 weeks ago biblesync cicku, orphan4 weeks ago bifcl orphan 4 weeks ago bip adamwill, bcl, orphan2 weeks ago colorhug-client orphan 5 weeks ago cook orphan 4 weeks ago cros-guest-tools orphan 5 weeks ago dc3dd maxamillion, orphan 4 weeks ago dep go-sig, orphan 4 weeks ago dnsjava orphan 4 weeks ago dynaplugz orphan 4 weeks ago edb orphan 4 weeks ago ekiga mcrha, orphan2 weeks ago electric blackfile, orphan4 weeks ago eyesight cicku, orphan, plfiorini 4 weeks ago fifechan orphan 4 weeks ago fillets-ngorphan, thias4 weeks ago flaconignatenkobrain, orphan 4 weeks ago fmpp orphan 4 weeks ago freerdp1.2orphan 3 weeks ago freetiger orphan 4 weeks ago glyr orphan 4 weeks ago gmpc orphan 4 weeks ago gnome-code-assistance elad, orphan 4 weeks ago gnome-documents anujmore, cosimoc, gnome-sig,4 weeks ago orphan gnome-shell-extension-desktop-atim, orphan 2 weeks ago icons gridftp-ifce orphan 4 weeks ago guacamole-server orphan 3 weeks ago icemonorphan 4 weeks ago java-comment-preprocessor hhorak, orphan, panovotn,4 weeks ago praiskup jaxodraw orphan 4 weeks ago jblas orphan 4 weeks ago jboss-servlet-2.5-api dmoluguw, orphan 4 weeks ago jfontchooser orphan 4 weeks ago jgraphx jerboaa, orphan 5 weeks ago jgroups gil, goldmann, lef, orphan 4 weeks ago jing-trangorphan 4 weeks ago jnettop orphan 4 weeks ago js-html5shiv orphan 4 weeks ago js-jquery-file-upload
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-12-21.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainers Status Change RxCpp orphan 4 weeks ago apache-commons-chain orphan 2 weeks ago apivizlef, orphan 4 weeks ago apper kde-sig, orphan, rhughes 4 weeks ago aseman-qt-tools orphan 0 weeks ago atanuaorphan 3 weeks ago atool lef, orphan 0 weeks ago banshee-community-extensions elsupergomez, orphan, tpokorra 0 weeks ago bfast orphan 4 weeks ago biblesync cicku, orphan4 weeks ago bifcl orphan 4 weeks ago bip adamwill, bcl, orphan2 weeks ago colorhug-client orphan 5 weeks ago cook orphan 4 weeks ago cros-guest-tools orphan 5 weeks ago dc3dd maxamillion, orphan 4 weeks ago dep go-sig, orphan 4 weeks ago dnsjava orphan 4 weeks ago dynaplugz orphan 4 weeks ago edb orphan 4 weeks ago ekiga mcrha, orphan2 weeks ago electric blackfile, orphan4 weeks ago eyesight cicku, orphan, plfiorini 4 weeks ago fifechan orphan 4 weeks ago fillets-ngorphan, thias4 weeks ago flaconignatenkobrain, orphan 4 weeks ago fmpp orphan 4 weeks ago freerdp1.2orphan 3 weeks ago freetiger orphan 4 weeks ago glyr orphan 4 weeks ago gmpc orphan 4 weeks ago gnome-code-assistance elad, orphan 4 weeks ago gnome-documents anujmore, cosimoc, gnome-sig,4 weeks ago orphan gnome-shell-extension-desktop-atim, orphan 2 weeks ago icons gridftp-ifce orphan 4 weeks ago guacamole-server orphan 3 weeks ago icemonorphan 4 weeks ago java-comment-preprocessor hhorak, orphan, panovotn,4 weeks ago praiskup jaxodraw orphan 4 weeks ago jblas orphan 4 weeks ago jboss-servlet-2.5-api dmoluguw, orphan 4 weeks ago jfontchooser orphan 4 weeks ago jgraphx jerboaa, orphan 5 weeks ago jgroups gil, goldmann, lef, orphan 4 weeks ago jing-trangorphan 4 weeks ago jnettop orphan 4 weeks ago js-html5shiv orphan 4 weeks ago js-jquery-file-upload
Fedora rawhide compose report: 20201221.n.0 changes
OLD: Fedora-Rawhide-20201219.n.1 NEW: Fedora-Rawhide-20201221.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 0 Dropped packages:5 Upgraded packages: 70 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:21.87 MiB Size of upgraded packages: 11.92 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 522.79 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201221.n.0.x86_64.vagrant-virtualbox.box Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201221.n.0.x86_64.vagrant-libvirt.box Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20201221.n.0.x86_64.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: fedora-developer-portal-1.0.0-0.9.git1fb81d6.fc34 Summary: Fedora Developer Portal RPMs:fedora-developer-portal Size:2.63 MiB Package: fritzing-parts-0.9.3b-7.fc33 Summary: Parts library for the Fritzing electronic design application RPMs:fritzing-parts Size:12.10 MiB Package: golang-github-influxdata-roaring-0.4.12-5.fc33 Summary: Roaring bitmaps in Go RPMs:golang-github-influxdata-roaring-devel Size:99.99 KiB Package: notepadqq-1.4.8-13.fc33 Summary: An advanced text editor for developers RPMs:notepadqq Size:6.70 MiB Package: rubygem-json_pure-1.8.1-13.fc33 Summary: JSON Implementation for Ruby RPMs:rubygem-json_pure rubygem-json_pure-doc Size:364.36 KiB = UPGRADED PACKAGES = Package: cifs-utils-6.11-2.fc34 Old package: cifs-utils-6.11-1.fc34 Summary: Utilities for mounting and managing CIFS mounts RPMs: cifs-utils cifs-utils-devel cifs-utils-info pam_cifscreds Added RPMs: cifs-utils-info Size: 711.39 KiB Size change: 51.50 KiB Changelog: * Fri Dec 18 2020 Jonathan Lebon - 6.11-2 - Split out -info subpackage for smb2-quota and smbinfo https://bugzilla.redhat.com/show_bug.cgi?id=1909288 Package: ckb-next-0.4.3-1.fc34 Old package: ckb-next-0.4.2-4.fc33 Summary: Unofficial driver for Corsair RGB keyboards RPMs: ckb-next Size: 5.40 MiB Size change: 1.20 MiB Changelog: * Sun Dec 20 2020 Artur Frenszek-Iwicki - 0.4.3-1 - Update to v0.4.3 - Remove Patch0 (missing "extern" qualifiers - fixed upstream) - Simplify the install section (rely on %cmake_install) Package: codec2-0.9.2-6.fc34 Old package: codec2-0.9.2-4.fc34 Summary: Next-Generation Digital Voice for Two-Way Radio RPMs: codec2 codec2-devel Size: 2.75 MiB Size change: -6.34 KiB Changelog: * Sun Dec 20 2020 Richard Shaw - 0.9.2-5 - Rebuild for updated lpcnetfreedv. * Sun Dec 20 2020 Richard Shaw - 0.9.2-6 - Re-enable normal build after bootstrapping lpcnetfreedv. Package: cozy-0.7.8-1.fc34 Old package: cozy-0.7.7-1.fc34 Summary: Modern audiobook player RPMs: cozy Size: 273.51 KiB Size change: 283 B Changelog: * Sun Dec 20 2020 Artur Frenszek-Iwicki - 0.7.8-1 - Update to latest release Package: dhcpd-pools-3.1-1.fc34 Old package: dhcpd-pools-3.0-4.fc33 Summary: ISC dhcpd lease analysis and reporting RPMs: dhcpd-pools Size: 283.61 KiB Size change: 3.87 KiB Changelog: * Sat Dec 19 2020 Chris Adams - 3.1-1 - update to new upstream, use bundled gnulib - include make build dependency - add sample templates Package: dummy-test-package-gloster-0-2220.fc34 Old package: dummy-test-package-gloster-0-2214.fc34 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 141.12 KiB Size change: 330 B Changelog: * Sat Dec 19 2020 packagerbot - 0-2215 - rebuilt * Sun Dec 20 2020 packagerbot - 0-2216 - rebuilt * Sun Dec 20 2020 packagerbot - 0-2217 - rebuilt * Sun Dec 20 2020 packagerbot - 0-2218 - rebuilt * Sun Dec 20 2020 packagerbot - 0-2219 - rebuilt * Mon Dec 21 2020 packagerbot - 0-2220 - rebuilt Package: embree-3.12.1-2.fc34 Old package: embree-3.12.1-1.fc34 Summary: Collection of high-performance ray tracing kernels RPMs: embree embree-devel Size: 3.35 MiB Size change: -49.11 KiB Changelog: * Sat Dec 19 2020 Luya Tshimbalanga - 3.12.1-2 - Rebuild for ispc 1.5.0 Package: fritzing-0.9.4.CD498-1.fc34 Old package: fritzing-0.9.2b-21.fc33 Summary: Electronic Design Automation software; from prototype to product RPMs: fritzing fritzing-parts Added RPMs: fritzing-parts Size: 35.84 MiB Size change: -56.29 MiB Changelog: * Sun Dec 20 2020 Artur Frenszek-Iwicki - 0.9.4.CD498-1 - Update to latest stable release - Drop Patch2 (fix bug in parts intaller python script - fixed upstrea
Re: Fedora GNOME Shell rendering problem
On Mon, Dec 21, 2020 at 4:37 AM Michael Schwendt wrote: > > In the attached screenshot excerpt it's the bold "a" character that is > missing everywhere within the entire main window of Claws Mail. In other > cases, it's a different character. Sometimes it is not missing but > visually corrupted, looking like random "garbage" data. > > Fedora 33 x86_64 GNOME Shell on Wayland, and Claws Mail is based on GTK+ 2. > > What part of the rendering process could be the culprit? Pango? Most likely the GPU driver. This is a symptom of a corrupted Xft glyph cache inside the Xwayland X server. (It's not impossible that the glyph was corrupted before upload by some other component, but that's much less likely - especially if it seems to be hardware dependent.) Owen ___ 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 1909653] perl-Data-Peek-0.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909653 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Data-Peek-0.50-1.fc34 Resolution|--- |RAWHIDE Last Closed||2020-12-21 12:07:53 -- 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: What is the most time consuming task for you as packager?
Dne 19. 12. 20 v 21:24 Luya Tshimbalanga napsal(a): > Just an idea of a form application that generates the spec file for newcomers > as an example. Something like https://xsuchy.github.io/rpm-spec-wizard/ ? I do not propagate it too much as the first page needs a lot of love - it seems empty, but there is button in upper left corner, which does the magic. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ 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 1909653] perl-Data-Peek-0.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909653 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com | Doc Type|--- |If docs needed, set a value -- 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 1909492] perl-Config-Perl-V-0.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909492 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Config-Perl-V-0.33-1.f ||c34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-12-21 11:53:48 -- 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 1909508] perl-Module-CoreList-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909508 --- Comment #1 from Fedora Update System --- FEDORA-2020-bac5ecd005 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-bac5ecd005 -- 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 1909508] perl-Module-CoreList-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909508 --- Comment #1 from Fedora Update System --- FEDORA-2020-bac5ecd005 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-bac5ecd005 --- Comment #2 from Fedora Update System --- FEDORA-2020-d971f57a54 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d971f57a54 -- 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 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On 21. 12. 20 2:38, clime wrote: On Sun, 20 Dec 2020 at 11:39, Miro Hrončok wrote: On 12/20/20 1:38 AM, clime wrote: I view this proposal as a risk that the spec files will look a bit more weird, and the spec files maintenance will start diverging too much. Everything happening for an overestimated triviality as IMO the release/changelog is [1]. Well, even if this change is accepted, it doesn't mean people will use the feature so if the feature is overkill or it is generally bad, it will just die on its own. No. In fact, even if one maintainer keep using this (e.g. you), as a provenpackager I still need to be able to deal with that. So, while this is "opt-in only" for the individual packagers, it impacts all our provenackagers (and some of our downstreams as well). In some cases, the effect of this change on the work of ProvenPackagers will be positive. Manual release bumping (because of soname-bump or a hotfix change) is easier because you can just call `fedpkg tag` and write a message instead of manually messing with a spec file. And in case a script is used, then it's exactly the same amount of work (calling the script). It is not easier, because you need to special case it in all scripts *and* manual work. -- 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: Pagure / src.fp.o page comments go "stale"
On Sun, Dec 20, 2020 at 08:49:13AM -0500, Neal Gompa wrote: > On Sun, Dec 20, 2020 at 8:47 AM Richard Shaw wrote: > > > > I've noticed for a while now that if I leave one of the above pages open > > for an extended period of time that I can no longer submit comments. I just > > get the cursor circle of death and it just sits there indefinitely. > > > > I've resorted to copying my comments, refreshing the page, and then > > submitting again which always works, but the question is: > > > > Why is this necessary to begin with? > > There are only two cases where this happens: > > 1. You are expiring your login sessions aggressively locally (purging > cookies, etc.) > 2. The browser is disconnecting and killing the memory processes aggressively > > Neither of which are from Pagure's side. But the failed AJAX request should return an error (after a timeout) and a server-provided JavaScript client should handle the error gracefully. Instead of falling into a does-not-halt state. -- 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
[Bug 1909508] perl-Module-CoreList-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909508 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Module-CoreList-5.2020 ||1220-1.fc34 -- 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 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 20/11/2020 16:26, Ben Cotton wrote: == Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default. So I tried this in F33 with the packages from updates-testing and I'm afraid to say it didn't end well... Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify: - patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x) As pactl was removed by the switch I couldn't test this. - gnome-control-center: check the audio tab, check the volume sliders and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch. This worked initially, but see later. - pavucontrol: check volumes in the input devices tabs and check the microphone volumes Didn't test this. - firefox: check out a website with audio/video such as youtube and verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111). Didn't test this. - rhythmbox: check if playback works as expected This worked initially, but see later. - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. I was unable to get this to work. The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager. After that my headphones who show up as a device in pw-cli but not as a target I could send sound to. The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you switch to a different desktop to something because once I started a second session things got horribly confused and I wound up with one desktop where audio worked and one where it didn't work at all. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 1909507] perl-CPAN-Perl-Releases-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909507 --- Comment #1 from Fedora Update System --- FEDORA-2020-28a677bff8 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-28a677bff8 --- Comment #2 from Fedora Update System --- FEDORA-2020-039eaf42c6 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-039eaf42c6 -- 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 1909507] perl-CPAN-Perl-Releases-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909507 --- Comment #1 from Fedora Update System --- FEDORA-2020-28a677bff8 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-28a677bff8 -- 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 1909508] perl-Module-CoreList-5.20201220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909508 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|jose.p.oliveira.oss@gmail.c | |om, spo...@gmail.com, | |st...@silug.org | Doc Type|--- |If docs needed, set a value -- 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 1909364] perl-CPANPLUS-0.9910 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909364 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-CPANPLUS-0.991.000-1.f ||c34 -- 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
