[Bug 2031754] perl-Authen-PAM for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031754 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2021-8643de577a has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-8643de577a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031754 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
Great job. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031490] Please branch and build perl-Clone-PP in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2031490 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2021-b4b09cbbb9 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b4b09cbbb9 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031490 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031492] branch request: perl-Data-MessagePack for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=2031492 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2021-50e30ddd6f has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-50e30ddd6f 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031492 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2029100] perlbrew-0.94 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2029100 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Fixed In Version|perlbrew-0.94-1.fc36|perlbrew-0.94-1.fc36 ||perlbrew-0.94-1.fc35 Last Closed||2021-12-15 02:12:05 --- Comment #3 from Fedora Update System --- FEDORA-2021-954d818d4e has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2029100 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
Hi all, Neal Gompa and I have been reviving the effort to get our mailing list server infrastructure (currently running on RHEL 7 with missing packages provided in an unofficial repo) hostable on RHEL 9 + EPEL. Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) We're currently stuck on the following: https://bugzilla.redhat.com/show_bug.cgi?id=2032607 Your package (python-hyperkitty) Fails To Install in Fedora 36: can't install hyperkitty: - nothing provides python3.10dist(flufl-lock) >= 4 needed by hyperkitty-1.3.5-1.fc36.noarch - nothing provides python3.10dist(mistune) >= 2~rc1 needed by hyperkitty-1.3.5-1.fc36.noarch I have PRs attached to the upgrade requests for mistune: https://bugzilla.redhat.com/show_bug.cgi?id=1782288 and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603 but both have breaking changes I detailed in the above Bz entries; if you're a maintainer cc:ed on this email please check the relevant bz: ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source --whatrequires python3-flufl-lock mailman3-0:3.3.4-5.fc35.noarch mailman3-0:3.3.4-5.fc35.src mailman3-0:3.3.4-5.fc36.noarch mailman3-0:3.3.4-5.fc36.src odcs-0:0.3.4-6.fc35.noarch odcs-0:0.3.4-6.fc35.src odcs-0:0.3.4-6.fc36.noarch odcs-0:0.3.4-6.fc36.src python-cartopy-0:0.20.0-1.fc35.src python-cartopy-0:0.20.1-2.fc36.src ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source --whatrequires python3-mistune python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src python-nbconvert-0:6.1.0-2.fc35.src python-nbconvert-0:6.1.0-3.fc36.src python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch python3-nbconvert-0:6.1.0-2.fc35.noarch python3-nbconvert-0:6.1.0-3.fc36.noarch In particular, python-nbconvert specifically requires mistune < 2, and upstream doesn't seem to have a newer release yet. python-cartopy oddly only requires flufl-lock in its SRPM, not the built RPM. PRs: https://src.fedoraproject.org/rpms/python-flufl-lock/pull-request/1 https://src.fedoraproject.org/rpms/python-mistune/pull-request/5 (the packages are not in side tags yet because the PRs are not merged yet, but if it helps I can build them in a COPR for F35) We should probably bump the packages in Rawhide anyway, but also to note: - both of these packages are not co-maintained by the Python SIG - most of the recent updates have been done by non-maintainers Would it make sense to get the following groups officially added to the package ACLs? - infra-sig (admin), to ease maintaining the dependencies for Mailman and Hyperkitty - python-sig (commit or admin), for fixing issues e.g. with newer Python versions - epel-packagers-sig (collaborator, epel* branches) for helping to bootstrap on new EL releases Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031234] Please branch and build perl-DateTime-Format-SQLite in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2031234 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2021-a360d29c9b has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a360d29c9b 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031234 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031450] Please branch and build perl-XML-LibXSLT in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2031450 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2021-63cc27a92e has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-63cc27a92e 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031450 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Tue, Dec 14, 2021 at 05:50:46PM -0500, Elliott Sales de Andrade wrote: > On Tue, 14 Dec 2021 at 17:32, Michel Alexandre Salim > wrote: > > > > Hi all, > > > > Neal Gompa and I have been reviving the effort to get our mailing list > > server infrastructure (currently running on RHEL 7 with missing packages > > provided in an unofficial repo) hostable on RHEL 9 + EPEL. > > > > Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 > > Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 > > Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) > > > > We're currently stuck on the following: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2032607 > > > > Your package (python-hyperkitty) Fails To Install in Fedora 36: > > > > can't install hyperkitty: > > - nothing provides python3.10dist(flufl-lock) >= 4 needed by > > hyperkitty-1.3.5-1.fc36.noarch > > - nothing provides python3.10dist(mistune) >= 2~rc1 needed by > > hyperkitty-1.3.5-1.fc36.noarch > > > > I have PRs attached to the upgrade requests for mistune: > > https://bugzilla.redhat.com/show_bug.cgi?id=1782288 > > and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603 > > > > but both have breaking changes I detailed in the above Bz entries; if > > you're a maintainer cc:ed on this email please check the relevant bz: > > > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > > --whatrequires python3-flufl-lock > > mailman3-0:3.3.4-5.fc35.noarch > > mailman3-0:3.3.4-5.fc35.src > > mailman3-0:3.3.4-5.fc36.noarch > > mailman3-0:3.3.4-5.fc36.src > > odcs-0:0.3.4-6.fc35.noarch > > odcs-0:0.3.4-6.fc35.src > > odcs-0:0.3.4-6.fc36.noarch > > odcs-0:0.3.4-6.fc36.src > > python-cartopy-0:0.20.0-1.fc35.src > > python-cartopy-0:0.20.1-2.fc36.src > > > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > > --whatrequires python3-mistune > > python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src > > python-nbconvert-0:6.1.0-2.fc35.src > > python-nbconvert-0:6.1.0-3.fc36.src > > python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch > > python3-nbconvert-0:6.1.0-2.fc35.noarch > > python3-nbconvert-0:6.1.0-3.fc36.noarch > > > > In particular, python-nbconvert specifically requires mistune < 2, and > > upstream doesn't seem to have a newer release yet. python-cartopy oddly > > only requires flufl-lock in its SRPM, not the built RPM. > > > > Cartopy only needs flufl-lock to run tests. I suppose since those are > installed, it could also have a runtime dependency, but it'd be > largely unused, and anyway Cartopy won't need it at all after the next > minor release. Thanks, I just checked and all cartopy tests still pass with flufl-lock 6.0. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-12-20 and 2021-12-27 Fedora QA Meetings
Hi folks! I'm proposing we cancel the next couple of QA meetings, as it's the holiday season and folks both RHer and non-RHer will likely be busy. There's nothing urgent that needs addressing, so far as I know. We'll reconvene in the New Year, on January 3rd 2022. Happy holidays everyone! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032672] New: perl-REST-Client-280 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2032672 Bug ID: 2032672 Summary: perl-REST-Client-280 is available Product: Fedora Version: rawhide Status: NEW Component: perl-REST-Client Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 280 Current version/release in rawhide: 273-20.fc35 URL: http://search.cpan.org/dist/REST-Client/ 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/3297/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032672 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032672] perl-REST-Client-280 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2032672 --- Comment #1 from Upstream Release Monitoring --- Scratch build failed. Details bellow: BuilderException: Build started, but failure happened during post build operations: Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-ofku0ewh/perl-REST-Client.spec']' returned non-zero exit status 1. StdOut: error: Bad source: ./REST-Client-280.tar.gz: No such file or directory Traceback: File "/usr/local/lib/python3.9/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build result = self.builder.build(request.package, request.opts) File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line 188, in build raise BuilderException( If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032672 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032512] Please branch and build perl-Switch in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032512 Chris Adams changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed||2021-12-14 23:33:13 --- Comment #1 from Chris Adams --- Sorry, I missed that perl-Switch is in the CentOS 9-stream CRB repo. Please ignore. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032512 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Tue, 14 Dec 2021 at 17:32, Michel Alexandre Salim wrote: > > Hi all, > > Neal Gompa and I have been reviving the effort to get our mailing list > server infrastructure (currently running on RHEL 7 with missing packages > provided in an unofficial repo) hostable on RHEL 9 + EPEL. > > Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 > Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 > Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) > > We're currently stuck on the following: > > https://bugzilla.redhat.com/show_bug.cgi?id=2032607 > > Your package (python-hyperkitty) Fails To Install in Fedora 36: > > can't install hyperkitty: > - nothing provides python3.10dist(flufl-lock) >= 4 needed by > hyperkitty-1.3.5-1.fc36.noarch > - nothing provides python3.10dist(mistune) >= 2~rc1 needed by > hyperkitty-1.3.5-1.fc36.noarch > > I have PRs attached to the upgrade requests for mistune: > https://bugzilla.redhat.com/show_bug.cgi?id=1782288 > and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603 > > but both have breaking changes I detailed in the above Bz entries; if > you're a maintainer cc:ed on this email please check the relevant bz: > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > --whatrequires python3-flufl-lock > mailman3-0:3.3.4-5.fc35.noarch > mailman3-0:3.3.4-5.fc35.src > mailman3-0:3.3.4-5.fc36.noarch > mailman3-0:3.3.4-5.fc36.src > odcs-0:0.3.4-6.fc35.noarch > odcs-0:0.3.4-6.fc35.src > odcs-0:0.3.4-6.fc36.noarch > odcs-0:0.3.4-6.fc36.src > python-cartopy-0:0.20.0-1.fc35.src > python-cartopy-0:0.20.1-2.fc36.src > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > --whatrequires python3-mistune > python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src > python-nbconvert-0:6.1.0-2.fc35.src > python-nbconvert-0:6.1.0-3.fc36.src > python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch > python3-nbconvert-0:6.1.0-2.fc35.noarch > python3-nbconvert-0:6.1.0-3.fc36.noarch > > In particular, python-nbconvert specifically requires mistune < 2, and > upstream doesn't seem to have a newer release yet. python-cartopy oddly > only requires flufl-lock in its SRPM, not the built RPM. > Cartopy only needs flufl-lock to run tests. I suppose since those are installed, it could also have a runtime dependency, but it'd be largely unused, and anyway Cartopy won't need it at all after the next minor release. > PRs: > https://src.fedoraproject.org/rpms/python-flufl-lock/pull-request/1 > https://src.fedoraproject.org/rpms/python-mistune/pull-request/5 > > (the packages are not in side tags yet because the PRs are not merged > yet, but if it helps I can build them in a COPR for F35) > > We should probably bump the packages in Rawhide anyway, but also to > note: > - both of these packages are not co-maintained by the Python SIG > - most of the recent updates have been done by non-maintainers > > Would it make sense to get the following groups officially added to the > package ACLs? > - infra-sig (admin), to ease maintaining the dependencies for Mailman > and Hyperkitty > - python-sig (commit or admin), for fixing issues e.g. with newer Python > versions > - epel-packagers-sig (collaborator, epel* branches) for helping to > bootstrap on new EL releases > > Thanks, > > -- > Michel Alexandre Salim > profile: https://keyoxide.org/mic...@michel-slm.name -- Elliott ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Tue, 14 Dec 2021 at 17:32, Michel Alexandre Salim wrote: > > Hi all, > > Neal Gompa and I have been reviving the effort to get our mailing list > server infrastructure (currently running on RHEL 7 with missing packages > provided in an unofficial repo) hostable on RHEL 9 + EPEL. > > Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 > Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 > Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) > > We're currently stuck on the following: > > https://bugzilla.redhat.com/show_bug.cgi?id=2032607 > > Your package (python-hyperkitty) Fails To Install in Fedora 36: > > can't install hyperkitty: > - nothing provides python3.10dist(flufl-lock) >= 4 needed by > hyperkitty-1.3.5-1.fc36.noarch > - nothing provides python3.10dist(mistune) >= 2~rc1 needed by > hyperkitty-1.3.5-1.fc36.noarch > > I have PRs attached to the upgrade requests for mistune: > https://bugzilla.redhat.com/show_bug.cgi?id=1782288 > and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603 > > but both have breaking changes I detailed in the above Bz entries; if > you're a maintainer cc:ed on this email please check the relevant bz: > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > --whatrequires python3-flufl-lock > mailman3-0:3.3.4-5.fc35.noarch > mailman3-0:3.3.4-5.fc35.src > mailman3-0:3.3.4-5.fc36.noarch > mailman3-0:3.3.4-5.fc36.src > odcs-0:0.3.4-6.fc35.noarch > odcs-0:0.3.4-6.fc35.src > odcs-0:0.3.4-6.fc36.noarch > odcs-0:0.3.4-6.fc36.src > python-cartopy-0:0.20.0-1.fc35.src > python-cartopy-0:0.20.1-2.fc36.src > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > --whatrequires python3-mistune > python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src > python-nbconvert-0:6.1.0-2.fc35.src > python-nbconvert-0:6.1.0-3.fc36.src > python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch > python3-nbconvert-0:6.1.0-2.fc35.noarch > python3-nbconvert-0:6.1.0-3.fc36.noarch > > In particular, python-nbconvert specifically requires mistune < 2, and > upstream doesn't seem to have a newer release yet. python-cartopy oddly > only requires flufl-lock in its SRPM, not the built RPM. > Cartopy only needs flufl-lock to run tests. I suppose since those are installed, it could also have a runtime dependency, but it'd be largely unused, and anyway Cartopy won't need it at all after the next minor release. > PRs: > https://src.fedoraproject.org/rpms/python-flufl-lock/pull-request/1 > https://src.fedoraproject.org/rpms/python-mistune/pull-request/5 > > (the packages are not in side tags yet because the PRs are not merged > yet, but if it helps I can build them in a COPR for F35) > > We should probably bump the packages in Rawhide anyway, but also to > note: > - both of these packages are not co-maintained by the Python SIG > - most of the recent updates have been done by non-maintainers > > Would it make sense to get the following groups officially added to the > package ACLs? > - infra-sig (admin), to ease maintaining the dependencies for Mailman > and Hyperkitty > - python-sig (commit or admin), for fixing issues e.g. with newer Python > versions > - epel-packagers-sig (collaborator, epel* branches) for helping to > bootstrap on new EL releases > > Thanks, > > -- > Michel Alexandre Salim > profile: https://keyoxide.org/mic...@michel-slm.name -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
Hi all, Neal Gompa and I have been reviving the effort to get our mailing list server infrastructure (currently running on RHEL 7 with missing packages provided in an unofficial repo) hostable on RHEL 9 + EPEL. Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) We're currently stuck on the following: https://bugzilla.redhat.com/show_bug.cgi?id=2032607 Your package (python-hyperkitty) Fails To Install in Fedora 36: can't install hyperkitty: - nothing provides python3.10dist(flufl-lock) >= 4 needed by hyperkitty-1.3.5-1.fc36.noarch - nothing provides python3.10dist(mistune) >= 2~rc1 needed by hyperkitty-1.3.5-1.fc36.noarch I have PRs attached to the upgrade requests for mistune: https://bugzilla.redhat.com/show_bug.cgi?id=1782288 and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603 but both have breaking changes I detailed in the above Bz entries; if you're a maintainer cc:ed on this email please check the relevant bz: ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source --whatrequires python3-flufl-lock mailman3-0:3.3.4-5.fc35.noarch mailman3-0:3.3.4-5.fc35.src mailman3-0:3.3.4-5.fc36.noarch mailman3-0:3.3.4-5.fc36.src odcs-0:0.3.4-6.fc35.noarch odcs-0:0.3.4-6.fc35.src odcs-0:0.3.4-6.fc36.noarch odcs-0:0.3.4-6.fc36.src python-cartopy-0:0.20.0-1.fc35.src python-cartopy-0:0.20.1-2.fc36.src ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source --whatrequires python3-mistune python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src python-nbconvert-0:6.1.0-2.fc35.src python-nbconvert-0:6.1.0-3.fc36.src python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch python3-nbconvert-0:6.1.0-2.fc35.noarch python3-nbconvert-0:6.1.0-3.fc36.noarch In particular, python-nbconvert specifically requires mistune < 2, and upstream doesn't seem to have a newer release yet. python-cartopy oddly only requires flufl-lock in its SRPM, not the built RPM. PRs: https://src.fedoraproject.org/rpms/python-flufl-lock/pull-request/1 https://src.fedoraproject.org/rpms/python-mistune/pull-request/5 (the packages are not in side tags yet because the PRs are not merged yet, but if it helps I can build them in a COPR for F35) We should probably bump the packages in Rawhide anyway, but also to note: - both of these packages are not co-maintained by the Python SIG - most of the recent updates have been done by non-maintainers Would it make sense to get the following groups officially added to the package ACLs? - infra-sig (admin), to ease maintaining the dependencies for Mailman and Hyperkitty - python-sig (commit or admin), for fixing issues e.g. with newer Python versions - epel-packagers-sig (collaborator, epel* branches) for helping to bootstrap on new EL releases Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pipewire memory usage
Carlos O'Donell wrote on Tue, Dec 14, 2021 at 11:07:42AM -0500:
> > So I guess we're just chasing after artifacts from the allocator, and
> > it'll be hard to tell which it is when I happen to see pipewire-pulse
> > with high memory later on...
>
> It can be difficult to tell the difference between:
> (a) allocator caching
> (b) application usage
>
> To help with we developed some additional tracing utilities:
> https://pagure.io/glibc-malloc-trace-utils
Thanks for the pointer, I knew something would be able to do this but I
didn't remember what allowed this.
I don't see this in any package, maybe it'd be interesting to ship these
for easy use?
(yes, it's not difficult to git clone and configure/make locally, but
I'll forget about it again whereas a package might be easier to
remember)
For now, I can confirm that all memory is indeed freed in a timely
manner as far as pipewire-pulse knows.
> > From what I can see the big allocations are (didn't look at lifetime of each
> > alloc):
> > - load_spa_handle for audioconvert/libspa-audioconvert allocs 3.7MB
> > - pw_proxy_new allocates 590k
> > - reply_create_playback_stream allocates 4MB
> > - spa_buffer_alloc_array allocates 1MB from negotiate_buffers
> > - spa_buffer_alloc_array allocates 256K x2 + 128K
> >from negotiate_link_buffers
>
> On a 64-bit system the maximum dynamic allocation size is 32MiB.
>
> As you call malloc with ever larger values the dynamic scaling will scale up
> to
> at most 32MiB (half of a 64MiB heap). So it is possible that all of these
> allocations
> are placed on the mmap/sbrk'd heaps and stay there for future usage until
> freed back.
Yes, that's my guess as well - as they're all different sizes the cache
can blow up.
> Could you try running with this env var:
>
> GLIBC_TUNABLES=glibc.malloc.mmap_threshold=131072
>
> Note: See `info libc tunables`.
with this the max moved down from ~300-600MB to 80-150MB, and it comes
back down to 80-120MB instead of ~300MB.
> > maybe some of these buffers sticking around for the duration of the
> > connection could be pooled and shared?
>
> They are pooled and shared if they are cached by the system memory allocator.
>
> All of tcmalloc, jemalloc, and glibc malloc attempt to cache the userspace
> requests
> with different algorithms that match given workloads.
Yes, I didn't mean pooling as pooling allocator, but I meant live
pooling usage e.g. every objects could use the same objects when they
need to.
I can understand buffers being made per-client so an overhead of 1-2MB
per client is acceptable, but the bulk of the spa handle seem to be
storing many big ports?
$ pahole -y impl spa/plugins/audioconvert/libspa-audioconvert.so.p/merger.c.o
struct impl {
...
struct portin_ports[64]; /* 256 1153024 */
/* --- cacheline 18020 boundary (1153280 bytes) --- */
struct portout_ports[65];/* 1153280 1171040 */
/* --- cacheline 36317 boundary (2324288 bytes) was 32 bytes ago --- */
struct spa_audio_info format; /* 2324320 284 */
...
$ pahole -y impl spa/plugins/audioconvert/libspa-audioconvert.so.p/splitter.c.o
struct impl {
...
struct portin_ports[1]; /* 184 18056 */
/* --- cacheline 285 boundary (18240 bytes) --- */
struct portout_ports[64];/* 18240 1155584 */
/* --- cacheline 18341 boundary (1173824 bytes) --- */
...
Which themselves have a bunch of buffers:
struct port {
...
struct buffer buffers[32]; /* 576 17408 */
(pahole also prints useful hints that the structures have quite a bit of
padding, so some optimization there could save some scraps, but I think
it's more fundamental than this)
I understand that allocating once in bulk is ideal for latency so I have
no problem with overallocating a bit, but I'm not sure if we need so
many buffers laying around when clients are mute and probably not using
most of these :)
(I also understand that this isn't an easy change I'm asking about, it
doesn't have to be immediate)
BTW I think we're getting a bit gritty, which might be fine for the list
but probably leave some pipewire devs out. Perhaps it's time to move to
a new pipewire issue?
--
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[rpms/perl-Text-RecordParser] PR #1: Split tools into a subpackage
adamwill commented on the pull-request: `Split tools into a subpackage` that you are following: `` Together with https://src.fedoraproject.org/rpms/perl-SQL-Translator/pull-request/1 , this lets me cut graphviz out of openQA's dependency chain, which let me dump a ton of packages from the openQA server. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Text-RecordParser/pull-request/1 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Text-RecordParser] PR #1: Split tools into a subpackage
adamwill opened a new pull-request against the project: `perl-Text-RecordParser` that you are following: `` Split tools into a subpackage `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Text-RecordParser/pull-request/1 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: missing pyproject-rpm-macros component from EPEL (Bugzilla)
fair enough, will this be also the case for EPEL9? On Tue, Dec 14, 2021 at 10:47 PM Adam Williamson wrote: > On Tue, 2021-12-14 at 22:24 +0100, chedi toueiti wrote: > > I noticed that pyproject-rpm-macros is not listed as a Bugzilla component > > in the EPEL product. Is there a specific reason for that? If not can > > someone add it or direct me to the adequate procedure to request it. > > It's 'missing' because the package isn't built on EPEL. It's not built > on EPEL because the EL 7 and EL 8 environments are too old for the > macros to work. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- *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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-SQL-Translator] PR #1: Split GraphViz-dependent components into subpackages
adamwill commented on the pull-request: `Split GraphViz-dependent components into subpackages` that you are following: `` @eseyman for comments from a perl packaging expert...not sure if -graph is the best subpackage name, or if there's a more 'canonical' way to do this kind of split, please let me know if so! `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-SQL-Translator/pull-request/1 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-SQL-Translator] PR #1: Split GraphViz-dependent components into subpackages
adamwill opened a new pull-request against the project: `perl-SQL-Translator` that you are following: `` Split GraphViz-dependent components into subpackages `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-SQL-Translator/pull-request/1 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Raising the attachment size limit in bugzilla?
On 12/14/21 12:37, Daniel P. Berrangé wrote: > A sosreport contains a tonne of useful info, but for any single bug > the vast majority is irrelevant. So it is much harder to argue that > requesting this sos report info is proportionate for solving bugs > from Fedora users, especially when attachments default to public > and never expire. I'm happy if Fedora SOS reports default to *less* information, and perhaps have no logs, and if that gets us under the 19.5MiB attachment limit then I'm fine. I'm looking for an *easy* way to get /proc/cpuinfo and other system information from a developer since that helps me as a glibc developer track down bugs. The existence of sos makes this process easier (no matter if it gathers too much information). I have not seen any Fedora-specific customization for sos (the package e.g. sos.spec) but it should be possible to do that. I could file a bug asking for a Fedora-specific customization to default to collecting less information? -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: missing pyproject-rpm-macros component from EPEL (Bugzilla)
On Tue, 2021-12-14 at 22:24 +0100, chedi toueiti wrote: > I noticed that pyproject-rpm-macros is not listed as a Bugzilla component > in the EPEL product. Is there a specific reason for that? If not can > someone add it or direct me to the adequate procedure to request it. It's 'missing' because the package isn't built on EPEL. It's not built on EPEL because the EL 7 and EL 8 environments are too old for the macros to work. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
missing pyproject-rpm-macros component from EPEL (Bugzilla)
I noticed that pyproject-rpm-macros is not listed as a Bugzilla component in the EPEL product. Is there a specific reason for that? If not can someone add it or direct me to the adequate procedure to request it. -- *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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On Tue, Dec 14, 2021 at 08:08:19PM +0100, Fabio Valentini wrote: > On Tue, Dec 14, 2021 at 1:45 AM Davide Cavalca via devel > wrote: > > > > On Mon, 2021-12-13 at 16:00 +0100, Vít Ondruch wrote: > > > Would it be possible to document the editing of protected file in the > > > change proposal, probably including example of the best way to do it > > > (is > > > it possible to replace the file by symlink?) Or is there a way to > > > temporary enable the editing with some overlay? Is there any other way > > > to restore the original file except "dnf reinstall"? > > > > I've added this to the wiki: > > https://fedoraproject.org/wiki/Changes/FsVerityRPM#Can_the_user_modify_a_file_shipped_by_a_package_.28e.g._to_edit_a_script_while_debugging.29_.3F > > > > You could restore the original file via "dnf reinstall", or by moving > > it back into place (rename() and unlink() are allowed on fs-verity > > enabled files). > > I thought fsverity was about determining at runtime that the system > has not been tampered with? But if somebody who has (physical) access > to the device can just ... move verified files out of the way and put > their own (unverified) files there (which then apparently does not > trigger red warning signs?) - doesn't that defeat the whole purpose of > enabling fsverity? That's a good question. fs-verity and dm-verity share the same underlying concept (merkle trees and signature verification by the kernel). So this raises the question that you asked… which can also be phrased as "why would you even use fs-verity, if you can do dm-verity"? My understanding it the following: fs-verity originated in the Android world where you can have an unprivileged process downloading a file, e.g. a jar. This unprivileged process manages the download, but the file is only trusted and executed when it has a matching signature from some central authority. The file contains the whole app, including all resources, so there is no question of other unverified files being used by the app. And the file can be large enough that it's practical to do chunked verification, since checksumming the whole file on first use would be slow. We don't really have the same considerations: the download process has full privileges, and the download is exploded into individual files, and more importantly, unpackaged files are also used. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
License update: scummvm
Hello, beginning with version 2.5.0, the license for the package scummvm has been changed to "GPLv2+ and LGPLv2+ and GPLv3+ and BSD and OFL and MIT and ISC" Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Provisional %{pyproject_build_lib} macro
Hello Pythonistas,
the pyproject-rpm-macros-0-51 update (available in Rawhide+ELN and updates
ready for 33 and 34) introduces a new provisional %{pyproject_build_lib} macro.
The intended use case will remain the same, but it might yet change its
behavior slightly. Here is the snippet from pyproject-rpm-macros README, better
viewed at
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/README.md
PROVISIONAL: Importing just-built (extension) modules in %build
---
Sometimes, it is desired to be able to import the *just-built* extension modules
in the `%build` section, e.g. to build the documentation with Sphinx.
%build
%pyproject_wheel
... build the docs here ...
With pure Python packages, it might be possible to set `PYTHONPATH=${PWD}` or
`PYTHONPATH=${PWD}/src`.
However, it is a bit more complicated with extension modules.
The location of just-built modules might differ depending on Python version,
architecture, pip version.
Hence, the macro `%{pyproject_build_lib}` exists to be used like this:
%build
%pyproject_wheel
PYTHONPATH=%{pyproject_build_lib} ... build the docs here ...
This macro is currently **provisional** and the behavior might change.
The `%{pyproject_build_lib}` macro expands to an Shell `$(...)` expression and
does not work when put into single quotes (`'`).
Depending on the pip version, the expanded value will differ:
### New pip 21.3+ with in-tree-build (Fedora 36+)
Always use the macro from the same directory where you called
`%pyproject_wheel` from.
The value will expand to something like:
* `/builddir/build/BUILD/%{name}-%{version}/build/lib.linux-x86_64-3.10` for
wheels with extension modules
* `/builddir/build/BUILD/%{name}-%{version}/build/lib` for pure Python wheels
If multiple wheels were built from the same directory,
some pure Python and some with extension modules,
the expanded value will be combined with `:`:
*
`/builddir/build/BUILD/%{name}-%{version}/build/lib.linux-x86_64-3.10:/builddir/build/BUILD/%{name}-%{version}/build/lib`
If multiple wheels were built from different directories,
the value will differ depending on the current directory.
### Older pip with out-of-tree-build (Fedora 34, 35, and EL 9)
The value will expand to something like:
*
`/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib.linux-x86_64-3.10`
for wheels with extension modules
*
`/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib`
for pure Python wheels
Note that the exact value is **not stable** between builds
(the `` part is randomly generated,
neither you should consider the `.pyproject-builddir` directory to remain
stable).
If multiple wheels are built,
the expanded value will always be combined with `:` regardless of the current
directory, e.g.:
*
`/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib.linux-x86_64-3.10:/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib.linux-x86_64-3.10:/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib`
**Note:** If you manage to build some wheels with in-tree-build and some with
out-of-tree-build option,
the expanded value will contain all relevant directories.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On Tue, Dec 14, 2021 at 1:45 AM Davide Cavalca via devel wrote: > > On Mon, 2021-12-13 at 16:00 +0100, Vít Ondruch wrote: > > Would it be possible to document the editing of protected file in the > > change proposal, probably including example of the best way to do it > > (is > > it possible to replace the file by symlink?) Or is there a way to > > temporary enable the editing with some overlay? Is there any other way > > to restore the original file except "dnf reinstall"? > > I've added this to the wiki: > https://fedoraproject.org/wiki/Changes/FsVerityRPM#Can_the_user_modify_a_file_shipped_by_a_package_.28e.g._to_edit_a_script_while_debugging.29_.3F > > You could restore the original file via "dnf reinstall", or by moving > it back into place (rename() and unlink() are allowed on fs-verity > enabled files). I thought fsverity was about determining at runtime that the system has not been tampered with? But if somebody who has (physical) access to the device can just ... move verified files out of the way and put their own (unverified) files there (which then apparently does not trigger red warning signs?) - doesn't that defeat the whole purpose of enabling fsverity? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
I don't believe we systematically tested this. We will collect that along with the detailed size increase data. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Raising the attachment size limit in bugzilla?
On Tue, Dec 14, 2021 at 09:48:58AM -0500, Carlos O'Donell wrote: > The Fedora SOS reports are ~30MiB today, and this exceeds the > Bugzilla attachment limit of 19.5MiB. Rather than going straight to raising BZ limits, I think we have some more basic questions that should be considered first First, it is reasonable for the Fedora SOS reports to be such a large size by default ? Second, is Fedora setup to handle these user SOS reports (that are likely to contain large amounts of sensitive PII - Personally Identifiable Information) in a way that respects data protection rules or best practices. Bear in mind that the Fedora bug tracker defaults to everything being public unless you remember to tick the 'private' box, and once attached never expires. TL;DR, I'm sceptical that Fedora maintainers should be handling sosreports at all in bugzilla right nwo. I just generated a sosreport on my Fedora host and it indeed came out at the kind of scale you mention - for me 20 MB compressed, and 375 MB uncompressed. Mine had 100 MB of 'journalctl' output dating back over 6 months. I struggle to come up with any common scenarios in which debugging is going to require 6 months of logs from my server. IMHO most bugs where logs are relevant would only need 24 hours worth of data to diagnose. In the rare cases where more is needed the user could be asked for that separately from a sosreport. IOW That 100 MB could easily be a mere few MB instead. In another directory it then has another 35 MB of journalctl output, split across 2 files which are identical, dating back ~1 month from the last time I booted. Again this feels very excessive. I can understand wanting to get kernel boot up messages, which might be quite some time ago, but that does not imply we need everything in between the initial boot up and today. IOW just journal logs is 1/3 of the total data size in my sosreport ! Looking at another random large file 'ss_-peaonmi.tailed', at 25 MB in size. It seems to be listing open socket information. For some bizarre reason every line in it starts with ~4KB of whitespace, and then about 200 bytes of actual data. IOW, that 25 MB could be less than 0.5 MB if all the extraneous whitespace wasn't there. At least whitespace compresses well, but still... Overall, sosreport sizes feel pretty excessive and have scope for more tailored data collection, without terribly compromising the usefulness. On the second question, there is a significant amount of data in the sosreports that is likely to be sensitive, and thus raises questions about data protection / PII handling policies if we request it from users in a public facing bug tracker. The 'sos' tool prints a warning message telling you to analyse the the contents of the report before making it available. This suggestion doesn't really feel credible when it contains nearly 400 MB of data to look at. IMHO we have to assume that any sosreport we receive will not have been scrubbed and thus be full of sensitive information. Some might say that we already ask users to attach sensitive info to bugs routinely, so how is this different ? To some extent that is correct. As maintainers we often ask for logs, config files, and so on that can contain sensitive information. The difference though, IMHO, is the scale. A single file request is easily examined by the bug reporter to check if they'd be exposing something sensitive. It is also a proportionate amount of information to request for the task of investigating a bug. A sosreport contains a tonne of useful info, but for any single bug the vast majority is irrelevant. So it is much harder to argue that requesting this sos report info is proportionate for solving bugs from Fedora users, especially when attachments default to public and never expire. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Tom Deseyn
Tom, Per Omair Majid’s request[1], I have sponsored you to the packager group via the co-maintainer path. Welcome to Fedora, and happy packaging! – Ben Beasley https://pagure.io/packager-sponsors/issue/504 On 12/14/21 10:42, Tom Deseyn wrote: Hi everyone! My name is Tom. I work on .NET and try to make it work well/better on Linux. I maintain a few .NET libraries for interacting with D-Bus, systemd. I'm joining the list because I'd like to help Omair Majid maintain Fedora's .NET packages. Thanks. Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Raising the attachment size limit in bugzilla?
Most Bugzilla attachments are highly-compressible text. Are they currently stored in compressed form, and if not, would that be practical to implement? If feasible and not already implemented, this would vastly reduce long-term storage requirements, at a CPU cost that could be made as low as necessary by appropriate choice of algorithm and parameters. – Ben Beasley On 12/14/21 11:25, Carlos O'Donell wrote: On 12/14/21 10:16, Robbie Harwood wrote: Carlos O'Donell writes: - Life-cycle management (delete attachments). Please don't delete attachments. It severely reduces the usefulness of keeping old bugzillas around - if we're going to do that, we might as well delete the old bugzilla entries as well, and I don't think anyone wants that. I noted "life-cycle management" specifically so we could have a discussion about the topic. Choosing one way or the other has costs and consequences. Without data from bugzilla about the total size, growth rate of attachments, and cost of storage, it's hard to decide on a real life-cycle policy. To say "we must keep it all" needs some very specific qualification, because often the older the bugzilla the less useful it is because it no longer matches existing in-use code. Yes, it is nice for archaeology, but is it sufficiently nice that we would prioritize it *over* the needs of Fedora users today to upload SOS reports? Two positions could arise, given a fixed budget for storage: (a) We keep attachments forever, but users can't upload SOS reports. (b) We keep attachments for a reasonable amount of time, and users can upload SOS reports. If I understand your data retention policy correctly it looks like this: - Maximize usefulness. - Priority is to existing and new <19.5MiB attachments? - What about the priority to users and their ability to upload SOS reports? - Consequence: Keep data forever and pay for that storage? Do you have any thoughts on archiving attachments older than a certain age into some kind of slow access / low cost / cold storage via a bugzilla URL attachment? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Raising the attachment size limit in bugzilla?
On 12/14/21 10:16, Robbie Harwood wrote: > Carlos O'Donell writes: > >> - Life-cycle management (delete attachments). > > Please don't delete attachments. It severely reduces the usefulness of > keeping old bugzillas around - if we're going to do that, we might as > well delete the old bugzilla entries as well, and I don't think anyone > wants that. I noted "life-cycle management" specifically so we could have a discussion about the topic. Choosing one way or the other has costs and consequences. Without data from bugzilla about the total size, growth rate of attachments, and cost of storage, it's hard to decide on a real life-cycle policy. To say "we must keep it all" needs some very specific qualification, because often the older the bugzilla the less useful it is because it no longer matches existing in-use code. Yes, it is nice for archaeology, but is it sufficiently nice that we would prioritize it *over* the needs of Fedora users today to upload SOS reports? Two positions could arise, given a fixed budget for storage: (a) We keep attachments forever, but users can't upload SOS reports. (b) We keep attachments for a reasonable amount of time, and users can upload SOS reports. If I understand your data retention policy correctly it looks like this: - Maximize usefulness. - Priority is to existing and new <19.5MiB attachments? - What about the priority to users and their ability to upload SOS reports? - Consequence: Keep data forever and pay for that storage? Do you have any thoughts on archiving attachments older than a certain age into some kind of slow access / low cost / cold storage via a bugzilla URL attachment? -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Raising the attachment size limit in bugzilla?
On a related note - could we increase the size limit for FTBFS tickets? Currently, the when FTBFS bugs are filed, the attachments are limited to 32KiB, which is often too small to fit the whole build log. The whole point of attaching these to the bugzilla ticket is that koji deletes logs after some time, and the attachments are meant to provide a non-ephemeral copy. But when said copy is truncated, it often ends up being of little use, leading one to re-submit the broken build to koji just to get new copies of the full logs. A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032424] perl-Crypt-X509 for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032424 --- Comment #2 from Xavier Bachelot --- Fine by me, my FAS username is xavierb. I have filed quite a number of bugs requesting perl modules for EPEL 9 in the last few days, and I believe several are assigned to you. I'd be grateful if you could grant me rights on them so I can request the branches and do the builds. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032424 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Requesting branches for epel9
On Tue, Dec 14, 2021 at 06:31:04AM -0500, Stephen John Smoogen wrote: > > Where is that checklist? I found > I don't know myself. Fair -- a lot of this stuff is individual experience and wisdom that we haven't recorded, but need to. > > But it seems like "request an EPEL branch" should generally be either "Okay! > > Doing that automatically now" or "Oh, this is in EL, sorry"*. What are the > > other cases? > > As far as I know this isn't about requesting EPEL branches, as much as > requesting any branches by hand. If I add something to Fedora rawhide > and then ask for a F34 branch, the same issues can happen. Remember > our build infrastructure is a pile of band-aids on top of duct tape on > top of bungee cords. Lots of tools are written for a toolchain which > existed years ago and have been hacked to make it work with whatever > new initiative that comes into play. 'Unexpected' side effects and > corner cases happen all the time and the fixing of them tends to add > new ones. Sure. But also, asking people to spend a lot of their time running grunt-work tasks means that they have less time to fix when things break, let alone re-engineer away some of that tech debt. It seems like we should be able to automate the simple cases (adding F34 and F35 branches should be even easier, since we don't have the "is it in EL?" question even). -- Matthew Miller Fedora Project Leader ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032424] perl-Crypt-X509 for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032424 Ralf Corsepius changed: What|Removed |Added Doc Type|--- |If docs needed, set a value --- Comment #1 from Ralf Corsepius --- (In reply to Xavier Bachelot from comment #0) > Could you please branch and build perl-Crypt-X509 for EPEL 9 ? Feel free to do it youself. I do not use RHEL and refuse to support RHAT's non-free products. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032424 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pipewire memory usage
On 12/14/21 07:08, Dominique Martinet wrote: > I've double-checked with traces in load_spa_handle/unref_handle and it > is all free()d as soon as the client disconnects, so there's no reason > the memory would still be used... And I think we're just looking at some > malloc optimisation not releasing the memory. > > To confirm, I've tried starting pipewire-pulse with jemalloc loaded, > LD_PRELOAD=/usr/lib64/libjemalloc.so , and interestingly after the 100 > clients exit the memory stays at ~3-400MB but as soon as single new > client connects it jumps back down to 20MB, so that seems to confirm it. > (with tcmalloc it stays all the way up at 700+MB...) > So I guess we're just chasing after artifacts from the allocator, and > it'll be hard to tell which it is when I happen to see pipewire-pulse > with high memory later on... It can be difficult to tell the difference between: (a) allocator caching (b) application usage To help with we developed some additional tracing utilities: https://pagure.io/glibc-malloc-trace-utils The idea was to get a full API trace of malloc family calls and then play them back in a simulator to evaluate the heap/arena usage when threads were involved. Knowing the exact API calls lets you determine if you have (a), where the API calls show a small usage but in reality RSS is higher, or (b) where the API calls show there are some unmatched free()s and the usage is growing. It seems like you used jemalloc and then found that memory usage stays low? If that is the case it may be userspace caching from the allocator. jemalloc is particularly lean with a time-decay thread that frees back to the OS in order to reduce memory usage down to a fixed percentage. The consequence of this is that you get latency on the allocation side, and the application has to take this into account. > From what I can see the big allocations are (didn't look at lifetime of each > alloc): > - load_spa_handle for audioconvert/libspa-audioconvert allocs 3.7MB > - pw_proxy_new allocates 590k > - reply_create_playback_stream allocates 4MB > - spa_buffer_alloc_array allocates 1MB from negotiate_buffers > - spa_buffer_alloc_array allocates 256K x2 + 128K >from negotiate_link_buffers On a 64-bit system the maximum dynamic allocation size is 32MiB. As you call malloc with ever larger values the dynamic scaling will scale up to at most 32MiB (half of a 64MiB heap). So it is possible that all of these allocations are placed on the mmap/sbrk'd heaps and stay there for future usage until freed back. Could you try running with this env var: GLIBC_TUNABLES=glibc.malloc.mmap_threshold=131072 Note: See `info libc tunables`. > maybe some of these buffers sticking around for the duration of the > connection could be pooled and shared? They are pooled and shared if they are cached by the system memory allocator. All of tcmalloc, jemalloc, and glibc malloc attempt to cache the userspace requests with different algorithms that match given workloads. -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032511] Please branch and build perl-Modern-Perl in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032511 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/39560 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032511 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-12-15 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic EPEL-9 #topic Openfloor #endmeeting Source: https://calendar.fedoraproject.org//meeting/9854/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Self Introduction: Tom Deseyn
Hi everyone! My name is Tom. I work on .NET and try to make it work well/better on Linux. I maintain a few .NET libraries for interacting with D-Bus, systemd. I'm joining the list because I'd like to help Omair Majid maintain Fedora's .NET packages. Thanks. Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032513] New: Please branch and build perl-Sys-Virt in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032513 Bug ID: 2032513 Summary: Please branch and build perl-Sys-Virt in epel9 Product: Fedora Version: rawhide Status: NEW Component: perl-Sys-Virt Assignee: jples...@redhat.com Reporter: li...@cmadams.net QA Contact: extras...@fedoraproject.org CC: berra...@redhat.com, crobi...@redhat.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Please branch and build perl-Sys-Virt in epel9. If you do not wish to maintain perl-Sys-Virt in epel9, or do not think you will be able to do this in a timely manner, I would be happy to be a co-maintainer of the package. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032513 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: PostgreSQL 14 (Self-Contained Change proposal)
On Thu, Nov 25, 2021 at 16:52:59 -0500, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PostgreSQL_14 == Summary == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 13 to version 14 in the non-modular (main) builds. == Feedback == I'm all for it. I have been running PGDG Red Hat binaries for 14 for about 2 months on a RHEL machine at work and have not seen any issues. When it gets into Rawhide, I'll be testing it on a work desktop where I use Postgres to analyze data for some work tasks. There isn't any feature in this release that I am personally really looking forward to, but there are some performance related ones that could provide some immediate benefit. I do like being on the latest release in case something new I want to do would benefit from it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032512] New: Please branch and build perl-Switch in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032512 Bug ID: 2032512 Summary: Please branch and build perl-Switch in epel9 Product: Fedora Version: rawhide Status: NEW Component: perl-Switch Assignee: spo...@gmail.com Reporter: li...@cmadams.net QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Please branch and build perl-Switch in epel9. If you do not wish to maintain perl-Switch in epel9, or do not think you will be able to do this in a timely manner, I would be happy to be a co-maintainer of the package. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032512 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032511] New: Please branch and build perl-Modern-Perl in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032511 Bug ID: 2032511 Summary: Please branch and build perl-Modern-Perl in epel9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Modern-Perl Assignee: p...@city-fan.org Reporter: li...@cmadams.net QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Please branch and build perl-Modern-Perl in epel9. If you do not wish to maintain perl-Modern-Perl in epel9, or do not think you will be able to do this in a timely manner, I would be happy to be a co-maintainer of the package. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032511 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1977273] perl-XML-TreeBuilder for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1977273 Xavier Bachelot changed: What|Removed |Added Flags||needinfo?(rlandman@redhat.c ||om) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1977273 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032441] New: perl-Test-MockModule for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032441 Bug ID: 2032441 Summary: perl-Test-MockModule for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Test-MockModule Assignee: spo...@gmail.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-Test-MockModule for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032441 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1977273] perl-XML-TreeBuilder for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1977273 Andrew Bauer changed: What|Removed |Added CC||zonexpertconsulting@outlook ||.com --- Comment #2 from Andrew Bauer --- Would the package manager please respond to this request for build on el8. I would be glad to manage this package for epel branches if the packager manager desires. Thank you. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1977273 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Raising the attachment size limit in bugzilla?
Carlos O'Donell writes: > - Life-cycle management (delete attachments). Please don't delete attachments. It severely reduces the usefulness of keeping old bugzillas around - if we're going to do that, we might as well delete the old bugzilla entries as well, and I don't think anyone wants that. Be well, --Robbie 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Raising the attachment size limit in bugzilla?
The Fedora SOS reports are ~30MiB today, and this exceeds the Bugzilla attachment limit of 19.5MiB. Do we have the option to raise the attachment size to something that could accommodate the average SOS report limit for Fedora uses? I've had users report SOS tarballs that are ~60MiB in size which would mean we need a ~100MiB attachment limit (5x what we have today). This is a difficult problem to solve because we need: - Storage (real costs). - Life-cycle management (delete attachments). Comments? -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
On Tue, Dec 14, 2021 at 6:00 AM wrote: > > You are kindly invited to the meeting: >Prioritized bugs and issues on 2021-12-15 from 11:00:00 to 12:00:00 > America/Indiana/Indianapolis >At fedora-meetin...@libera.chat > > More information available at: > https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/ There are no nominated or accepted bugs, so tomorrow's meeting is canceled. The 29 December meeting is also canceled. If you have any bugs to nominate, we'll review them on Wednesday 12 January 2022. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032452] New: perl-Test-Perl-Critic for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032452 Bug ID: 2032452 Summary: perl-Test-Perl-Critic for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Test-Perl-Critic Assignee: p...@city-fan.org Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, rob.my...@gtri.gatech.edu Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-Test-Perl-Critic for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032452 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032450] New: perl-Test-LWP-UserAgent for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032450 Bug ID: 2032450 Summary: perl-Test-LWP-UserAgent for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Test-LWP-UserAgent Assignee: jples...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-Test-LWP-UserAgent for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032450 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032454] New: perl-UUID-Tiny for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032454 Bug ID: 2032454 Summary: perl-UUID-Tiny for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-UUID-Tiny Assignee: jples...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mhron...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-UUID-Tiny for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032454 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032447] New: perl-MooX-Types-MooseLike for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032447 Bug ID: 2032447 Summary: perl-MooX-Types-MooseLike for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-MooX-Types-MooseLike Assignee: emman...@seyman.fr Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-MooX-Types-MooseLike for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032447 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032440] New: perl-JSON-MaybeXS for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032440 Bug ID: 2032440 Summary: perl-JSON-MaybeXS for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-JSON-MaybeXS Assignee: p...@city-fan.org Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-JSON-MaybeXS for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032440 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032433] New: perl-namespace-sweep for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032433 Bug ID: 2032433 Summary: perl-namespace-sweep for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-namespace-sweep Assignee: rc040...@freenet.de Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-namespace-sweep for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032433 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032430] New: perl-Type-Tiny for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032430 Bug ID: 2032430 Summary: perl-Type-Tiny for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Type-Tiny Assignee: rc040...@freenet.de Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-Type-Tiny for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032430 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032428] New: perl-RDF-Trine for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032428 Bug ID: 2032428 Summary: perl-RDF-Trine for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-RDF-Trine Assignee: ppi...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-RDF-Trine for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032428 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032426] New: perl-RDF-Query for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032426 Bug ID: 2032426 Summary: perl-RDF-Query for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-RDF-Query Assignee: ppi...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-RDF-Query for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032426 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032425] New: perl-Moose for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032425 Bug ID: 2032425 Summary: perl-Moose for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Moose Assignee: p...@city-fan.org Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, lkund...@v3.sk, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-Moose for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032425 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032424] New: perl-Crypt-X509 for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032424 Bug ID: 2032424 Summary: perl-Crypt-X509 for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Crypt-X509 Assignee: rc040...@freenet.de Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Hi, Could you please branch and build perl-Crypt-X509 for EPEL 9 ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032424 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wxGTK-devel vs wxGTK3-devel
On 12/14/21 07:50 AM, Sérgio Basto wrote: On Mon, 2021-12-13 at 08:53 -0500, Steven A. Falco wrote: On 12/12/21 06:21 PM, Scott Talbert wrote: On Sun, 12 Dec 2021, Steven A. Falco wrote: I also noticed that python3-wxpython4 appears to require the 3.0 branch, so that might be what is causing both 3.0 and 3.1 of wxGTK to be dragged in: $ rpm -q --requires python3-wxpython4 ... libwx_baseu-3.0.so.0()(64bit) ... Is there a version of python3-wxpython4 that uses 3.1? I really don't want both wxGTK versions in the build. Yes, there is. However, the latest version bundles its own non- release copy of wxWidgets, and I don't believe it can be (easily) built unbundled with the current release of wxWidgets 3.1. So that's why I have been holding off packaging it. That, plus the 3.1.x variant of wxWidgets is a development release and not API/ABI stable. Perhaps it's worth reconsidering if there's a new release of wxPython that can use the latest released wxWidgets 3.1.x. Thanks very much for the reply, Scott. I'm not sure how critical it is to KiCad to make the switch, but I'll ask. I believe that the KiCad Mac, Windows, and Flatpack builds have already made the switch, but I don't know if the KiCad team make their own builds of wxWidgets / wxpython. Do you have a feel for when the 3.1 branch might stabilize enough to create a Fedora package? BTW from this thread https://sourceforge.net/p/dvdstyler/discussion/318795/thread/b40e1d871f/#84aa wxWidgets 3.1 isn't available in many distributions (debian, Ubuntu, archlinux, gentoo) and will never be packaged because 3.1 is a development version... https://trac.wxwidgets.org/wiki/Roadmap Good to know. Thanks, Sérgio. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wxGTK-devel vs wxGTK3-devel
On Mon, 2021-12-13 at 08:53 -0500, Steven A. Falco wrote: > On 12/12/21 06:21 PM, Scott Talbert wrote: > > On Sun, 12 Dec 2021, Steven A. Falco wrote: > > > > > I also noticed that python3-wxpython4 appears to require the 3.0 > > > branch, so that might be what is causing both 3.0 and 3.1 of wxGTK > > > to be dragged in: > > > > > > $ rpm -q --requires python3-wxpython4 > > > ... > > > libwx_baseu-3.0.so.0()(64bit) > > > ... > > > > > > Is there a version of python3-wxpython4 that uses 3.1? I really > > > don't want both wxGTK versions in the build. > > > > Yes, there is. However, the latest version bundles its own non- > > release copy of wxWidgets, and I don't believe it can be (easily) > > built unbundled with the current release of wxWidgets 3.1. So that's > > why I have been holding off packaging it. That, plus the 3.1.x > > variant of wxWidgets is a development release and not API/ABI > > stable. Perhaps it's worth reconsidering if there's a new release of > > wxPython that can use the latest released wxWidgets 3.1.x. > > Thanks very much for the reply, Scott. > > I'm not sure how critical it is to KiCad to make the switch, but I'll > ask. I believe that the KiCad Mac, Windows, and Flatpack builds have > already made the switch, but I don't know if the KiCad team make their > own builds of wxWidgets / wxpython. > > Do you have a feel for when the 3.1 branch might stabilize enough to > create a Fedora package? BTW from this thread https://sourceforge.net/p/dvdstyler/discussion/318795/thread/b40e1d871f/#84aa wxWidgets 3.1 isn't available in many distributions (debian, Ubuntu, archlinux, gentoo) and will never be packaged because 3.1 is a development version... https://trac.wxwidgets.org/wiki/Roadmap Best regards, -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pipewire memory usage
Wim Taymans wrote on Tue, Dec 14, 2021 at 09:09:30AM +0100: > I can get it as high as that too but then it stays there and doesn't really > grow anymore so it does not seem like > it's leaking. Maybe it's the way things are done, there is a lot of ldopen > and memfd/mmap. Right, I've had a look with massif and it looks like the memory is reused properly -- when the next batch of clients come in all previously used memory is freed and promptly reallocated for the new clients. The problem seems to be more that there is no sign of memory being released even after some time, I've left pipewire-pulse run for a while and it stays at 300ishMB of RSS all this time. Connecting a single new client at this point does increase memory (+8-9MB) so it doesn't look like it's reusing the old memory, but looking at massif the numbers all fell down close to 0 so everything -is- freed successfully... And it's a bit weird. FWIW, here's some massif output file if you're curious. I ran 100 clients, 100 clients, 1 client for a while, then 100 clients again: https://gaia.codewreck.org/local/massif.out.pipewire I've double-checked with traces in load_spa_handle/unref_handle and it is all free()d as soon as the client disconnects, so there's no reason the memory would still be used... And I think we're just looking at some malloc optimisation not releasing the memory. To confirm, I've tried starting pipewire-pulse with jemalloc loaded, LD_PRELOAD=/usr/lib64/libjemalloc.so , and interestingly after the 100 clients exit the memory stays at ~3-400MB but as soon as single new client connects it jumps back down to 20MB, so that seems to confirm it. (with tcmalloc it stays all the way up at 700+MB...) So I guess we're just chasing after artifacts from the allocator, and it'll be hard to tell which it is when I happen to see pipewire-pulse with high memory later on... That all being said, I agree with Zbigniew that the allocated amount per client looks big. From what I can see the big allocations are (didn't look at lifetime of each alloc): - load_spa_handle for audioconvert/libspa-audioconvert allocs 3.7MB - pw_proxy_new allocates 590k - reply_create_playback_stream allocates 4MB - spa_buffer_alloc_array allocates 1MB from negotiate_buffers - spa_buffer_alloc_array allocates 256K x2 + 128K from negotiate_link_buffers maybe some of these buffers sticking around for the duration of the connection could be pooled and shared? -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Requesting branches for epel9
On Mon, 13 Dec 2021 at 22:20, Matthew Miller wrote: > > On Mon, Dec 13, 2021 at 09:40:19AM -0500, Stephen John Smoogen wrote: > > It is a fairly manual process where a person volunteers to sit in > > front of the firehose every day and deal with these requests. The > > person who has to process them has a checklist of policy items they > > have to confirm/check to make sure the branch is possible. > > Where is that checklist? I found I don't know myself. > https://docs.pagure.org/releng/sop_process_dist_git_requests.html, but it > refers to a tool which is deprecated in favor of another one, at > https://pagure.io/fedscm-admin/, but none of those places have a clear > articulation of the policy items. > > I get human sanity check of new package requests is good, although really > ideally I would hope that wouldn't fall to the rel-eng/scm firehose > volunteers. > > But it seems like "request an EPEL branch" should generally be either "Okay! > Doing that automatically now" or "Oh, this is in EL, sorry"*. What are the > other cases? > As far as I know this isn't about requesting EPEL branches, as much as requesting any branches by hand. If I add something to Fedora rawhide and then ask for a F34 branch, the same issues can happen. Remember our build infrastructure is a pile of band-aids on top of duct tape on top of bungee cords. Lots of tools are written for a toolchain which existed years ago and have been hacked to make it work with whatever new initiative that comes into play. 'Unexpected' side effects and corner cases happen all the time and the fixing of them tends to add new ones. > > * I'm very sad that this isn't "So, would you like to do it anyway, and then > make a module?", but c'est la vie -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
HEADS UP: Update to tesseract-5.0.0 in rawhide
Hi I'll be updating to tesseract-5.0.0 in rawhide, I'll be rebuilding the following packages in the f36-build-side-48784 side-tag: gimagereader mupdf opencv python-PyMuPDF R-tesseract vapoursynth zathura-pdf-mupdf I already performed the rebuilds for testing in this copr repo [1]. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/tesseract5 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The New Hotness 1.0.0 deployed on production
Anitya doesn't removing versions on it's own. This needs to be done by admin. The filter is just for the new versions that are retrieved by Anitya. This should be fixed in the future when The New Hotness will learn to work with pre-releases. I also plan to add new option to src.fedoraproject.org to notify only about stable versions. Michal P.S.: I removed the beta versions from Anitya project for you. On 13. 12. 21 18:11, Fabio Valentini wrote: On Mon, Dec 13, 2021 at 11:41 AM Michal Konecny wrote: Do you have an example? Because this is a bug. If the project doesn't have some strange versioning scheme the stable should be still considered newer than pre-release and the message should be emitted and processed by The New Hotness. Here's an example: https://release-monitoring.org/project/141635/ After getting notifications for the first 2.0.0-beta releases, I added a version filter to exclude alpha;beta versions. But upstream kept releasing versions 1.9.0, 1.9.1, 1.9.2, etc. after that, which are not considered *newer* than the last 2.0.0-beta version anitya saw, so we don't get bugs for them. So this is not a problem with a strange versioning scheme, but with anitya not removing versions from its database, I guess. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031814] perl-Regexp-Assemble for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031814 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/39540 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031814 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031862] Please branch and build perl-Test-File-Contents for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031862 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/39539 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031862 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031819] perl-Test-Output for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031819 Jitka Plesnikova changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/39537 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031819 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031808] perl-Net-OpenID-Consumer for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031808 --- Comment #2 from Jitka Plesnikova --- (In reply to Jitka Plesnikova from comment #1) > https://pagure.io/releng/fedora-scm-requests/issue/39534 Wrong link https://pagure.io/releng/fedora-scm-requests/issue/39535 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031808 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031808] perl-Net-OpenID-Consumer for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031808 --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/39534 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031808 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pipewire memory usage
On Tue, Dec 14, 2021 at 09:09:30AM +0100, Wim Taymans wrote: > I can get it as high as that too but then it stays there and doesn't really > grow anymore so it does not seem like > it's leaking. Maybe it's the way things are done, there is a lot of ldopen > and memfd/mmap. This doesn't sound right. 340 *MB* is just too much. It might be useful to look at smem to get the USS: $ smem -P '\bpipewire' PID User Command Swap USS PSS RSS 2450 zbyszek /usr/bin/pipewire 2288225922326528700 2452 zbyszek /usr/bin/pipewire-pulse 3412 241784 242097 246924 So 241 MB of non-shared data seems like a lot. It seems like pipewire-pulse starts with reasonable memory use, but then grows quite a lot over time. (This is still with 0.3.40. I'm upgrading now and I'll report if this changes significantly.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032232] perl-Crypt-DH-GMP for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032232 --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/39531 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032232 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031809] perl-Net-OpenID-Server for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031809 --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/39533 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031809 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032231] perl-Net-OpenID-Common for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032231 --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/39532 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032231 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031809] perl-Net-OpenID-Server for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031809 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031809 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031808] perl-Net-OpenID-Consumer for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031808 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031808 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032261] perl-Math-BigInt-GMP for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032261 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/39530 I have to use Math-BigInt-GMP-1.6007, because newer version requires Math-BigInt >= 1.999819. RHEL 9 contains perl-Math-BigInt-1.9998.18. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032261 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211214.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211212.0): ID: 1086038 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1086038 ID: 1086049 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1086049 Passed openQA tests: 7/8 (aarch64), 7/8 (x86_64) New passes (same test not passed in Fedora-Cloud-34-20211212.0): ID: 1086046 Test: aarch64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1086046 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032261] New: perl-Math-BigInt-GMP for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032261 Bug ID: 2032261 Summary: perl-Math-BigInt-GMP for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Math-BigInt-GMP Assignee: jples...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, st...@silug.org Blocks: 2032232 Target Milestone: --- Classification: Fedora Please branch and build perl-Math-BigInt-GMP for EPEL 9. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032232 [Bug 2032232] perl-Crypt-DH-GMP for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032261 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032232] perl-Crypt-DH-GMP for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032232 Jitka Plesnikova changed: What|Removed |Added Depends On||2032261 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032261 [Bug 2032261] perl-Math-BigInt-GMP for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032232 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20211214.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20211213.0): ID: 1086022 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1086022 ID: 1086033 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1086033 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032209] Branch and build perl-Crypt-Cracklib in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032209 Paul Howarth changed: What|Removed |Added Blocks||2032214 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032214 [Bug 2032214] Branch and build proftpd in epel9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032209 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032209] Branch and build perl-Crypt-Cracklib in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032209 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/39527 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032209 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032232] New: perl-Crypt-DH-GMP for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032232 Bug ID: 2032232 Summary: perl-Crypt-DH-GMP for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Crypt-DH-GMP Assignee: jples...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Blocks: 2032231 Target Milestone: --- Classification: Fedora Please branch and build perl-Crypt-DH-GMP for EPEL 9. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032231 [Bug 2032231] perl-Net-OpenID-Common for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032232 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032231] perl-Net-OpenID-Common for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032231 Jitka Plesnikova changed: What|Removed |Added Depends On||2032232 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032232 [Bug 2032232] perl-Crypt-DH-GMP for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032231 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pipewire memory usage
I can get it as high as that too but then it stays there and doesn't really grow anymore so it does not seem like it's leaking. Maybe it's the way things are done, there is a lot of ldopen and memfd/mmap. Wim On Mon, Dec 13, 2021 at 11:42 PM Dominique Martinet wrote: > Wim Taymans wrote on Mon, Dec 13, 2021 at 09:22:42AM +0100: > > There was a leak in 0.3.40 that could explain this, see > > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840 > > > > Upcoming 0.3.41 will have this fixed. At least I can't reproduce this > > anymore with the test you posted below. > > Thanks for testing! > > I've also taken the time of rebuilding pipewire from source (current > master, just on top of 0.3.41) but unfortunately it doesn't look like it > solves the issue here, so it must be something specific in my > environment. > > fresh start: > myuser 335184 1.0 0.0 56384 11596 ?S /opt/pipewire/bin/pipewire > myuser 335197 2.7 0.0 36000 11480 ?S /usr/bin/pipewire-media-session > myuser 335208 0.5 0.0 31312 6428 ?S /opt/pipewire/bin/pipewire-pulse > > after running 100 mpv like last time: > myuser 335184 5.3 0.3 174836 63360 ?S /opt/pipewire/bin/pipewire > myuser 335197 1.6 0.0 36708 12336 ?S /usr/bin/pipewire-media-session > myuser 335208 9.2 2.1 666020 341196 ? S /opt/pipewire/bin/pipewire-pulse > > > > `pactl stat` is happy though: > Currently in use: 89 blocks containing 3.4 MiB bytes total. > Allocated during whole lifetime: 89 blocks containing 3.4 MiB bytes total. > Sample cache size: 0 B > > I've run out of free time this morning but since it's not a known issue > I'll debug this a bit more after getting home tonight and report an > issue proper. > Since it's easy to reproduce here I'm sure I'll find the cause in no > time... > > -- > Domnique > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031808] perl-Net-OpenID-Consumer for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031808 Jitka Plesnikova changed: What|Removed |Added Depends On||2032231 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032231 [Bug 2032231] perl-Net-OpenID-Common for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031808 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032231] New: perl-Net-OpenID-Common for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032231 Bug ID: 2032231 Summary: perl-Net-OpenID-Common for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Net-OpenID-Common Assignee: jples...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Blocks: 2031808, 2031809 Target Milestone: --- Classification: Fedora Please branch and build perl-Net-OpenID-Common for EPEL 9. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2031808 [Bug 2031808] perl-Net-OpenID-Consumer for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2031809 [Bug 2031809] perl-Net-OpenID-Server for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032231 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031809] perl-Net-OpenID-Server for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031809 Jitka Plesnikova changed: What|Removed |Added Depends On||2032231 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032231 [Bug 2032231] perl-Net-OpenID-Common for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031809 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032209] New: Branch and build perl-Crypt-Cracklib in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2032209 Bug ID: 2032209 Summary: Branch and build perl-Crypt-Cracklib in epel9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Crypt-Cracklib Assignee: p...@city-fan.org Reporter: ngomp...@gmail.com QA Contact: extras...@fedoraproject.org CC: c...@redhat.com, daxel...@datto.com, dcava...@fb.com, fed...@danonline.net, fed...@red-dragon.com, m...@1eanda.com, mic...@michel-slm.name, p...@city-fan.org, perl-devel@lists.fedoraproject.org Blocks: 1914423 (EPELPackagersSIG) Target Milestone: --- Classification: Fedora Please branch and build perl-Crypt-Cracklib in epel9. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1914423 [Bug 1914423] Tracker for epel-packagers-sig -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032209 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
