[Bug 2053941] The Fedora BuildRequires is missing an the license files are listed as %doc
https://bugzilla.redhat.com/show_bug.cgi?id=2053941 Petr Pisar changed: What|Removed |Added Version|35 |36 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2053941 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned gtkhtml3
Hi there, I just orphaned gtkhtml3 [1]. It used to be used by Evolution many years ago. It's unmaintained and archived upstream since Evolution moved to the WebKitGTK. The only user of it is xiphos, whose maintainer I added to the CC. They can take it, if they want to. Bye, Milan [1] https://src.fedoraproject.org/rpms/gtkhtml3 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Need help with disappeared update from repository
Hi all, It seems update fcitx5-qt-5.0.16-2.fc37 from [1] somehow did not make it to stable repository while other package in same update did. This caused broken dependences during update [2]. Seems that bodhi is doing something weird. I might have an idea how this happened.]: I decided to update fcitx5-qt to 5.0.16 and created a update [3] containing fcitx5-qt-5.0.16-1.fc37, during [3] waiting to make it to stable, qt6 rebuild happens and created another update with fcitx5-qt-5.0.16-2.fc37 [1]. [1] gets a lot karma and pushed to stable soon. And when [3] gets pushed afterwards, somehow fcitx5-qt-5.0.16- 1.fc37 overrides fcitx5-qt-5.0.16-2.fc37. I don't know if this behavior should be considered as a bug, but anyway, it seems that manual override from releng is needed to fix the broken dependencies. Cheers, Qiyu Yan [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9821716191 [2]: https://github.com/fcitx/fcitx5/issues/678 [3]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-729ae0f3ae ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump
Petr Pisar wrote: > Funilly, kdepimlibs-gpgme already provides a copy of an older > libqgpgme.so.1. That is a Qt 4 qgpgme. The Qt 5 port, initially released the same way by KDE, was eventually upstreamed from KDE into gpgme and is hence no longer available as a separate package from KDE (and a compatibility package for that one was not needed because all the affected Qt5/KF5 applications were able to be built against the qgpgme from upstream gpgme). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenCOLLADA dead upstream
Richard Shaw wrote: > Before we go ripping it out of Fedora, Just because a project is dead upstream does not mean it has to be removed from Fedora. > is anyone aware of another active upstream we can port to? Since this is a library, not a leaf package, that would have to happen before we can even consider removing the package from Fedora. > It looks like the only direct consumer is Blender (cc'd). So Blender upstream would have to move to something different. Please take it up with the upstream Blender project. As long as Blender depends on OpenCOLLADA, OpenCOLLADA should remain in Fedora. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
On Thu, Nov 10, 2022 at 8:24 PM Ben Cotton wrote: > === Items in progress === > * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F38 > * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F37 > * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F36 > * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F35 > * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in RHEL 9 > * Update [[Packaging:Perl | Fedora Packaging Guidelines for Perl]] > * Replace ''perl(:MODULE_COMPAT_XXX)'' by `%perl_require_compat` > run-time in all F38 spec files (3259) For those of us that prefer linear (and release agnostic) spec files, could the %perl_require_compat macro for el7, and el8, simply map to the classic MODULE_COMPAT... syntax without the need for expression expansion (no improvement, but no regression, either)? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149242] perl-Devel-NYTProf in EPEL 8 (present in EPEL 5,6,7)
https://bugzilla.redhat.com/show_bug.cgi?id=2149242 --- Comment #5 from Fedora Update System --- FEDORA-EPEL-2022-289cf1db38 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-2022-289cf1db38 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=2149242 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149242] perl-Devel-NYTProf in EPEL 8 (present in EPEL 5,6,7)
https://bugzilla.redhat.com/show_bug.cgi?id=2149242 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-5872ac4a43 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-2022-5872ac4a43 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=2149242 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-322b4e0cd3 advancecomp-2.4-1.el9 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f6c990ebdd qpress-20220819-1.el9 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8f2df2e1e2 botan2-2.19.3-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing flamegraph-1.0-12.20220917gitd9fcc27.el9 kde-partitionmanager-21.12.2-2.el9 kpmcore-21.12.3-2.el9 perl-CPAN-02Packages-Search-0.002-1.el9 perl-Devel-NYTProf-6.12-1.el9 pulseaudio-qt-1.3-2.el9.1 python-colorclass-2.2.2-1.el9 python-specfile-0.10.0-1.el9 qt-creator-7.0.2-2.el9 singularity-ce-3.10.4-1.el9 woff-0.20091126-35.el9 Details about builds: flamegraph-1.0-12.20220917gitd9fcc27.el9 (FEDORA-EPEL-2022-8aeeab0e44) Stack trace visualizer Update Information: Added the package to EPEL . ChangeLog: * Wed Nov 2 2022 Jerry James - 1.0-12 - Update to git HEAD for various enhancements and bug fixes * Tue Aug 16 2022 Jerry James - 1.0-11 - Convert License tags to SPDX * Thu Jul 21 2022 Fedora Release Engineering - 1.0-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 1.0-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Wed Oct 6 2021 Jerry James - 1.0-9.20210830git810687f - Update to git HEAD for various enhancements and bug fixes - Use the forge macros * Wed Jul 21 2021 Fedora Release Engineering - 1.0-8.20200729.a258e78 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 1.0-7.20200729.a258e78 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild References: [ 1 ] Bug #2149271 - Add flamegraph to EPEL 8/9 https://bugzilla.redhat.com/show_bug.cgi?id=2149271 kde-partitionmanager-21.12.2-2.el9 (FEDORA-EPEL-2022-2b6af2e158) KDE Partition Manager Update Information: Update for epel9 ChangeLog: * Tue Nov 29 2022 Troy Dawson - 21.12.2-2 - Rebuild for epel9 * Mon Feb 14 2022 Marc Deop - 21.12.2-1 - 21.12.2 * Thu Jan 20 2022 Fedora Release Engineering - 21.12.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild kpmcore-21.12.3-2.el9 (FEDORA-EPEL-2022-2b6af2e158) Library for managing partitions by KDE programs Update Information: Update for epel9 ChangeLog: * Tue Nov 29 2022 Troy Dawson - 21.12.3-2 - Rebuild for epel9 * Thu Mar 3 2022 Marc Deop - 21.12.3-1 - 21.12.3 * Mon Feb 14 2022 Marc Deop - 21.12.2-1 - 21.12.2 * Thu Jan 20 2022 Fedora Release Engineering - 21.12.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild perl-CPAN-02Packages-Search-0.002-1.el9 (FEDORA-EPEL-2022-e2e5918844) Search Perl modules in 02packages.details.txt Update Information: This update brings a new perl-CPAN-02Packages-Search package, which can search modules in 02packages.details.txt CPAN metadata. ChangeLog: * Thu Nov 3 2022 Petr Pisar - 0.002-1 - 0.002 bump * Fri Jul 22 2022 Fedora Release Engineering - 0.001-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Wed Jun 1 2022 Jitka Plesnikova - 0.001-5 - Perl 5.36 rebuild * Thu Jan 20 2022 Fedora Release Engineering - 0.001-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 0.001-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Fri May 21 2021 Jitka Plesnikova - 0.001-2 - Perl 5.34 rebuild * Wed Feb 24 2021 Petr Pisar 0.001-1 - Specfile autogenerated by cpanspec 1.78.
[Bug 2143423] Please branch and build perl-Net-Pcap in epel9.
https://bugzilla.redhat.com/show_bug.cgi?id=2143423 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-Net-Pcap-0.20-4.el9 Status|ON_QA |CLOSED Last Closed||2022-12-01 03:04:23 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-0594961239 has been pushed to the Fedora EPEL 9 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=2143423 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-10049c7b14 libbsd-0.11.7-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing golang-1.18.4-1.el7 singularity-ce-3.10.4-1.el7 woff-0.20091126-11.el7 Details about builds: golang-1.18.4-1.el7 (FEDORA-EPEL-2022-96dbad9cd3) The Go Programming Language Update Information: Update to 1.18.4 by doing the equivalent changes as centos8-stream ChangeLog: * Wed Nov 30 2022 Dave Dykstra - 1.18.14-1 - Update to 1.18.4 by doing the equivalent changes as centos8-stream. References: [ 1 ] Bug #2149668 - Please update EPEL7 golang to 1.18 / 1.19 https://bugzilla.redhat.com/show_bug.cgi?id=2149668 singularity-ce-3.10.4-1.el7 (FEDORA-EPEL-2022-8e44f7a924) Application and environment virtualization Update Information: Initial packaging of SingularityCE 3.10.4 ChangeLog: * Wed Nov 30 2022 David Trudgian - 3.10.4-1 - Initial packaging of SingularityCE 3.10.4 woff-0.20091126-11.el7 (FEDORA-EPEL-2022-63588ab702) Encoding and decoding for Web Open Font Format (WOFF) Update Information: Fix a possible double free in woffEncode() ChangeLog: * Wed Nov 30 2022 Benjamin A. Beasley 0.20091126-11 - Improved summary and description * Wed Nov 30 2022 Benjamin A. Beasley 0.20091126-10 - Update License to SPDX * Tue Nov 29 2022 Benjamin A. Beasley - 0.20091126-6 - Clarify URL/Source situation, and do not claim to have a working source archive URL - General tidying of spec file; use modern macros and install HTML format description as documentation - Add hand-written man pages * Sun Jun 5 2022 Benson Muite - 0.20091126-5 - Source URL update * Mon Feb 19 2018 Parag Nemade - 0.20091126-4 - Add BuildRequires: gcc as per packaging guidelines ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenCOLLADA dead upstream
So it looks like the last commit was in 2018: https://github.com/KhronosGroup/OpenCOLLADA Before we go ripping it out of Fedora, is anyone aware of another active upstream we can port to? It's a shame as this was one of my first (if not my first) projects I packaged for Fedora over 10 years ago. It looks like the only direct consumer is Blender (cc'd). Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?
Just noting that initial wasm support also just got merged upstream for ghc 9.6. Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142661] perl-File-Edit-Portable-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142661 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2022-2ab2e684bf has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2ab2e684bf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2ab2e684bf 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=2142661 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Mon, Nov 21, 2022, at 10:20 AM, Jonathan Lebon wrote: > On Tue, Oct 25, 2022 at 12:43 PM Colin Walters wrote: >> - This proposal is explicitly trying to tie everything together. I think >> without the "bigger picture", it's actually *more* confusing. For example, >> just pushing the container images does little unless we invest in them as a >> derivation source and build tooling and docs around them. > > I agree it's helpful to discuss this at a higher level than the > individual pieces to make sense of it. But the proposal as is seems to > imply it will all be done in one cycle which I agree with Dusty is > very optimistic. I agree. > WDYT about introducing phases into the proposal? E.g. something like: > - phase 1 (f38): start pushing OSTree-based variants as container > images in Quay.io; users can opt into rebasing onto them > > - phase 2 (f39): automatically transition existing users to shipping > from Quay.io; users can opt out. > - phase 3 (f40): stop pushing OSTree repo updates entirely I'd agree that "stop pushing ostree repo updates" probably isn't going to happen in Fedora 38. Dunno, I guess we could try a f40 change that calls that out explicitly. > Some concerns about this have been raised upstream already around > whether hijacking the `dnf` command in that way could cause more > confusion than it's worth. ISTM like a cleaner approach would be to > build this out into `dnf` directly instead and have it drive > rpm-ostree. I agree with this longer term, though there's a *lot* of details here. We have the same problem with this that exists with dnf5 in that there are a *ton* of options that dnf exposes that we're unlikely to make work anytime soon. (A random example here is "-4 resolve to IPv4 addresses only" which seems tricky to plumb through the stack, particularly scoping in the container side). > It would be great to get feedback from the DNF maintainers about this > proposal and some of the ideas here. Agreed! I pinged them directly again but was hoping they'd see this Change and reply here. > I think this probably makes sense generally, but I'll note that for > Fedora CoreOS at least, the whole point is to have users' workloads > run in containers and decoupled from the host. E.g. we've gone to > great lengths to keep Python out for that reason (also, `cowsay` pulls > in Perl BTW :) ). Having non-finger compatibility with `dnf install -y > cowsay` was kind of a feature in that sense; it made users think twice > before falling into the same patterns as other systems. Now with this > and especially container layering, it gives more power to users but > weakens that messaging. This is true. But weakening that messaging (and making the technology more flexible) also *weakens the barriers* we've set up between "CoreOS" and other editions. (This topic gets confusing because we could be talking about the *build* side or the client side or both; I hope most people agree the CLI compatibility on the build side just makes sense) BTW I wanted to give an update here specifically regarding the "dnf image" bit - as of late, I've been working on a fresh new "bootc" CLI, see https://github.com/ostreedev/ostree-rs-ext/pull/412 and https://github.com/cgwalters/bootc and that may make more sense for the client side. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
I'm quite not sure how one would go about empirically measuring something like that - at least in the general case. It might be an interesting research topic. So no, unfortunately I don't really have hard evidence for this. I just know that of all the C libraries I've looked at, in my personal experience it seems to be a very common phenomenon to copy or reimplement code that in Rust you would just import and re-use. It's just a pattern that one notices frequently when it comes to C libraries, especially crossplatform ones that can't rely exclusively on the existence of a Linux-like package manager. If you want specific examples, the ones that pop to mind are: * zchunk and deltarpm both reimplement / "bundle" multiple different hashing algorithms * libcomps implements about 4 different relatively common data structures * GTK appears to contain a bundled, forked copy of the CRoaring library ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Should the policy documents better reflect real package maintenance practice?
On 2022-11-30 06:41, Eike Rathke wrote: Maybe I misunderstood. So you're agreeing that once Thunderbird does not support the N-1 ESR anymore then rebasing to N is wanted on release branches? Yes. In really explicit detail, see the message I sent at 2022-11-27, 23:42 (Pacific). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
Once upon a time, Daniel Alley said: > 100 C packages with 100 separate copies of sha256.c sitting in their source > trees (which seems like an entirely realistic comparison) You keep saying this - do you have any evidence that this is the case? -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
> I think almost all of these qualify as "Core system libraries that > pretty much everything depends on.". > Building their C dependencies from vendored copies (if that is even > supported) and statically linking them seems like a pretty bad idea in > almost all cases here, especially for things where the version of a > program on the "host" and the accompanying shared library should > match. Yes, we're in complete agreement. I'm not suggesting anything like that. Vendoring libraries like openssl is a bad idea. What I'm saying is that it's not very logically justified to say that just because core system libraries like openssl shouldn't be vendored, all vendoring is disallowed regardless of how small and focused they are or how few dependents they have. Because - most C libraries have "dark dependencies" that are effectively the same but worse, in some ways. Given the choice between 100 Rust packages vendoring 10 different copies of the sha256 crate and 100 C packages with 100 separate copies of sha256.c sitting in their source trees (which seems like an entirely realistic comparison), why would the latter be completely A-OK while the latter is completely disallowed? > But ... none of these "tiny" Rust crates are dynamically linked in > Fedora anyway - because Rust doesn't really support that? > So I fail to see your point there, unless you meant to say "C projects > don't 'bundle', they just often 'copy' some code into their > projects"? > > Fabio Yes, that's essentially what I'm saying. I feel like the "no bundling" policy draws distinctions that don't entirely make sense, especially when it comes to the small, focused leaf-node dependencies that people often complain about. Clearly the "left-pad" scenario is bad and should be avoided, but on the other hand is having 800 different linked list implementations, 500 different hash table implementations, 25 different half-baked XML parsers, really so much "better", or is it just what we're used to? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142661] perl-File-Edit-Portable-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142661 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2022-2ab2e684bf has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2ab2e684bf -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2142661 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, 2022-11-30 at 18:26 +, Simon Farnsworth via devel wrote: > On Wednesday, 30 November 2022 17:47:16 GMT Fabio Valentini wrote: > > On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote: > > > I feel like there is insufficient recognition of the extent to which C > > > libraries do "bundling". Not "bundling" in the sense of vendoring a > > > whole library, but in the sense of including one-off implementations of > > > basic data structures, configuration parsers, hashing algorithms, etc. I > > > would love to hear anyone argue that 100 different variations of > > > "sha256.c" across 100 different packages better follows the spirit of the > > > "no bundling" guidelines than a vendored crate named "sha256" with 100x > > > as many eyes on it, and a higher likelihood to actually be updated if a > > > problem is found. > > > > > > > > > > > Many of the tiny, "sprawling" Rust dependencies are like this - not all of > > > them of course, but many. > > > > But ... none of these "tiny" Rust crates are dynamically linked in > > Fedora anyway - because Rust doesn't really support that? > > So I fail to see your point there, unless you meant to say "C projects > > don't 'bundle', they just often 'copy' some code into their projects"? > > > I think the point he's making is that developers don't write common > functionality from scratch, in general. We reuse code from elsewhere. > > It's just that in C, I'll copy-and-paste code from the web into my library or > application, not necessarily even bothering with a full "vendoring", whereas > in Rust, I'll use the crc crate (say), or the base64 crate, or other simple > utility crate. > > The result is that I have N implementations of common functionality, each > with > its own unique quirks and security risks, in my C binaries; but my C binaries > have only a small number of dependencies. > > In Rust, however, I'm directly reusing the small utility crate, and while I > may use `cargo vendor` to import the crate's source into my tree, I'm > unlikely > to edit it. The result is that a Rust binary has a larger number of > dependencies than the equivalent C program, because I'm depending on a crate > instead of copy-and-pasting the code and "hiding" it from the packager. > > This is a challenge for Fedora: how do we cope with a world where instead of > having a few tens of dependencies, and a lot of copy-and-paste code, we have > hundreds of dependencies, but no copy-and-paste code? > > One answer is to say that Rust is bad for encouraging developers to depend on > small crates instead of copying-and-pasting "small" utilities around. > Another > (which you're doing a great job of) is to package up all the dependencies, > so > that we represent the true dependency tree in RPM. Yet another would be to > manually decide which dependencies get bundled, and which don't - doing the > same thing as the C world does to keep its dependency count down. This is a bit of a misleading characterization. - the amount of copying in C programs is overblown in my opinion (no data provided to back this up though) - dependency minimization for C programs/libraries is assumed but no data provided to back it up. - the dilemma is how to manage rust programs not to decide what to bundle or not, that's basically decided upstream Although there are certainly instances of copying/paste in C code, the vast majority of reuse comes through linking to utility libraries dynamically, which makes distro-level maintenance much easier because you have only once place to fix/rebuild/distribute when there are serious issues. The problems with Rust crates (or go modules, or any other "vendoring"), is that not only you have to go and find each place where a problematic crate was vendored; you also have to figure out, often under pressure, if the crate can simply be summarily updated or if you need a backport because the vendoring application can't cope with the semantic changes that happened in the problematic crate's new version. Multiply this by N packages using M different versions of the problematic crate. Although vendored crates can be tracked (this i much better than copy/pasting), with additional tooling, the distribution remains on the hook for solving the same problem in N packages, without easy coordination. Some upstream may be quick and do the work for you, some may not care, disappear etc... or are simply too slow for the urgency the distribution has leading potentially to diverging solutions ... Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wednesday, 30 November 2022 17:47:16 GMT Fabio Valentini wrote: > On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote: > > I feel like there is insufficient recognition of the extent to which C > > libraries do "bundling". Not "bundling" in the sense of vendoring a > > whole library, but in the sense of including one-off implementations of > > basic data structures, configuration parsers, hashing algorithms, etc. I > > would love to hear anyone argue that 100 different variations of > > "sha256.c" across 100 different packages better follows the spirit of the > > "no bundling" guidelines than a vendored crate named "sha256" with 100x > > as many eyes on it, and a higher likelihood to actually be updated if a > > problem is found. > > > > > > > Many of the tiny, "sprawling" Rust dependencies are like this - not all of > > them of course, but many. > > But ... none of these "tiny" Rust crates are dynamically linked in > Fedora anyway - because Rust doesn't really support that? > So I fail to see your point there, unless you meant to say "C projects > don't 'bundle', they just often 'copy' some code into their projects"? > I think the point he's making is that developers don't write common functionality from scratch, in general. We reuse code from elsewhere. It's just that in C, I'll copy-and-paste code from the web into my library or application, not necessarily even bothering with a full "vendoring", whereas in Rust, I'll use the crc crate (say), or the base64 crate, or other simple utility crate. The result is that I have N implementations of common functionality, each with its own unique quirks and security risks, in my C binaries; but my C binaries have only a small number of dependencies. In Rust, however, I'm directly reusing the small utility crate, and while I may use `cargo vendor` to import the crate's source into my tree, I'm unlikely to edit it. The result is that a Rust binary has a larger number of dependencies than the equivalent C program, because I'm depending on a crate instead of copy-and-pasting the code and "hiding" it from the packager. This is a challenge for Fedora: how do we cope with a world where instead of having a few tens of dependencies, and a lot of copy-and-paste code, we have hundreds of dependencies, but no copy-and-paste code? One answer is to say that Rust is bad for encouraging developers to depend on small crates instead of copying-and-pasting "small" utilities around. Another (which you're doing a great job of) is to package up all the dependencies, so that we represent the true dependency tree in RPM. Yet another would be to manually decide which dependencies get bundled, and which don't - doing the same thing as the C world does to keep its dependency count down. -- Simon Farnsworth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
On 30. 11. 22 19:07, Miro Hrončok wrote: The list of the packages which use MODULE_COMPAT and do not contain Perl directories are here [1]. [1] https://jplesnik.fedorapeople.org/perl-module-compat/only-compat-no-dirs Thanks, I will have a look. noarch packages would only require perl-libs instead of perl(:MODULE_COMPAT...) with %perl_require_compat. I've checked all noarch packages from the list: they already require /usr/bin/perl (which requires perl-libs and perl(:MODULE_COMPAT...)). The only exception is EekBoek which already requires perl-interpreter manually anyway (it also requires perl-generators which I don't understand). The arched packages from the list are a bit more complex than that. Some of them require libperl.so.5.36()(64bit) which is probably good enough. Some of them don't require perl(:MODULE_COMPAT_5.36.0) or anything perl-ish based on my query (e.g. asterisk, claws-mail or zypper) -- maybe I need to query a specific subpackge instead? Some fo them require /usr/bin/perl and I think would not need to require perl(:MODULE_COMPAT_5.36.0) even when not noarch. My (unverified) assumption is that the packages contains compiled executables, but no Perl modules. They probably only contain Perl script (e.g. docbook2X, emacspeak or freeradius). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review swaps
Hello fellow packagers, I'd like to ask your help for a handful of reviews. Most of them are Lua dependencies for the SILE Typesetter, any help is appreciated. I offer my help in exchange for reviews, I have experience with Java, Python, Lua, C and C++ packages. Best regards, Jonny Heggheim lua-fluent - Lua implementation of Project Fluent: https://bugzilla.redhat.com/show_bug.cgi?id=2142798 lua-cliargs - A command-line argument parser: https://bugzilla.redhat.com/show_bug.cgi?id=2143056 lua-vstruct - Lua library to manipulate binary data: https://bugzilla.redhat.com/show_bug.cgi?id=2143351 lua-cosmo - Safe templates for Lua: https://bugzilla.redhat.com/show_bug.cgi?id=2142671 lua-luarepl - REPL.lua a reusable Lua REPL written in Lua: https://bugzilla.redhat.com/show_bug.cgi?id=2143382 lua-linenoise - A binding for the linenoise command line library: https://bugzilla.redhat.com/show_bug.cgi?id=2143020 lua-cldr - Lua interface to Unicode CLDR data: https://bugzilla.redhat.com/show_bug.cgi?id=2142653 lua-zlib - Simple streaming interface to zlib for Lua: https://bugzilla.redhat.com/show_bug.cgi?id=2143050 lua-epnf - Extended PEG Notation Format (easy grammars for LPeg): https://bugzilla.redhat.com/show_bug.cgi?id=2142786 lua-utf8 - A UTF-8 support module for Lua: https://bugzilla.redhat.com/show_bug.cgi?id=2143391 lua-loadkit - Loadkit allows you to load arbitrary files within the Lua package path: https://bugzilla.redhat.com/show_bug.cgi?id=2143028 libertinus-fonts - The Libertinus Fonts project: https://bugzilla.redhat.com/show_bug.cgi?id=2149626 hack-fonts - A typeface designed for source code: https://bugzilla.redhat.com/show_bug.cgi?id=2149686 sile - The SILE Typesetter: https://bugzilla.redhat.com/show_bug.cgi?id=2149698 randomx - A proof-of-work algorithm that is optimized for general-purpose CPUs: https://bugzilla.redhat.com/show_bug.cgi?id=2078535 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
On 30. 11. 22 17:40, Jitka Plesnikova wrote:
MODULE_COMPAT is used for 1) Perl Modules and also 2) for packages which use
perl interpreter or libperl.so.
For the second case, the RPM dependency generator above does not work. These
packages may not contain
the Perl directories.
For now, I prefer to use the change describe in the proposal. It works for
all these cases.
Thanks for looking into it. I am not surprised that an RPM generator I
written in an email does not work out of the box for all the packages. It can
be enhanced. Do you have a specific example I can have a look at? Don't
packages using libperl.so already require a pretty specific soname version?
Do you think that saying something like this is generally a bad idea?
"""
Packages with Perl modules installed in %{perl_vendorlib} or
%{perl_vendorarch} will automatically gain dependency on perl-libs for pure
Perl modules or a dependency on perl(:MODULE_COMPAT_) for
libraries with compiled code.
Packages that require the Perl interpreter or libperl.so but do not install
modules to the aforementioned directories or explicitly link to
libperl.so. need to handle the dependency manually.
"""
To me, this still sounds like a massive improvement over both the status quo
and %perl_require_compat.
The dependency generator for this case should be following:
cat perlcompat.attr
%__perlcompat_requires() %{lua:
if macros[1]:match('.+%.so$') and macros.perl_version then
print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
else
print('perl-libs')
end
}
%__perlcompat_path
^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+
Should be the file add to perl-generators or perl-srpm-macros?
I'd say perl-generators considering %{perl_vendorarch} etc. is not even defined
in the default buildroot where perl-srpm-macros is intalled.
The file attributes rules are applied on each file separately, if I understand
it correctly.
It means that perl-libs and MODULE_COMPAT will be added for Perl modules with
compiled code,
because there are not only *.so files.
Correct. In theory, a global Lua table can be used to cache the results based
on %{name} and refuse to generate perl-libs dependency if the
perl(:MODULE_COMPAT_...) one was already generated but I don't think it would
work when the files appear in an unfortunate order. Also, probably not worth-it.
Is it acceptable to have both dependencies for these packages?
I don't see why not, they will both evaluate to the same package, so it should
not matter.
The list of the packages which use MODULE_COMPAT and do not contain Perl
directories are here [1].
[1] https://jplesnik.fedorapeople.org/perl-module-compat/only-compat-no-dirs
Thanks, I will have a look.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote: > > > Do I really need to explain this point? I think linking against system > > OpenSSL is *way better* than statically linking to a random vendored > > copy of it. > > There are maybe about 100-120 libraries for which this is obviously the case. > openssl, glibc, glib2, zlib, libxml2, libcurl, kde libraries, etc. Core > system libraries that pretty much everything depends on. Dynamically linking > such libraries has real benefits. > > For everything else though? No, not so much. These are actually all good examples of stuff that we dynamically link to. This is the (not 100% exhaustive) list of system libraries we always dynamically link to: - all GTK / GNOME libraries (dbus, freetype, fontconfig, atk, gdk-pixbuf, gdk, gtk3, gtk4, gio, glib2, graphene, gsk4, pango, cairo, gstreamer, etc.) - multimedia codecs / libraries (aom, dav1d, pipewire, pulseaudio, etc.) - crypto libraries (openssl, libsodium, nettle, curl) - compression libraries (bzip2, flate2, libz, lzma, zstd) - database connectors (libsqlite, libpq) - low-level device / storage libraries (devicemapper, libblkid) I think almost all of these qualify as "Core system libraries that pretty much everything depends on.". Building their C dependencies from vendored copies (if that is even supported) and statically linking them seems like a pretty bad idea in almost all cases here, especially for things where the version of a program on the "host" and the accompanying shared library should match. The only exception (that I know of) for "crate dependency built from vendored sources and statically linked" in Fedora right now is libgit2, because the version in Fedora is chronically outdated, and dealing with that has become very painful - and started to block some necessary updates to support more recent versions of Rust / cargo. > I feel like there is insufficient recognition of the extent to which C > libraries do "bundling". Not "bundling" in the sense of vendoring a whole > library, but in the sense of including one-off implementations of basic data > structures, configuration parsers, hashing algorithms, etc. I would love to > hear anyone argue that 100 different variations of "sha256.c" across 100 > different packages better follows the spirit of the "no bundling" guidelines > than a vendored crate named "sha256" with 100x as many eyes on it, and a > higher likelihood to actually be updated if a problem is found. > > Many of the tiny, "sprawling" Rust dependencies are like this - not all of > them of course, but many. But ... none of these "tiny" Rust crates are dynamically linked in Fedora anyway - because Rust doesn't really support that? So I fail to see your point there, unless you meant to say "C projects don't 'bundle', they just often 'copy' some code into their projects"? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Willing to unretire package: rust-starship
Fabio, What is so bad about the COPR package that can't be used in the main repo? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2053941] The Fedora BuildRequires is missing an the license files are listed as %doc
https://bugzilla.redhat.com/show_bug.cgi?id=2053941 --- Comment #3 from Frank Büttner --- Same for F36, but I can't set the version to 36. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2053941 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
> Do I really need to explain this point? I think linking against system > OpenSSL is *way better* than statically linking to a random vendored > copy of it. There are maybe about 100-120 libraries for which this is obviously the case. openssl, glibc, glib2, zlib, libxml2, libcurl, kde libraries, etc. Core system libraries that pretty much everything depends on. Dynamically linking such libraries has real benefits. For everything else though? No, not so much. I feel like there is insufficient recognition of the extent to which C libraries do "bundling". Not "bundling" in the sense of vendoring a whole library, but in the sense of including one-off implementations of basic data structures, configuration parsers, hashing algorithms, etc. I would love to hear anyone argue that 100 different variations of "sha256.c" across 100 different packages better follows the spirit of the "no bundling" guidelines than a vendored crate named "sha256" with 100x as many eyes on it, and a higher likelihood to actually be updated if a problem is found. Many of the tiny, "sprawling" Rust dependencies are like this - not all of them of course, but many. Torvalds has similar feelings: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=rcus...@mail.gmail.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149094] perl-Chart-2.403.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2149094 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Status|MODIFIED|CLOSED Last Closed||2022-11-30 16:46:56 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2149094 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
MODULE_COMPAT is used for 1) Perl Modules and also 2) for packages
which use perl interpreter or libperl.so.
For the second case, the RPM dependency generator above does not
work. These packages may not contain
the Perl directories.
For now, I prefer to use the change describe in the proposal. It
works for all these cases.
Thanks for looking into it. I am not surprised that an RPM generator I
written in an email does not work out of the box for all the packages.
It can be enhanced. Do you have a specific example I can have a look
at? Don't packages using libperl.so already require a pretty specific
soname version?
Do you think that saying something like this is generally a bad idea?
"""
Packages with Perl modules installed in %{perl_vendorlib} or
%{perl_vendorarch} will automatically gain dependency on perl-libs for
pure Perl modules or a dependency on
perl(:MODULE_COMPAT_) for libraries with compiled code.
Packages that require the Perl interpreter or libperl.so but do not
install modules to the aforementioned directories or explicitly link
to libperl.so. need to handle the dependency manually.
"""
To me, this still sounds like a massive improvement over both the
status quo and %perl_require_compat.
The dependency generator for this case should be following:
cat perlcompat.attr
%__perlcompat_requires() %{lua:
if macros[1]:match('.+%.so$') and macros.perl_version then
print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
else
print('perl-libs')
end
}
%__perlcompat_path
^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+
Should be the file add to perl-generators or perl-srpm-macros?
The file attributes rules are applied on each file separately, if I
understand it correctly.
It means that perl-libs and MODULE_COMPAT will be added for Perl modules
with compiled code,
because there are not only *.so files.
Is it acceptable to have both dependencies for these packages?
The list of the packages which use MODULE_COMPAT and do not contain Perl
directories are here [1].
[1] https://jplesnik.fedorapeople.org/perl-module-compat/only-compat-no-dirs
Jitka
--
Jitka Plesnikova
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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, report it:
https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-POE] PR #3: Update license to SPDX format
mspacek merged a pull-request against the project: `perl-POE` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-POE/pull-request/3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
Dne 28. 11. 22 v 19:20 Mattia Verga via devel napsal(a): - rpms/python-copr-common - rpms/python-flask-whooshee Taken. M. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-POE] PR #3: Update license to SPDX format
mspacek opened a new pull-request against the project: `perl-POE` that you are following: `` Update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-POE/pull-request/3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: epel-next repo cleanup (both 8 and 9)
On Wed, Nov 30, 2022 at 10:24 AM Troy Dawson wrote:
>
> I have cleaned up the epel-next (both 8 and 9) repo's.
>
> If a package was newer in regular epel than in epel-next, the epel-next
> package was untagged from epel{8,9}-next.
>
> If a package was the same version-release in both epel and epel-next, I made
> sure the epel version was installable on CentOS Stream {8,9}, I also checked
> that the epel-next branches were the same as the epel branch, I also checked
> to see your building style. If everything pointed to "remove it from
> epel-next", I untagged the epel-next package from epel{8,9}-next.
>
> If the epel-next package was newer than what's in epel, I left them alone.
>
> The vast majority of the cleanup happened yesterday, so you should be able to
> see a smaller epel-next repo now.
>
> If I untagged a package that you feel should be in epel-next, let me know in
> the next week or two and I can tag them back.
> If I missed your package and you want me to untag it, also let me know.
Thanks for this Troy!
--
真実はいつも一つ！/ Always, there's only one truth!
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: qt6ct: warning: source_date_epoch_from_changelog set but %changelog is missing
On Wed, 2022-11-30 at 15:32 +, Martin Gansser wrote: > Sorry, I forgot to set the month in the changelog. you can use rpmdev-bumpspec that make changelog entry for you for example: rpmdev-bumpspec -c "Fix something " clamav.spec -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149094] perl-Chart-2.403.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2149094 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Chart-2.403.9-1.fc38 --- Comment #1 from Petr Pisar --- An enhancement release suitable for Fedora ≥ 38. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2149094 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: qt6ct: warning: source_date_epoch_from_changelog set but %changelog is missing
Sorry, I forgot to set the month in the changelog. Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] epel-next repo cleanup (both 8 and 9)
I have cleaned up the epel-next (both 8 and 9) repo's.
If a package was newer in regular epel than in epel-next, the epel-next
package was untagged from epel{8,9}-next.
If a package was the same version-release in both epel and epel-next, I
made sure the epel version was installable on CentOS Stream {8,9}, I also
checked that the epel-next branches were the same as the epel branch, I
also checked to see your building style. If everything pointed to "remove
it from epel-next", I untagged the epel-next package from epel{8,9}-next.
If the epel-next package was newer than what's in epel, I left them alone.
The vast majority of the cleanup happened yesterday, so you should be able
to see a smaller epel-next repo now.
If I untagged a package that you feel should be in epel-next, let me know
in the next week or two and I can tag them back.
If I missed your package and you want me to untag it, also let me know.
Troy
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149094] perl-Chart-2.403.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2149094 Petr Pisar changed: What|Removed |Added Doc Type|--- |If docs needed, set a value CC|ppi...@redhat.com | Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2149094 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2148773] perl-Prima-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2148773 Petr Pisar changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |RAWHIDE Last Closed||2022-11-30 15:20:37 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148773 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149242] perl-Devel-NYTProf in EPEL 8 (present in EPEL 5,6,7)
https://bugzilla.redhat.com/show_bug.cgi?id=2149242 --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-289cf1db38 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-289cf1db38 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2149242 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149242] perl-Devel-NYTProf in EPEL 8 (present in EPEL 5,6,7)
https://bugzilla.redhat.com/show_bug.cgi?id=2149242 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2022-5872ac4a43 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5872ac4a43 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2149242 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Should the policy documents better reflect real package maintenance practice?
Hi Gordon, On Monday, 2022-11-28 08:21:31 -0800, Gordon Messmer wrote: > On 2022-11-28 07:36, Eike Rathke wrote: > > > I would much prefer to see Thunderbird updated early in > > > Rawhide and releases that are not yet final, but to remain on the older > > > stable version for as long as possible on any Fedora release that had > > > included it. > > That'd be a problem though because ~every Thunderbird x.y.0 release > > includes security fixes, which are not backported to older then > > unmaintained ESR releases by Mozilla. > > I don't understand... When I said that I'd prefer to see Fedora remain on > the older stable version "for as long as possible", I meant "for as long as > Mozilla continues publishing security fixes for that release", which should > be at least 12 weeks after a new stable release series (x.y.0) starts. Maybe I misunderstood. So you're agreeing that once Thunderbird does not support the N-1 ESR anymore then rebasing to N is wanted on release branches? Eike -- GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Willing to unretire package: rust-starship
On Wed, Nov 30, 2022 at 2:13 PM Mauricio Teixeira wrote: > > Hello folks, > > Following up on the steps provided by the documentation [1], I would like to > announce that I am willing to unretire the package rust-starship [2]. I use > this app on a daily basis, and it seems like the previous maintainer is no > longer interested in keeping the package, so I would like to take over the > ownership. > > I will follow up on the remaining steps within the next few hours. > > Please, let me know if there is anything else I should know about. > > Thank you. Hi! Great to see that you're interested in resurrecting the starship package. However, maintaining it and keeping it up-to-date in Fedora requires a substantial amount of time, so you'd either have to familiarize yourself with Rust packaging (and most likely assume responsibility for ~a dozen library dependencies). The previous maintainer is a seasoned Fedora packager and didn't have the capacity to do that, so I'm not sure it's a good starting point for you: https://bugzilla.redhat.com/show_bug.cgi?id=2051601 If you'd like to use starship packages for Fedora, there's a COPR with unofficial packages (maintained by the same packager who originally maintained the package in Fedora) that should work fine but are built in a way that's not allowed for official Fedora packages: https://copr.fedorainfracloud.org/coprs/atim/starship/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned package "scratch"
I have orphaned package "scratch" https://src.fedoraproject.org/rpms/scratch The package is 1.x version of Scratch. Then was version 2 and now we have even version 3. All of them does not provide offline client for Linux. I used the version 1 in past in schools that have poor connection. But after the pandemic all school I know have good connection and good equipment and I am using the online version 3 all the time. If anyone wants to maintain the 1.x version feel free to take it. But be aware that the upstream is not maintained. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149651] New: perl-Module-Faker-0.023 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2149651 Bug ID: 2149651 Summary: perl-Module-Faker-0.023 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Module-Faker Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.023 Upstream release that is considered latest: 0.023 Current version/release in rawhide: 0.022-12.fc37 URL: http://search.cpan.org/dist/Module-Faker/ 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://docs.fedoraproject.org/en-US/package-maintainers/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/6989/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Module-Faker -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2149651 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-DBD-Pg] PR #1: Rebuild for PostgreSQL 15 (side-tag)
praiskup merged a pull-request against the project: `perl-DBD-Pg` that you are following. Merged pull-request: `` Rebuild for PostgreSQL 15 (side-tag) `` https://src.fedoraproject.org/rpms/perl-DBD-Pg/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-DBD-Pg] PR #1: Rebuild for PostgreSQL 15 (side-tag)
praiskup commented on the pull-request: `Rebuild for PostgreSQL 15 (side-tag)` that you are following: `` Going to merge now, and build against PostgreSQL 15 (proven packager action). `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-DBD-Pg/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, 30 Nov 2022 at 07:54, Daniel P. Berrangé wrote: > On Wed, Nov 30, 2022 at 11:54:10AM +, Peter Robinson wrote: > > Hi Fabio, > > > > Been meaning to reply to this, but it got lost in the mail pile. > > > > > > > But running `cargo fetch` with a clean cache pulls down *390* > crates. Of > > > > these, it looks like 199 (!) are already packaged as > rust-[crate]-devel, > > > > which is *amazing*. But... that still is hundreds that I'd have to > add. And > > > > mostly they are things I don't know _anything_ about. > > > > > > You must realize that this is an extreme case. For many Rust > > > applications that people want to package for Fedora, the number of > > > dependencies that are missing is rather small, *because* most popular > > > libraries are already packaged. > > > > In my experience, and I'm not packaging any form of gaming engine, > > it's not an extreme case, for a few small things and one slightly > > larger thing I *have* packaged I now maintain over 60 more packages. I > > have another one I want to package and AFAICT I get to package another > > 50-100 but frankly it's hard to tell, and this is something I have > > control over and have been actively trying to do upstream reduction of > > deps. > > The magnitude of the number of deps is the real killer for not > only Rust, but also Go, and arguably anything that isn't a C > based application. > > Packaging up all of a project's deps individually is viable when > there are a relatively small number of them, especially if most > of the deps are shared by other apps, and the libraries have good > API + ABI stability promises. This is common in the case of most > C applications/libraries, since shared libraries are relatively > speaking fairly broad in functional scope, and often long lived, > because that is the mindset of the C ecosystem in general. > > Modern languages & their ecosystems though have brought about > a world where the granularity of deps is way smaller, where > the focus is on being able to evolve rapidly, with less focus > on long term stable API/ABI, as apps are expected to just fix > against specific versions they've tested on. > > I wonder if we should look at the standard libraries in the late 1960/1970 languages as being the same as 'opinionated' Operating Systems. Most of them started out with a period where every mainframe might have a 'language' and a set of 'libraries' of routines but every site pretty much mangled them to fit their own 'local' needs. Software vendors which existed usually ended up having consultants go out to 'fix' their code to match whatever routines and tooling existed on each mainframe. This got to be unworkable and various 'libraries' were put forward which were to standardize things. However, going from the 'old war tales' my mentors and professors from that era, the same arguments that the current languages (Rust, etc) have against standards were existent. The issue was the scale of the problem was much more on the side of the hardware/OS vendors putting out a standard chosen library (and then fighting over getting those to match up for the software vendors who still needed to spend a lot of consulting time). Most of those arguments seem to have 'died' out as people got tired of fighting the differences versus the delight of new challenges that many programmers have when dealing with a 'new' language. [Same with C++ back in the late 1980's where every vendor had a slightly different set of libraries which for its proponents was the best thing over all the others.. and then by the late 1990's was 'Oh no, not this again'. Java went through this up until the late 00's. ] I don't think we are at the state where enough of the new people who are getting into Rust have gotten tired of fighting 'oh, I have to f'ing change my code again to make it work with these 4 things?' Basically when enough people HAVE to code in the language versus just 'WANT' to, but hate the grind.. ability to standardize is going to happen. > So functionality that lives in single library in C, often ends > up being spread across 20-200 modules in any of the modern > non-C languages. We've been experiancing this problem in Fedora > for a very long time and while we have spec auto-generators, > that still leaves masses of busy work, and also still leaves > the problem that what we ship doesn't match what upstream has > tested, so the result is often less reliable. > > IMHO the only thing that can make packaging such fine grained > modules sustainable long term, is if the process could be 100% > automated. I don't mean just having a tool to auto-generate > a spec file. It needs to be fully automated to the extent that > you just tell a robot "i need deps for this package" and it > does everything automatically, except for human approval of > the results of a code license audit. > > That of course would be a non-trivial service to build, and > it still begs the question of whether its really beneficial > in
[Bug 2148773] perl-Prima-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2148773 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-Prima-1.67-1.fc38 Status|ASSIGNED|MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148773 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, Nov 30, 2022 at 8:16 AM Fabio Valentini wrote: > > On Wed, Nov 30, 2022 at 12:54 PM Peter Robinson wrote: > > > > > This is true, and probably also not "fixable". We need to make some > > > amount of non-upstreamable patches to some crates (most notably, > > > removing Windows- or mac OS-specific dependencies, because we don't > > > want to package those), but in some cases, these are "incompatible" > > > changes, and Rust *developers* should not be targeting our downstream > > > sources that have these differences with actual upstream sources. > > > > Yet you say above "We *do* provide value to both users *and* > > developers" yet you say developers shouldn't be targeting that work? > > We provide value to developers by basically running a huge free CI > across a wide range of architectures. > > That doesn't mean that they should develop against crate sources we > have in Fedora, similarly to how upstream Python developers probably > should use pip/venv instead of "whatver is in Fedora". The same > applies to basically every language ecosystem except C/C++, where the > package manager story is just so bad that system libraries are > actually the only reliable development environment. > > > > This is due to a limitation of how cargo handles target-specific > > > dependencies - all dependencies that are *mentioned in any way* need > > > to be *present* for it to resolve dependencies / enabled optional > > > features / update its lockfile etc. But since we don't want to package > > > bindings for Windows and mac OS system APIs, we need to actually patch > > > them out, otherwise builds will fail. > > > > And that ends up being quite a bit of work from my point of view. Also > > the way the packaging works with options things like devel or optional > > features ends up being very painful. I will often drop out optional > > features just so I can do less packaging. > > Recent versions of rust2rpm automatically generate a patch to remove > non-linux dependencies, so that work has effectively been reduced to > zero. > Disabling unused optional dependencies can also be done with either a > rust2rpm config option or with a simple patch, so that should not be a > problem, either. I also don't understand why disabling some optional > features is such a bad thing? I don't think we have a policy in Fedora > that says we *must* enable *all possible functionality and optional > features*. > > > > > We're doing okay with #1, but... I think #3 _even_ with all of the work > > > > in > > > > Rust-to-RPM packaging isn't sufficient. I've played with the Bevy game > > > > engine and will probably have a few things it would be nice to package > > > > to > > > > make available in Fedora Linux. I might not even mind maintaining Bevy > > > > itself. > > > > > > Somebody actually already started packaging Bevy components - some > > > packages are already approved and some are still pending review. Not > > > sure what the progress has been there, but it's not *impossible*. > > > > Well nothing is *impossible* if you have enough stamina, resources or > > whatever else. I don't find saying something isn't *impossible* > > necessarily makes it compelling. > > I agree. And I think we can do better, as I said in my original post. > > > > > But running `cargo fetch` with a clean cache pulls down *390* crates. Of > > > > these, it looks like 199 (!) are already packaged as rust-[crate]-devel, > > > > which is *amazing*. But... that still is hundreds that I'd have to add. > > > > And > > > > mostly they are things I don't know _anything_ about. > > > > > > You must realize that this is an extreme case. For many Rust > > > applications that people want to package for Fedora, the number of > > > dependencies that are missing is rather small, *because* most popular > > > libraries are already packaged. > > > > In my experience, and I'm not packaging any form of gaming engine, > > it's not an extreme case, for a few small things and one slightly > > larger thing I *have* packaged I now maintain over 60 more packages. I > > have another one I want to package and AFAICT I get to package another > > 50-100 but frankly it's hard to tell, and this is something I have > > control over and have been actively trying to do upstream reduction of > > deps. > > As far as I know, salimma's intern worked on a tool to determine > missing dependencies for Rust projects in Fedora recursively, which > should make it easier to determine the exact set of things that you > would need to do here. > > > And requests to make things like this easier have been open for over a year: > > https://pagure.io/fedora-rust/rust2rpm/issue/140 > > Right. I'm sorry about the issue reports that have been open for a long time. > > rust2rpm / rust-packaging is an entirely community-run project. We > don't get any support from Red Hat (or other places) for anything > except the Rust compiler itself. And with the original developer of > rust2rpm (Igor) being gone, nobody
perl-Prima license change
perl-Prima-1.67 in Rawhide will change a license from BSD-2-Clause AND BSD-3-Clause AND BSD-4-Clause AND MIT-open-group AND HPND-sell-variant AND TCL AND ImageMagick AND LGPL-2.0-or-later AND AGPL-3.0-or-later to BSD-2-Clause AND BSD-3-Clause AND BSD-4-Clause AND MIT-open-group AND HPND AND HPND-sell-variant AND TCL AND ImageMagick AND LGPL-2.0-or-later AND AGPL-3.0-or-later -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
qt6ct: warning: source_date_epoch_from_changelog set but %changelog is missing
Hi, when compiling qt6ct with the spec file [1], i get the following warning at the end of the packaging build. + umask 022 + cd /home/martin/rpmbuild/BUILD + rm -rf qt6ct-0.7 qt6ct-0.7.gemspec + RPM_EC=0 ++ jobs -p + exit 0 RPM build warnings: source_date_epoch_from_changelog set but %changelog is missing How can i solve this ? [1] https://src.fedoraproject.org/rpms/qt6ct/blob/rawhide/f/qt6ct.spec Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2148773] perl-Prima-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2148773 --- Comment #1 from Petr Pisar --- New features, many code refactored, some modules split, some removed. Suitable only for Rawhide. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148773 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, Nov 30, 2022 at 12:54 PM Peter Robinson wrote: > > > This is true, and probably also not "fixable". We need to make some > > amount of non-upstreamable patches to some crates (most notably, > > removing Windows- or mac OS-specific dependencies, because we don't > > want to package those), but in some cases, these are "incompatible" > > changes, and Rust *developers* should not be targeting our downstream > > sources that have these differences with actual upstream sources. > > Yet you say above "We *do* provide value to both users *and* > developers" yet you say developers shouldn't be targeting that work? We provide value to developers by basically running a huge free CI across a wide range of architectures. That doesn't mean that they should develop against crate sources we have in Fedora, similarly to how upstream Python developers probably should use pip/venv instead of "whatver is in Fedora". The same applies to basically every language ecosystem except C/C++, where the package manager story is just so bad that system libraries are actually the only reliable development environment. > > This is due to a limitation of how cargo handles target-specific > > dependencies - all dependencies that are *mentioned in any way* need > > to be *present* for it to resolve dependencies / enabled optional > > features / update its lockfile etc. But since we don't want to package > > bindings for Windows and mac OS system APIs, we need to actually patch > > them out, otherwise builds will fail. > > And that ends up being quite a bit of work from my point of view. Also > the way the packaging works with options things like devel or optional > features ends up being very painful. I will often drop out optional > features just so I can do less packaging. Recent versions of rust2rpm automatically generate a patch to remove non-linux dependencies, so that work has effectively been reduced to zero. Disabling unused optional dependencies can also be done with either a rust2rpm config option or with a simple patch, so that should not be a problem, either. I also don't understand why disabling some optional features is such a bad thing? I don't think we have a policy in Fedora that says we *must* enable *all possible functionality and optional features*. > > > We're doing okay with #1, but... I think #3 _even_ with all of the work in > > > Rust-to-RPM packaging isn't sufficient. I've played with the Bevy game > > > engine and will probably have a few things it would be nice to package to > > > make available in Fedora Linux. I might not even mind maintaining Bevy > > > itself. > > > > Somebody actually already started packaging Bevy components - some > > packages are already approved and some are still pending review. Not > > sure what the progress has been there, but it's not *impossible*. > > Well nothing is *impossible* if you have enough stamina, resources or > whatever else. I don't find saying something isn't *impossible* > necessarily makes it compelling. I agree. And I think we can do better, as I said in my original post. > > > But running `cargo fetch` with a clean cache pulls down *390* crates. Of > > > these, it looks like 199 (!) are already packaged as rust-[crate]-devel, > > > which is *amazing*. But... that still is hundreds that I'd have to add. > > > And > > > mostly they are things I don't know _anything_ about. > > > > You must realize that this is an extreme case. For many Rust > > applications that people want to package for Fedora, the number of > > dependencies that are missing is rather small, *because* most popular > > libraries are already packaged. > > In my experience, and I'm not packaging any form of gaming engine, > it's not an extreme case, for a few small things and one slightly > larger thing I *have* packaged I now maintain over 60 more packages. I > have another one I want to package and AFAICT I get to package another > 50-100 but frankly it's hard to tell, and this is something I have > control over and have been actively trying to do upstream reduction of > deps. As far as I know, salimma's intern worked on a tool to determine missing dependencies for Rust projects in Fedora recursively, which should make it easier to determine the exact set of things that you would need to do here. > And requests to make things like this easier have been open for over a year: > https://pagure.io/fedora-rust/rust2rpm/issue/140 Right. I'm sorry about the issue reports that have been open for a long time. rust2rpm / rust-packaging is an entirely community-run project. We don't get any support from Red Hat (or other places) for anything except the Rust compiler itself. And with the original developer of rust2rpm (Igor) being gone, nobody who understands the low-level stuff in there is still around. zbyszek and I are trying our best to keep things running, but at this point, we'll need basically a rewrite of both rust2rpm and the RPM dependency / provides generators to support new
Willing to unretire package: rust-starship
Hello folks, Following up on the steps provided by the documentation [1], I would like to announce that I am willing to unretire the package rust-starship [2]. I use this app on a daily basis, and it seems like the previous maintainer is no longer interested in keeping the package, so I would like to take over the ownership. I will follow up on the remaining steps within the next few hours. Please, let me know if there is anything else I should know about. Thank you. [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ [2] https://src.fedoraproject.org/rpms/rust-starship ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump
Thanks for the reminder Petr. I will do the rebase in rawhide only then. Regards, Jiri On Wed, Nov 30, 2022 at 9:46 AM Petr Pisar wrote: > V Tue, Nov 29, 2022 at 10:34:45AM -0500, Yaakov Selkowitz napsal(a): > > On Tue, 2022-11-29 at 14:56 +0100, Petr Pisar wrote: > > > V Tue, Nov 29, 2022 at 01:07:19PM +0100, Jiri Kucera napsal(a): > > > > Hello, > > > > > > > > I am going to rebase gpgme to 1.17.1 in rawhide, f37, and f36. This > > > > bumps the SONAME of libqgpgme.so.7 to libqgpgme.so.15. > > > > > > Please, don't. That is an incompatible change which will break a lot of > > > software. E.g. DNF. We had a long thread "Should the policy documents > better > > > reflect real package maintenance practice?" > > > < > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/t > > > hread/7QL6UNNCC6WHIUSDQSEZMG222IWWCZEI/> > > > about it last week. > > > > > > Do a coordinate rebase in Rawhide. Backport important fixes to older > > > Fedoras. > > > > > > > Expect pushes to these repositories: > > > > * isoimagewriter > > > > * trojita > > > > * kget > > > > * kf5-libkleo > > > > * kleopatra > > > > * kmail-account-wizard > > > > * kf5-messagelib > > > > * kf5-mailcommon > > > > * kdepim-addons > > > > * kmail > > > > > > > This list is suspiciously short. It's missing libdnf, librepo, libisds > and > > > probably many others. > > > > Jiri wrote that only lib*q*gpgme is getting an SONAME bump. This is a Qt > > binding which is only used by Qt and KDE programs. > > > You are right. It's libqgpgme.so.7 only. Then the list of the packages is > indeed shorter. Though I still think that it's inappropriate to break the > soname in Fedoras < Rawhide. > > Funilly, kdepimlibs-gpgme already provides a copy of an older > libqgpgme.so.1. > > If Jiri really want to rebase the library in stable Fedoras, creating > a compatibility package with libqgpgme.so.7 there could be a way to go. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, Nov 30, 2022 at 11:54:10AM +, Peter Robinson wrote: > Hi Fabio, > > Been meaning to reply to this, but it got lost in the mail pile. > > > > But running `cargo fetch` with a clean cache pulls down *390* crates. Of > > > these, it looks like 199 (!) are already packaged as rust-[crate]-devel, > > > which is *amazing*. But... that still is hundreds that I'd have to add. > > > And > > > mostly they are things I don't know _anything_ about. > > > > You must realize that this is an extreme case. For many Rust > > applications that people want to package for Fedora, the number of > > dependencies that are missing is rather small, *because* most popular > > libraries are already packaged. > > In my experience, and I'm not packaging any form of gaming engine, > it's not an extreme case, for a few small things and one slightly > larger thing I *have* packaged I now maintain over 60 more packages. I > have another one I want to package and AFAICT I get to package another > 50-100 but frankly it's hard to tell, and this is something I have > control over and have been actively trying to do upstream reduction of > deps. The magnitude of the number of deps is the real killer for not only Rust, but also Go, and arguably anything that isn't a C based application. Packaging up all of a project's deps individually is viable when there are a relatively small number of them, especially if most of the deps are shared by other apps, and the libraries have good API + ABI stability promises. This is common in the case of most C applications/libraries, since shared libraries are relatively speaking fairly broad in functional scope, and often long lived, because that is the mindset of the C ecosystem in general. Modern languages & their ecosystems though have brought about a world where the granularity of deps is way smaller, where the focus is on being able to evolve rapidly, with less focus on long term stable API/ABI, as apps are expected to just fix against specific versions they've tested on. So functionality that lives in single library in C, often ends up being spread across 20-200 modules in any of the modern non-C languages. We've been experiancing this problem in Fedora for a very long time and while we have spec auto-generators, that still leaves masses of busy work, and also still leaves the problem that what we ship doesn't match what upstream has tested, so the result is often less reliable. IMHO the only thing that can make packaging such fine grained modules sustainable long term, is if the process could be 100% automated. I don't mean just having a tool to auto-generate a spec file. It needs to be fully automated to the extent that you just tell a robot "i need deps for this package" and it does everything automatically, except for human approval of the results of a code license audit. That of course would be a non-trivial service to build, and it still begs the question of whether its really beneficial in the long term. > > Sure, but isn't that the case for most projects that a newcomer wants > > to package, regardless of programming language? Say, somebody wants to > > package some cool new Python project for machine learning, then > > there's probably also some linear algebra package or SIMD math library > > in the dependency tree that's missing from Fedora. How is that > > different? > > I think the big difference here from my experience, and I've packaged > right across the Fedora spectrum, is that most of the python style > projects are able to use a pretty comprehensive standard library and > crypto library which helps minimise a lot of the extras I've seen in > the rust ecosystem. Python isn't that different from the Rust world to be honest. For a short while we had OpenStack in Fedora, but it wasn't sustainable to maintain its large set of python module deps, fighting between the versions Fedora already had, vs the versions that OpenStack actually wanted (and was tested against by upstream. It was never ending busy-work for the people trying to keep it working in Fedora, taking time away from more beneficial work, and delivering a system that was often broken because module version combinations we used were not tested. > > - we port projects to new versions of dependencies > > That's valuable for other projects but not Fedora, and it's not > something I am going to do personally as a rust packager. It isn't sustainable in the general case, as it requires a level of expertize / knowledge that most packagers can't be assumed to have. If they have that knowledge and the time to invest in this, they can do it directly in upstream, regardless of what Fedora packaging approach is used. > I don't think it's as bad as other ecosystems but I don't agree with > your assessment of "kind of a *good* situation", I feel there may be a > little bit of Stockholm syndrome coming into play here to be honest. I feel like Fedora is successfull in packaging huge numbers of deps
[Bug 2148773] perl-Prima-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2148773 Petr Pisar changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED CC|ppi...@redhat.com | -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148773 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
Hi Fabio, Been meaning to reply to this, but it got lost in the mail pile. > > I _very much_ appreciate all the work you and the other Rust SIG folks > > (Igor and Zbyszek in particular but I'm sure others as well!) have put into > > packaging rust apps and crates and all of the systems around that. > > I'll respond inline. Same. > > I fundamentally disagree with Kevin on a deep level about "entirely > > useless", but ... find myself kind of agreeing about the "unpackagable" > > part. I mean: clearly we've found a way, but I'm really not sure we're > > providing a lot of _value_ in this approach, and I'm also not sure it's as > > successful as it could be. > > We *do* provide value to both users *and* developers by doing things > the way we do, but the benefits might not be obvious to people who > don't know how (Rust) packaging works, and what we as package > maintainers do. As a rust packager I initially agreed but I am now having doubts here. > > There are three ways having things packaged in Fedora repos _can_ be > > helpful: > > > > 1. End-user applications and tools > > 2. Useful development environment > > 3. As convenience for ourselves for building packages for #1 or #2 > > > > I am not discounting the value of #3 -- making a shared thing that we all > > work on together is kind of the whole point, and the nicer we can make that > > the better we can bring in more people, and those of us already here have a > > lighter load and can work on the things we're most interested in. But > > ultimately, we're doing it so we make a useful system for users. That means > > the first two. > > This I can agree with :) > > > I'll start with the second: our system for Rust doesn't really do that. > > Developers are going to use cargo and crates.io and we're not going to > > convince them that they should do otherwise. (I don't expect anyone > > disagrees with this.) > > This is true, and probably also not "fixable". We need to make some > amount of non-upstreamable patches to some crates (most notably, > removing Windows- or mac OS-specific dependencies, because we don't > want to package those), but in some cases, these are "incompatible" > changes, and Rust *developers* should not be targeting our downstream > sources that have these differences with actual upstream sources. Yet you say above "We *do* provide value to both users *and* developers" yet you say developers shouldn't be targeting that work? > This is due to a limitation of how cargo handles target-specific > dependencies - all dependencies that are *mentioned in any way* need > to be *present* for it to resolve dependencies / enabled optional > features / update its lockfile etc. But since we don't want to package > bindings for Windows and mac OS system APIs, we need to actually patch > them out, otherwise builds will fail. And that ends up being quite a bit of work from my point of view. Also the way the packaging works with options things like devel or optional features ends up being very painful. I will often drop out optional features just so I can do less packaging. > > We're doing okay with #1, but... I think #3 _even_ with all of the work in > > Rust-to-RPM packaging isn't sufficient. I've played with the Bevy game > > engine and will probably have a few things it would be nice to package to > > make available in Fedora Linux. I might not even mind maintaining Bevy > > itself. > > Somebody actually already started packaging Bevy components - some > packages are already approved and some are still pending review. Not > sure what the progress has been there, but it's not *impossible*. Well nothing is *impossible* if you have enough stamina, resources or whatever else. I don't find saying something isn't *impossible* necessarily makes it compelling. > > But running `cargo fetch` with a clean cache pulls down *390* crates. Of > > these, it looks like 199 (!) are already packaged as rust-[crate]-devel, > > which is *amazing*. But... that still is hundreds that I'd have to add. And > > mostly they are things I don't know _anything_ about. > > You must realize that this is an extreme case. For many Rust > applications that people want to package for Fedora, the number of > dependencies that are missing is rather small, *because* most popular > libraries are already packaged. In my experience, and I'm not packaging any form of gaming engine, it's not an extreme case, for a few small things and one slightly larger thing I *have* packaged I now maintain over 60 more packages. I have another one I want to package and AFAICT I get to package another 50-100 but frankly it's hard to tell, and this is something I have control over and have been actively trying to do upstream reduction of deps. And requests to make things like this easier have been open for over a year: https://pagure.io/fedora-rust/rust2rpm/issue/140 > Bevy is a bit special, because it (presumably) pulls in lots of GPU / > OpenGL / Vulkan related libraries, which we didn't
Re: Red Hat Bugzilla fonts
I think good to open a bug against the Bugzilla product in bugzilla. Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 1716324] Module::Build lists the object files after the linker flags, causing underlinking with -Wl,--as-needed
https://bugzilla.redhat.com/show_bug.cgi?id=1716324 Paul Howarth changed: What|Removed |Added Version|35 |36 --- Comment #11 from Paul Howarth --- No activity this cycle, presumably still an issue. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1716324 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2149242] perl-Devel-NYTProf in EPEL 8 (present in EPEL 5,6,7)
https://bugzilla.redhat.com/show_bug.cgi?id=2149242 --- Comment #1 from Jitka Plesnikova --- epel8 https://pagure.io/releng/fedora-scm-requests/issue/49590 epel9 https://pagure.io/releng/fedora-scm-requests/issue/49591 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2149242 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump
V Tue, Nov 29, 2022 at 10:34:45AM -0500, Yaakov Selkowitz napsal(a): > On Tue, 2022-11-29 at 14:56 +0100, Petr Pisar wrote: > > V Tue, Nov 29, 2022 at 01:07:19PM +0100, Jiri Kucera napsal(a): > > > Hello, > > > > > > I am going to rebase gpgme to 1.17.1 in rawhide, f37, and f36. This > > > bumps the SONAME of libqgpgme.so.7 to libqgpgme.so.15. > > > > Please, don't. That is an incompatible change which will break a lot of > > software. E.g. DNF. We had a long thread "Should the policy documents better > > reflect real package maintenance practice?" > > < > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/t > > hread/7QL6UNNCC6WHIUSDQSEZMG222IWWCZEI/> > > about it last week. > > > > Do a coordinate rebase in Rawhide. Backport important fixes to older > > Fedoras. > > > > > Expect pushes to these repositories: > > > * isoimagewriter > > > * trojita > > > * kget > > > * kf5-libkleo > > > * kleopatra > > > * kmail-account-wizard > > > * kf5-messagelib > > > * kf5-mailcommon > > > * kdepim-addons > > > * kmail > > > > > This list is suspiciously short. It's missing libdnf, librepo, libisds and > > probably many others. > > Jiri wrote that only lib*q*gpgme is getting an SONAME bump. This is a Qt > binding which is only used by Qt and KDE programs. > You are right. It's libqgpgme.so.7 only. Then the list of the packages is indeed shorter. Though I still think that it's inappropriate to break the soname in Fedoras < Rawhide. Funilly, kdepimlibs-gpgme already provides a copy of an older libqgpgme.so.1. If Jiri really want to rebase the library in stable Fedoras, creating a compatibility package with libqgpgme.so.7 there could be a way to go. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
