Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
Thank you, Peter, for coming up with this! I have to say this is really good news to hear indeed - I have been waiting silently for this for quite a long time. Kudos, 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Dr Anirban Mitra
Dear Anirban, স্বাগতম (welcome)! Awesome story, an inspiration to others. Regards, Benson On 2/8/22 3:29 AM, Anirban Mitra via devel wrote: Hello I am Dr Anirban Mitra. I an is open-source enthusiast and amateur typographer, I am a physician by profession. I had worked for GNU/ Linux Bengali/ Bangla localisation project and worked on a few open source OpenType fonts in Bengali. I had described my journey in open source in an article https://opensource.com/article/20/7/linux-bengali I had joined Fedora developer group to begin packaging my fonts for Fedora. I am learning Fedora packaging now and two of my font package are in review stage. Thanks Anirban ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RPM Spec scriptlets
> On Mon, Feb 7, 2022 at 9:57 PM Paweł Marciniak wrote:
> At first glance, this happens because you apply the scriptlets to the
> wrong package.
"%pre -n python3-%{github_name}"
This is the missing part, thank you Fabio.
> and you should probably also use the macros provided by
> systemd-rpm-macros instead:
Yes I know it was only for testing purposes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[Bug 2051034] Removal of gethostbyname2 breaks Shorewall6
https://bugzilla.redhat.com/show_bug.cgi?id=2051034 --- Comment #7 from Brian J. Murrell --- Ahhh. Very nice. I didn't even know Shorewall had made it outside of SourceForge. Hopefully they merge that MR. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051034 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2037669] Please branch and build perl-Crypt-CBC for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2037669 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-0cc4391af4 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-0cc4391af4 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=2037669 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2037672] Please branch and build perl-Crypt-Blowfish for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2037672 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-0cc4391af4 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-0cc4391af4 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=2037672 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032450] perl-Test-LWP-UserAgent for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032450 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-65bb401248 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-65bb401248 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=2032450 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[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-90efec73a3 phoronix-test-suite-10.8.1-2.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c6e9e4be6b rlwrap-0.45.2-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5aac445eff libdxfrw-1.0.1-3.el7 librecad-2.2.0-0.13.rc3.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a23ae5cde8 nodejs-16.13.2-8.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing liblxi-1.16-1.el7 libmodulemd2-2.14.0-1.el7 php-composer-semver3-3.2.9-1.el7 rpki-client-7.6-1.el7 uglify-js-3.15.1-1.el7 Details about builds: liblxi-1.16-1.el7 (FEDORA-EPEL-2022-af1d012200) Library with simple API for communication with LXI devices Update Information: # liblxi v1.16 - Fix handling of send errors for TCP/RAW connections ChangeLog: * Thu Feb 3 2022 Robert Scheck 1.16-1 - Upgrade to 1.16 (#2050367) References: [ 1 ] Bug #2050367 - liblxi-1.16 is available https://bugzilla.redhat.com/show_bug.cgi?id=2050367 libmodulemd2-2.14.0-1.el7 (FEDORA-EPEL-2022-631747b5eb) Module metadata manipulation library Update Information: This release fixes a crash when updating an index with an invalid subdocument and a NULL error parameter, clobbering module defaults on a modulemd_module_set_defaults() failure, modulemd_module_index_upgrade_defaults() to actually use the requested version, rejecting duplicate contexts in modulemd- packager-v3 documents, reporting an error if modulemd-validator tool is invoked with both --version option and an unknown option, and runing tests with Python 3.11. This release also adds functions for cleaning modules from XMD data and improves a documentation. ChangeLog: * Fri Feb 4 2022 Petr Pisar - 2.14.0-1 - 2.14.0 bump php-composer-semver3-3.2.9-1.el7 (FEDORA-EPEL-2022-e09ad262a5) Semver library version 3 Update Information: **Version 3.2.9** *Revert #129 (Fixed MultiConstraint with MatchAllConstraint) which caused regressions **Version 3.2.8** * Updates to latest phpstan / CI by @Seldaek in #130 *Fixed MultiConstraint with MatchAllConstraint by @Toflar in #129 ChangeLog: * Sat Feb 5 2022 Remi Collet - 3.2.9-1 - update to 3.2.9 * Fri Feb 4 2022 Remi Collet - 3.2.8-1 - update to 3.2.8 rpki-client-7.6-1.el7 (FEDORA-EPEL-2022-cf0c01c04a) RPKI validator to support BGP Origin Validation Update Information: # rpki-client 7.6- Enforce the correct namespace of rrdp files. - Fail certificate verification if a certificate contains unknown critical extensions. - Improve cleanup of rrdp directory contents. - Introduce a validated cache which holds all the files that have successfully been verified by `rpki-client`. - Add a new option `-f ` to validate a signed object in a file against the RPKI cache. ChangeLog: * Mon Feb 7 2022 Robert Scheck 7.6-1 - Upgrade to 7.6 (#2051736) * Fri Jan 21 2022 Fedora Release Engineering - 7.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild References: [ 1 ] Bug #2051736 - rpki-client-7.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=2051736 uglify-js-3.15.1-1.el7 (FEDORA-EPEL-2022-1e8da20366) JavaScript parser, mangler/compressor and beautifier toolkit Update
[Bug 2050091] perl-CGI-4.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2050091 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2022-632a984213 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-632a984213` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-632a984213 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=2050091 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Mon, Feb 7, 2022 at 8:12 PM Kevin Kofler via devel wrote: > > Miro Hrončok wrote: > > gstreamer1 orphan, uraeus, wtaymans1 weeks > > ago > > gstreamer1-plugins-baseorphan, uraeus, wtaymans1 weeks > > ago > > gstreamer1-plugins-goodorphan, uraeus, wtaymans1 weeks > > ago > > How did the gstreamer1 stack end up orphaned? Pretty much the entire desktop > world, across all desktop environments, depends on it! > Wim Taymans, who actually maintains it, hasn't actually been set as the primary maintainer. He needs to pick them up and become the official main maintainer. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
Miro Hrončok wrote: > gstreamer1 orphan, uraeus, wtaymans1 weeks > ago > gstreamer1-plugins-baseorphan, uraeus, wtaymans1 weeks > ago > gstreamer1-plugins-goodorphan, uraeus, wtaymans1 weeks > ago How did the gstreamer1 stack end up orphaned? Pretty much the entire desktop world, across all desktop environments, depends on it! 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 on the list, report it: https://pagure.io/fedora-infrastructure
Self Introduction: Dr Anirban Mitra
Hello I am Dr Anirban Mitra. I an is open-source enthusiast and amateur typographer, I am a physician by profession. I had worked for GNU/ Linux Bengali/ Bangla localisation project and worked on a few open source OpenType fonts in Bengali.I had described my journey in open source in an article https://opensource.com/article/20/7/linux-bengali I had joined Fedora developer group to begin packaging my fonts for Fedora. I am learning Fedora packaging now and two of my font package are in review stage.Thanks Anirban ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051034] Removal of gethostbyname2 breaks Shorewall6
https://bugzilla.redhat.com/show_bug.cgi?id=2051034 --- Comment #6 from Michal Josef Spacek --- (In reply to Brian J. Murrell from comment #5) > (In reply to Michal Josef Spacek from comment #4) > > The best way is rewrite Shorewall6 to remove dependency to Socket6. > > Sure. But I am not a Shorewall maintainer or really much of a Perl > programmer for that matter. No offence, but I don't really like Perl as a > programming language and don't spend much time with as a result. I understand > > There are IO::Socket::IP or Socket with IPv6 support now. > > That's great. > > But seeing as this change in the Perl::Socket6 is breaking Shorewall in > Fedora 35 currently, assuming we cannot get the Shorewall authors to agree > (there has been no response to my report of the use of these obsolete > interfaces) to updating to discontinue using these obsolete interfaces, > would it be appropriate to transfer this ticket to the shorewall BZ > component to have the above patch applied to the Fedora shorewall package? I created patch for fix: https://gitlab.com/shorewall/code/-/merge_requests/5 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051034 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?
On Mon, Feb 07, 2022 at 03:01:43PM -0800, Adam Williamson wrote: > On Mon, 2022-02-07 at 15:17 +0100, Miro Hrončok wrote: > > > > The change owner proposed 4 options to move forward. I understand them as > > follows: > > > > 1. do nothing, keep it broken > > 2. disable this behavior by default, keep it optional, but keep it broken > > 3. do not ignore already broken weak rich deps (partially reverts the > > change) > > 4. change the behavior on dynamically depending on the dnf command used > > (discouraged) > > It's not clear to me whether any of these choices maps to "revert the > Change and do exactly what F35 and earlier did", but on principle, that > is the correct choice if no other choice is an improvement. It is not > useful to change to a new behavior which is no better than the old > behavior. If the Change can't be implemented as planned, ideally no > change should happen at all. Option 2. is that. The code to support this has been merged in libsolv and dnf, so it's easier to return to status quo ante by flipping the default, then to fully undo all changes. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?
On Mon, 2022-02-07 at 15:17 +0100, Miro Hrončok wrote: > > The change owner proposed 4 options to move forward. I understand them as > follows: > > 1. do nothing, keep it broken > 2. disable this behavior by default, keep it optional, but keep it broken > 3. do not ignore already broken weak rich deps (partially reverts the change) > 4. change the behavior on dynamically depending on the dnf command used > (discouraged) It's not clear to me whether any of these choices maps to "revert the Change and do exactly what F35 and earlier did", but on principle, that is the correct choice if no other choice is an improvement. It is not useful to change to a new behavior which is no better than the old behavior. If the Change can't be implemented as planned, ideally no change should happen at all. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
On Sun, 2022-02-06 at 14:54 +0100, David Bold wrote: > > > I just tried to install Fedora on RPi, and I ended up on [1] where I > downloaded an image. That was unfortunately armv7 - and I needed to go > to [2] - which was not linked in the descriptions [3,4]. Also the wiki > lists first the armv7 [5] > > [1] https://arm.fedoraproject.org/ > [2] https://alt.fedoraproject.org/alt/ > [3] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/ > [4] > https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#installing-fedora-on-a-raspberry-pi-using-the-fedora-arm-installer_rpi > [5] https://www.fedoraproject.org/wiki/Architectures/ARM/Fedora_Linux_35 So yeah, I think cleaning up and modernizing all this should be in- scope for the Change, thanks for highlighting it. The arm.fp.o site and the docs page you used are both, I think, older things that date from before we really supported aarch64 much at all, and they clearly haven't been updated. The "current" approach is not great either, though. If you just go in through the front door of the docs page you'd go to "User Documentation" for "Fedora Linux 35", which takes you here: https://docs.fedoraproject.org/en-US/fedora/f35/ from where I guess you'd go to https://docs.fedoraproject.org/en-US/fedora/f35/install-guide/Downloading_Fedora/ , which has an "ARM images" section which points you to https://fedoraproject.org/wiki/Architectures/ARM . That page then points you to https://fedoraproject.org/wiki/Architectures/ARM/Installation , which does at least cover aarch64, but seems to give armhfp equal or higher prominence. It would be great if we can get a doc person to take a look at all these pages referenced above and try to streamline them, modernize them, and get them all singing from the same hymn sheet, I guess. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: dnf install removes /etc/systemd/system/multi-user.wants/myservice.target symlink
> On 7 Feb 2022, at 19:19, Kevin P. Fleming wrote: > > > Slightly off-topic, but I think it's relevant: > > If 'myservice' and 'ods-prx' are referring to the same thing, I think you're > supposed to use 'systemctl preset' instead of 'systemctl enable'. This allows > the admin to decide whether the installed service/target/timer/etc. should be > enabled during package installation. I recently learned about this feature > and am using it to good effect on my own systems to stop packages from > auto-starting the services they install :-) Yes myservice and ods-prx are the same. Yes preset is nice providing defaults for the admin. But this is for production system and it must be symlinked. Are you saying that there is code in dnf/rpm that is undoing the symlinking becuase the preset is not in place? Barry > >> On Mon, Feb 7, 2022 at 1:55 PM Barry Scott wrote: >> This is not for a package in Fedora, its for a package I'm >> working on for Oracle Linux 8. >> >> I install /usr/lib/systemd/system/myservice.target >> that has: >> >> [Install] >> WantedBy=multi-user.target >> >> In %post I run this: >> >> ls -l /etc/systemd/system/multi-user.target.wants >> /usr/bin/systemctl --no-reload enable ods-prx.target >> ls -l /etc/systemd/system/multi-user.target.wants >> echo "Info: post done" >> >> When I dnf install myservice I see that the symlink is >> setup from the ls -l output in the %post section. >> >> But later in the output I see this line: >> >> Info: post done >> >> Running scriptlet: myservice-2022.1-20220207180603.noarch >> Removed /etc/systemd/system/multi-user.target.wants/myservice.target. >> >> Is this expected? >> >> How can I stop this happening? >> >> If its not expected how can I pull apart the RPM to find the code that is >> running? >> >> Barry >> >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
On Mon, Feb 7, 2022 at 5:27 PM Dennis Gilmore wrote: > > On Sun, Feb 6, 2022 at 7:55 AM David Bold wrote: > > > > On 11/15/21 20:15, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/RetireARMv7 > > > > > ... > > > == Scope == > > > > > > * Proposal owners: Work with rel-eng to disable the architecture in > > > koji, remove all the various pungi pieces and clean up any other > > > release detritus. > > > > > > * Other developers: No action required. > > > > > > * Release engineering: [https://pagure.io/releng/issue/10387 Releng > > > issue #10387] Disable a bunch of stuff, it's really just one koji > > > admin command and a PR for pungi config changes > > > > > > * Policies and guidelines: No initial updates to policies and > > > guidelines as ARMv7 won't completely disappear until F-36 EOL. > > > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > > > > > Any current users of Fedora on ARMv7 devices won't be able to upgrade > > > to Fedora 37, they will have to stay on Fedora 36 until it's EOL. > > > > > ... > > > == User Experience == > > > Any current users of Fedora on ARMv7 devices won't be able to upgrade > > > to Fedora 37, they will have to stay on Fedora 36 until it's EOL. > > ... > > > > I just tried to install Fedora on RPi, and I ended up on [1] where I > > downloaded an image. That was unfortunately armv7 - and I needed to go > > to [2] - which was not linked in the descriptions [3,4]. Also the wiki > > lists first the armv7 [5] > > > > As such I think there will be very many people being stuck on F36, > > without a way to update to F37. I was not happy that my old RPi will not > > work any more, but that we still push people towards a to be retired > > version is very bad. > > > > I think at least this needs to be taken into account, and the websites > > should be fixed as soon as possible. Further, if this is possible, there > > should be instructions to update from armv7 to aarch64, to make a direct > > upgrade, rather than reinstall, possible. > > > > tl;dr > > 1) mention that also aarch64 users are affect, if they run armv7 > > software, which seems quite likely > > 2) Change the websites, add deprecation info, and point to aarch64 pages > > 3) discuss impact on armv7 on aarch64 users > > We do not support running 32-bit arm software on an AArch64 system. We > should look at places that suggest a 32 bit version of Fedora for a > raspberry pi and update that to use AArch64 versions. Possibly adding > a dnf plugin to all 32 bit arm systems giving users a warning that the > EOL of 32 bit arm is coming and depending on the hardware they will > need to replace it or in the case of the raspberry pi if it is new > enough they could do a clean AArch64 install > Any solution involving a DNF plugin is unworkable because any theoretical plugin is not already on the images. Frankly, it makes no sense that we can't run 32-bit ARM software on a 64-bit ARM platform, but here we are... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
On Sun, Feb 6, 2022 at 7:55 AM David Bold wrote: > > On 11/15/21 20:15, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/RetireARMv7 > > > ... > > == Scope == > > > > * Proposal owners: Work with rel-eng to disable the architecture in > > koji, remove all the various pungi pieces and clean up any other > > release detritus. > > > > * Other developers: No action required. > > > > * Release engineering: [https://pagure.io/releng/issue/10387 Releng > > issue #10387] Disable a bunch of stuff, it's really just one koji > > admin command and a PR for pungi config changes > > > > * Policies and guidelines: No initial updates to policies and > > guidelines as ARMv7 won't completely disappear until F-36 EOL. > > > > * Trademark approval: N/A (not needed for this Change) > > > > == Upgrade/compatibility impact == > > > > Any current users of Fedora on ARMv7 devices won't be able to upgrade > > to Fedora 37, they will have to stay on Fedora 36 until it's EOL. > > > ... > > == User Experience == > > Any current users of Fedora on ARMv7 devices won't be able to upgrade > > to Fedora 37, they will have to stay on Fedora 36 until it's EOL. > ... > > I just tried to install Fedora on RPi, and I ended up on [1] where I > downloaded an image. That was unfortunately armv7 - and I needed to go > to [2] - which was not linked in the descriptions [3,4]. Also the wiki > lists first the armv7 [5] > > As such I think there will be very many people being stuck on F36, > without a way to update to F37. I was not happy that my old RPi will not > work any more, but that we still push people towards a to be retired > version is very bad. > > I think at least this needs to be taken into account, and the websites > should be fixed as soon as possible. Further, if this is possible, there > should be instructions to update from armv7 to aarch64, to make a direct > upgrade, rather than reinstall, possible. > > tl;dr > 1) mention that also aarch64 users are affect, if they run armv7 > software, which seems quite likely > 2) Change the websites, add deprecation info, and point to aarch64 pages > 3) discuss impact on armv7 on aarch64 users We do not support running 32-bit arm software on an AArch64 system. We should look at places that suggest a 32 bit version of Fedora for a raspberry pi and update that to use AArch64 versions. Possibly adding a dnf plugin to all 32 bit arm systems giving users a warning that the EOL of 32 bit arm is coming and depending on the hardware they will need to replace it or in the case of the raspberry pi if it is new enough they could do a clean AArch64 install Dennis > Cheers, > David > > > [1] https://arm.fedoraproject.org/ > [2] https://alt.fedoraproject.org/alt/ > [3] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/ > [4] > https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#installing-fedora-on-a-raspberry-pi-using-the-fedora-arm-installer_rpi > [5] https://www.fedoraproject.org/wiki/Architectures/ARM/Fedora_Linux_35 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051034] Removal of gethostbyname2 breaks Shorewall6
https://bugzilla.redhat.com/show_bug.cgi?id=2051034 --- Comment #5 from Brian J. Murrell --- (In reply to Michal Josef Spacek from comment #4) > The best way is rewrite Shorewall6 to remove dependency to Socket6. Sure. But I am not a Shorewall maintainer or really much of a Perl programmer for that matter. No offence, but I don't really like Perl as a programming language and don't spend much time with as a result. > There are IO::Socket::IP or Socket with IPv6 support now. That's great. But seeing as this change in the Perl::Socket6 is breaking Shorewall in Fedora 35 currently, assuming we cannot get the Shorewall authors to agree (there has been no response to my report of the use of these obsolete interfaces) to updating to discontinue using these obsolete interfaces, would it be appropriate to transfer this ticket to the shorewall BZ component to have the above patch applied to the Fedora shorewall package? -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051034 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051729] New: perl-PDL-2.073 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051729 Bug ID: 2051729 Summary: perl-PDL-2.073 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PDL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jakub.jedel...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com, tjczep...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.073 Current version/release in rawhide: 2.63.0-2.fc36 URL: http://search.cpan.org/dist/PDL/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3205/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051729 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-SQL-Translator] PR #1: Split GraphViz-dependent components into subpackages
adamwill commented on the pull-request: `Split GraphViz-dependent components into subpackages` that you are following: `` Rebased and adjusted, thanks! `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-SQL-Translator/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Mon, 7 Feb 2022 at 17:10, Neal Gompa wrote: > > On Mon, Feb 7, 2022 at 11:20 AM Kevin Kofler via devel > wrote: > > > > Marc-André Lureau wrote: > > > Release build should be tested on Windows. It is easy to build and test > > > natively with msys2 nowadays, or build for other targets. Why not use > > > that? > > > > Because I do not have a computer running Windows, nor a Windows license. > > > > For my hobbyist game development, I rely on the Fedora MinGW stack to > be able to produce Windows builds for them. I do all my own > development and work from Fedora Linux and I'd rather not change that. > > If anything, our MinGW stack is an amazing selling point compared to > other distributions, because we provide a usable framework to build > applications for Windows. It really is great. GCC's C++17 std::filesystem code supports Windows, but is entirely developed on Fedora. I cross-compile using mingw-w64 and test using Wine. If I couldn't do that on Fedora, the Windows support simply wouldn't exist. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RPM Spec scriptlets
On Mon, Feb 7, 2022 at 9:57 PM Paweł Marciniak wrote:
>
> Can someone tell me why none of the scriptlets (%pre, post etc) in the spec
> file
> https://download.copr.fedorainfracloud.org/results/sunwire/rpmtest/fedora-35-x86_64/03364007-python-input-remapper/python-input-remapper.spec
> work?
> After building the package, all scriptlets are missing and rpm -qp --scripts
> returns nothing.
> Is this a bug in pyproject-rpm-macros? Am i missing something?
> rpm:
> https://download.copr.fedorainfracloud.org/results/sunwire/rpmtest/fedora-35-x86_64/03364007-python-input-remapper/python3-input-remapper-1.4.0-4.git20220205.fc35.noarch.rpm
> srpm:
> https://download.copr.fedorainfracloud.org/results/sunwire/rpmtest/fedora-35-x86_64/03364007-python-input-remapper/python-input-remapper-1.4.0-4.git20220205.fc35.src.rpm
Hi!
At first glance, this happens because you apply the scriptlets to the
wrong package.
You need to give %pre, %post, etc. the same "package name" argument as
%description and %files, namely the package name that contains the
service files, so "%pre -n python3-%{github_name}" etc.
Also note that enabling systemd services with presets and scriptlets
like these is forbidden for official Fedora packages,
and you should probably also use the macros provided by
systemd-rpm-macros instead:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
RPM Spec scriptlets
Can someone tell me why none of the scriptlets (%pre, post etc) in the spec file https://download.copr.fedorainfracloud.org/results/sunwire/rpmtest/fedora-35-x86_64/03364007-python-input-remapper/python-input-remapper.spec work? After building the package, all scriptlets are missing and rpm -qp --scripts returns nothing. Is this a bug in pyproject-rpm-macros? Am i missing something? rpm: https://download.copr.fedorainfracloud.org/results/sunwire/rpmtest/fedora-35-x86_64/03364007-python-input-remapper/python3-input-remapper-1.4.0-4.git20220205.fc35.noarch.rpm srpm: https://download.copr.fedorainfracloud.org/results/sunwire/rpmtest/fedora-35-x86_64/03364007-python-input-remapper/python-input-remapper-1.4.0-4.git20220205.fc35.src.rpm ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
> https://fedoraproject.org/wiki/Changes/F37MingwUCRT > > Since mingw-*.spec are very repetitive and cumbersome to modify (each > mingw32, mingw64, ucrt package has to be defined manually, and this is > tedious and error-prone), a custom MinGW/Fedora tool or solution will > be proposed. In the meantime, packages can be modified to add manually > the new target. I think this is an important point. If this is to be done manually, the transition will take forever and will consume a lot of maintainer resources. I would very much encourage you do first develop macroification to make the new subpackages easy to add. And once that is done, do spec file munging semi-automatically, like it was done when we were renaming python2 subpackages. (This was similar, because we needed to add a new %package section and related sections.) Once the whole thing is ready, use a provenpackager to update and build all packages. In my exprience, it is also important to ask maintainers to *not* do manual conversions, because if you add automatization later on, manually converted packages end up being a bit different and in the end are more trouble than running the automatic converted over a few additional files. If that'd be helpful, I can dig up the scripts for python2. I'd be happy to help with building scripts to do the conversion here, though I know almost nil about mingw. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Am 07.02.22 um 18:08 schrieb Neal Gompa: If anything, our MinGW stack is an amazing selling point compared to other distributions, because we provide a usable framework to build applications for Windows. I'd like to second this. I felt relieved once I found out that I could build a tiny in-house C application for Windows (using DBUS via glib + a proprietary 32 bit black box DLL) purely on Linux. meson can do all the cross-compilation, mingw glib provides .pc files and everything works beautifully just like you would compile a Linux executable. Since I got this working a year ago all of our release builds were done on Windows. I completely wiped Visual Studio and there was no bug report related to compilation or the build process since. :-) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rawhide update stuck in bodhi with weird test failures
On Sat, 2022-02-05 at 09:28 +, Richard W.M. Jones wrote: > "This update has been submitted for stable by bodhi" > > Thanks everyone! You might wanna just check after the push happens what happened to the package you untagged. I don't actually know offhand what will happen to it in this situation. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?
On Mon, Feb 07, 2022 at 03:25:44PM +0100, Miro Hrončok wrote: > > 1. do nothing, keep it broken > > I pretty much dislike this option. Clearly, the current behavior is not what > was approved in this change proposal. For me, it's a bad option. Agreed. We want to use langpacks with rich depenendecies *more*, e.g. replacing comps with that, and it'd be a big step back if rich deps stopped working as expected. > > 3. do not ignore already broken weak rich deps (partially reverts the > > change) > > This sounds like a possible path forward -- it would probably still be an > improvement over the the Fedora 35 status quo, however the results might be > quite surprising for the users. If we decide to do this, I think we should > postpone to Fedora 37 neverthelss to see it in action and figure out if it's > actually a good idea or an UX nightmare. Agreed, this doesn't sound too great either. I think we'd be better postponing the feature until F37 or later if we can get a solution then. > > 4. change the behavior on dynamically depending on the dnf command used > > (discouraged) > > As stated by the change owner in the bugzilla, this is probably not a good > idea. Even when the user types `dnf install` it sometimes upgrades some > already installed packages and even if they type `dnf upgrade` it sometimes > installs some new packages. Agreed also. > > 2. disable this behavior by default, keep it optional, but keep it broken > > This only makes sense if it's likely to get fixed and enabled again in later > Fedora release. If the plan is to disable it by default and never touch it > again, I suppose we might as well revert it entirely. I would very much to > see the change happening as it was advertised, even if we cannot make ti to > Fedora 36. Agreed. > For the sake of an open minded discussion, I am ignoring the fact that the > change owners themselves don't consider it doable (I think that it is > doable, but I honestly don't know if it is realistic with the current > resources). I'll just say what you and others said: rpm/dnf has *all* the information about the system, so it should be just a matter of adding plumbing to push that information to the right layer. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2022-02-07.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change 3proxy orphan 2 weeks ago DivFix++ orphan 2 weeks ago colorize orphan 2 weeks ago curlftpfs orphan 2 weeks ago darkstat orphan 2 weeks ago elmon orphan 2 weeks ago gstreamer1 orphan, uraeus, wtaymans1 weeks ago gstreamer1-plugins-baseorphan, uraeus, wtaymans1 weeks ago gstreamer1-plugins-goodorphan, uraeus, wtaymans1 weeks ago gupnp-igd kalev, orphan 1 weeks ago hans orphan 2 weeks ago httpd-itk orphan 2 weeks ago javahelp2 orphan 0 weeks ago laby orphan 4 weeks ago mysqlreportorphan, wolfy 2 weeks ago nautilus-image-converter orphan, timj1 weeks ago pacmanager ngompa, orphan 2 weeks ago percol orphan 2 weeks ago perl-File-Finder orphan 2 weeks ago perl-File-Inplace orphan 2 weeks ago perl-HTML-Tidy gnat, jplesnik, mmaslano, mspacek, 0 weeks ago orphan, ppisar perl-Lingua-EN-Fathom jfearn, orphan 2 weeks ago perl-Lingua-EN-Syllableorphan 2 weeks ago perl-MouseX-App-Cmdorphan 0 weeks ago perl-ParseLex orphan 2 weeks ago pgcenter orphan 2 weeks ago pgdbf orphan 2 weeks ago php-pecl-datadog_trace orphan 1 weeks ago php-pecl-solr2 orphan 4 weeks ago plexus-i18nmizdebsk, orphan2 weeks ago pstreams-devel jwakely, orphan 2 weeks ago publican jfearn, orphan 2 weeks ago python-ECPyorphan 2 weeks ago python-btchip jonny, orphan 2 weeks ago python-cmigemo orphan 2 weeks ago python-luftdaten orphan 1 weeks ago python-netssh2 orphan 4 weeks ago python-wandorphan 4 weeks ago rubygem-ruby-ntlm orphan 1 weeks ago slim aarem, orphan 2 weeks ago sqlite3-dbforphan 2 weeks ago ssh-contactorphan 1 weeks ago telepathy-farstreamorphan 1 weeks ago telepathy-filesystem orphan 1 weeks ago telepathy-idle orphan 1 weeks ago telepathy-logger orphan, rishi 1 weeks ago teseq orphan 2 weeks ago trickleorphan,
Re: dnf install removes /etc/systemd/system/multi-user.wants/myservice.target symlink
Slightly off-topic, but I think it's relevant: If 'myservice' and 'ods-prx' are referring to the same thing, I think you're supposed to use 'systemctl preset' instead of 'systemctl enable'. This allows the admin to decide whether the installed service/target/timer/etc. should be enabled during package installation. I recently learned about this feature and am using it to good effect on my own systems to stop packages from auto-starting the services they install :-) On Mon, Feb 7, 2022 at 1:55 PM Barry Scott wrote: > This is not for a package in Fedora, its for a package I'm > working on for Oracle Linux 8. > > I install /usr/lib/systemd/system/myservice.target > that has: > > [Install] > WantedBy=multi-user.target > > In %post I run this: > > ls -l /etc/systemd/system/multi-user.target.wants > /usr/bin/systemctl --no-reload enable ods-prx.target > ls -l /etc/systemd/system/multi-user.target.wants > echo "Info: post done" > > When I dnf install myservice I see that the symlink is > setup from the ls -l output in the %post section. > > But later in the output I see this line: > > Info: post done > > Running scriptlet: myservice-2022.1-20220207180603.noarch > Removed /etc/systemd/system/multi-user.target.wants/myservice.target. > > Is this expected? > > How can I stop this happening? > > If its not expected how can I pull apart the RPM to find the code that is > running? > > Barry > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
dnf install removes /etc/systemd/system/multi-user.wants/myservice.target symlink
This is not for a package in Fedora, its for a package I'm working on for Oracle Linux 8. I install /usr/lib/systemd/system/myservice.target that has: [Install] WantedBy=multi-user.target In %post I run this: ls -l /etc/systemd/system/multi-user.target.wants /usr/bin/systemctl --no-reload enable ods-prx.target ls -l /etc/systemd/system/multi-user.target.wants echo "Info: post done" When I dnf install myservice I see that the symlink is setup from the ls -l output in the %post section. But later in the output I see this line: Info: post done Running scriptlet: myservice-2022.1-20220207180603.noarch Removed /etc/systemd/system/multi-user.target.wants/myservice.target. Is this expected? How can I stop this happening? If its not expected how can I pull apart the RPM to find the code that is running? Barry ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: font copies in sphinx generated documentation
This is indeed a can of worms. A previous discussion on the packaging list[1] concluded that, despite the common practice of packaging Sphinx-generated HTML documentation, there is probably no practical way to do so without running afoul of guidelines about bundled or precompiled JavaScript, CSS, and fonts. Furthermore, Doxygen is just as bad. I’ve been packaging PDF documentation instead, where it’s possible to generate it. This is probably OK, as long as you’re not worried about possible embedded fonts. Since I’m not aware of practical open-source tooling to detect and/or remove these; since a PDF that has essential external dependencies is frustratingly and almost uselessly non-“portable”; and since many LaTeX fonts don’t have OpenType versions that could be packaged as system fonts anyway: if embedded fonts in PDFs were an issue then it seems that packaging PDF files would be effectively banned in practice. I don’t think there’s been a substantial discussion on the matter, though. [1] https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/LLUAURXZVADATHK65HBPPBHKF4EM4UC3/ Further clarity on some of these points would be welcome, although I’m personally *not* eager to put myself at the center of a debate about any of these issues. On Mon, Feb 7, 2022, at 10:51 AM, Petr Menšík wrote: > Hi! > > I maintain bind package, which generates html documentation using sphinx > and sphinx_rtd_theme. I admit this format is quite popular. Once I have > noticed that bind-doc package is quite big. When looking why, I have > found not a small number of static copies were generated by > documentation process. > > If I remember correctly, fonts are allowed to be shipped only by font > packages. Not only sphinx packages ships static copies of javascript > underscore and jquery, but it seems every such package includes also set > of fonts contained in its documentation. > > It leads to interesting situation on RHEL9. It ships fonts in supported > packages, which are not shipped in supported repositories. > > Example: > > dnf repoquery --disablerepo=rhel-CRB --whatprovides > '*/fontawesome-webfont.svg' > > I expect many users would like to serve those packages via web servers > to local networks. Is there way to share static contents in multiple > documentation packages and not break at least most common way to share > /usr/share/doc via web server? > > Note: I have attempted to link static contents to > python3-sphinx_rtd_theme. I symlinked directories js and css in _static > dir. I do NOT recommend anyone to follow my way. This way, I cannot > return real directories with real content into the place. Consider that > a blind way not worth following. > > Is there a good way to reduce duplicated documentation content, when > keeping it reasonably working? Are there helpers for that? It seems even > bodhi-server contains quite big stash of fonts files for example. Many > important packages has them bundled. kernel-doc, rust-doc. Do we want that? > > I have found not a single word about it in font exceptions [1]. Is that > okay? It seems guidelines contradicts common practice on this. > > Regards, > Petr > > 1. > https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/#_exceptions > > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?
On 07. 02. 22 17:17, Kevin Kofler via devel wrote: So I would currently tend towards: * postponing the Change to F37, * implementing option 2. for F36 (i.e., adding the option as experimental and disabled by default, which should not need a Change at all), AND * looking further for a proper solution for F37, as I do not believe it cannot be done (and neither does Fabio). And neither do I for the record. I just found it a bit unrealistic to convince the change owners :) -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Neal Gompa wrote: > (Sidebar, I wish the target would be renamed from mingw to windows, Well, in addition to the trademark concerns, that would also lose the distinction from Cygwin. > because it's kind of confusing when we don't even rely on a glibc-nt > port...) That would not really be *Minimalist* GNU for Windows anymore, would it? :-) 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051537] perl-Sereal-Decoder-4.019 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051537 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Resolution|--- |RAWHIDE Fixed In Version||perl-Sereal-Decoder-4.019-1 ||.fc36 Last Closed||2022-02-07 13:49:32 --- Comment #1 from Paul Howarth --- Built for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=82503482 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051537 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Mon, Feb 7, 2022 at 11:20 AM Kevin Kofler via devel wrote: > > Marc-André Lureau wrote: > > Release build should be tested on Windows. It is easy to build and test > > natively with msys2 nowadays, or build for other targets. Why not use > > that? > > Because I do not have a computer running Windows, nor a Windows license. > For my hobbyist game development, I rely on the Fedora MinGW stack to be able to produce Windows builds for them. I do all my own development and work from Fedora Linux and I'd rather not change that. If anything, our MinGW stack is an amazing selling point compared to other distributions, because we provide a usable framework to build applications for Windows. (Sidebar, I wish the target would be renamed from mingw to windows, because it's kind of confusing when we don't even rely on a glibc-nt port...) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Kevin Kofler via devel wrote: > Marc-André Lureau wrote: >> Release build should be tested on Windows. It is easy to build and test >> natively with msys2 nowadays, or build for other targets. Why not use >> that? > > Because I do not have a computer running Windows, nor a Windows license. PS: Well, actually, I still have original CDs of Windows 95 and Windows Me lying around, but those are not going to be practical for modern-day development. I switched to full-time Fedora after my Windows Me installation broke down, and I do not miss Windows at all. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Marc-André Lureau wrote: > Release build should be tested on Windows. It is easy to build and test > natively with msys2 nowadays, or build for other targets. Why not use > that? Because I do not have a computer running Windows, nor a Windows license. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?
Miro Hrončok wrote: > this is about the following Fedora change: > > https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect > > In the tracking bugzilla, the relevant comment is: > > https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4 > > If I understand this correctly, the current implementation is not doing > what the change described and the change owner says the feature cannot be > implemented as described. > > There are several options and we should probably decide what to do before > beta freeze. Hence opening this discussion. > > The change summarizes as "We would like to change a default behavior > dnf/PackageKit/microdnf to install only newly recommended packages on > upgrades." however the current impementation disbales weak depndencies in > various other scenarios, as reported by various of our packagers e.g. in > > Bug 2048394 - dnf should pull weak dependencies in install transaction > Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich > weak dependencies useless > Bug 2042808 - weakdeps not working on rawhide system So, as I understand it, the core of the issue is this: | We have a problem to detect rich dependencies correctly in autodetections | because we do not know whether their conditions were met or not in past. So basically, this leaves only 2 possible options (and the remainder are variants thereof): either assume they were met or assume they were unmet: > The change owner proposed 4 options to move forward. I understand them as > follows: > > 1. do nothing, keep it broken > 2. disable this behavior by default, keep it optional, but keep it broken > 3. do not ignore already broken weak rich deps (partially reverts the > change) > 4. change the behavior on dynamically depending on the dnf command > used (discouraged) The status quo, i.e., 1., assumes they were met. Option 3. would assume they were unmet. Option 2. is like 1. but disables the entire feature by default. Option 4. would attempt to heuristically, depending on the command used, pick the behavior of 1. vs. either 2. or 3.. They are basically all workarounds for the real issue, which is that the previous state cannot be correctly determined. Like Fabio Valentini, I have to wonder why that cannot be done. DNF should have all the required information in its database, or it could query RPM which also has the information in its database. E.g., foo-langpack-xx Supplements: (foo and langpacks-xx) cannot possibly have been already unmet if langpacks-xx was not previously installed. It ought to be possible for DNF to determine that automatically. So I would currently tend towards: * postponing the Change to F37, * implementing option 2. for F36 (i.e., adding the option as experimental and disabled by default, which should not need a Change at all), AND * looking further for a proper solution for F37, as I do not believe it cannot be done (and neither does Fabio). 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051535] perl-Sereal-4.019 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051535 Paul Howarth changed: What|Removed |Added Fixed In Version||perl-Sereal-4.019-1.fc36 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Last Closed||2022-02-07 14:26:14 --- Comment #1 from Paul Howarth --- Built for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=82505075 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051535 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2046802] perl: FTBFS in Fedora rawhide/f36
https://bugzilla.redhat.com/show_bug.cgi?id=2046802 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-5.34.0-485.fc36 Resolution|--- |RAWHIDE Last Closed||2022-02-07 15:42:16 --- Comment #10 from Jitka Plesnikova --- Thanks for the notice, Tulio. I removed the previous changes and successfully rebuilt perl. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2046802 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] 2022-02-07 @ 16:00 UTC - Fedora QA Meeting
Attending today Den lör 5 feb. 2022 02:18Adam Williamson skrev: > # Fedora Quality Assurance Meeting > # Date: 2022-02-07 > # Time: 16:00 UTC > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > # Location: #fedora-meeting on irc.libera.chat > > Greetings testers! > > It's Branch week, Rawhide's broken, and there's some other stuff we > could discuss, so let's get together for a meeting on Monday! > > If anyone has any other items for the agenda, please reply to this > email and suggest them! Thanks. > > == Proposed Agenda Topics == > > 1. Previous meeting follow-up > 2. Fedora 36 status and Branching > 3. Current criteria / test case proposals > 4. Test Day / community event status > 5. Open floor > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > test-announce mailing list -- test-annou...@lists.fedoraproject.org > To unsubscribe send an email to > test-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
font copies in sphinx generated documentation
Hi! I maintain bind package, which generates html documentation using sphinx and sphinx_rtd_theme. I admit this format is quite popular. Once I have noticed that bind-doc package is quite big. When looking why, I have found not a small number of static copies were generated by documentation process. If I remember correctly, fonts are allowed to be shipped only by font packages. Not only sphinx packages ships static copies of javascript underscore and jquery, but it seems every such package includes also set of fonts contained in its documentation. It leads to interesting situation on RHEL9. It ships fonts in supported packages, which are not shipped in supported repositories. Example: dnf repoquery --disablerepo=rhel-CRB --whatprovides '*/fontawesome-webfont.svg' I expect many users would like to serve those packages via web servers to local networks. Is there way to share static contents in multiple documentation packages and not break at least most common way to share /usr/share/doc via web server? Note: I have attempted to link static contents to python3-sphinx_rtd_theme. I symlinked directories js and css in _static dir. I do NOT recommend anyone to follow my way. This way, I cannot return real directories with real content into the place. Consider that a blind way not worth following. Is there a good way to reduce duplicated documentation content, when keeping it reasonably working? Are there helpers for that? It seems even bodhi-server contains quite big stash of fonts files for example. Many important packages has them bundled. kernel-doc, rust-doc. Do we want that? I have found not a single word about it in font exceptions [1]. Is that okay? It seems guidelines contradicts common practice on this. Regards, Petr 1. https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/#_exceptions -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2048959] Add perl-GraphViz to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2048959 Xavier Bachelot changed: What|Removed |Added CC||xav...@bachelot.org Flags||needinfo?(lkund...@v3.sk) --- Comment #1 from Xavier Bachelot --- Hi Lubomir, Will you be able to branch and build perl-Graphviz for EPEL 9 ? A perl-GraphViz scratch build succeeds: https://koji.fedoraproject.org/koji/taskinfo?taskID=82505761 I can take care of the build if you grant me access. My FAS username is xavierb. Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2048959 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220207.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 6 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 35/228 (x86_64), 25/159 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220205.n.1): ID: 1120758 Test: x86_64 Server-dvd-iso install_resize_lvm URL: https://openqa.fedoraproject.org/tests/1120758 ID: 1120764 Test: x86_64 Server-dvd-iso install_standard_partition_ext4 URL: https://openqa.fedoraproject.org/tests/1120764 ID: 1120766 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1120766 ID: 1120768 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/1120768 ID: 1120794 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1120794 ID: 1120795 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1120795 ID: 1120805 Test: x86_64 Workstation-live-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1120805 ID: 1120880 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/1120880 ID: 1120888 Test: aarch64 Server-dvd-iso install_repository_nfs_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1120888 ID: 1120947 Test: aarch64 Workstation-raw_xz-raw.xz base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1120947 ID: 1120948 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1120948 ID: 1120969 Test: x86_64 Workstation-upgrade gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1120969 ID: 1120995 Test: aarch64 Workstation-upgrade evince@uefi URL: https://openqa.fedoraproject.org/tests/1120995 ID: 1121003 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/1121003 ID: 1121008 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/1121008 ID: 1121022 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/1121022 ID: 1121032 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1121032 ID: 1121038 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/1121038 ID: 1121041 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/1121041 ID: 1121114 Test: aarch64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1121114 Old failures (same test failed in Fedora-Rawhide-20220205.n.1): ID: 1120774 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1120774 ID: 1120778 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1120778 ID: 1120785 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1120785 ID: 1120786 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1120786 ID: 1120787 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/1120787 ID: 1120789 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1120789 ID: 1120791 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1120791 ID: 1120798 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1120798 ID: 1120807 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1120807 ID: 1120818 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/1120818 ID: 1120821 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1120821 ID: 1120846 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1120846 ID: 1120899 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/1120899 ID: 1120901 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1120901 ID: 1120913 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1120913 ID: 1120915 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1120915 ID: 1120917 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1120917
[Bug 2031753] perl-Authen-Captcha for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031753 --- Comment #3 from Xavier Bachelot --- Hi Lubomir, All dependencies are available and a scratch build succeeds: https://koji.fedoraproject.org/koji/taskinfo?taskID=82495838 I can take care of the build if you grant me access. My FAS is xavierb. Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031753 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?
On Mon, Feb 7, 2022 at 3:26 PM Miro Hrončok wrote: > > > 3. do not ignore already broken weak rich deps (partially reverts the > > change) > > This sounds like a possible path forward -- it would probably still be an > improvement over the the Fedora 35 status quo, however the results might be > quite surprising for the users. If we decide to do this, I think we should > postpone to Fedora 37 neverthelss to see it in action and figure out if it's > actually a good idea or an UX nightmare. Wouldn't that revert the primary reason why users wanted this features? I.e. "I have not installed weak dependency of package X on purpose, so I also don't want updates of package X to pull them in again"? It sounds like it's "not possible" to check whether weak dependencies were satisfied before a transaction (I wonder why? dnf has all the data here), but then, this feature is basically useless, and only breaks some behaviour in unexpected ways, unless I misunderstand something? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Should python3dist(...) provides generator fail when the version is = 0?
On Monday, 7 February 2022 13.58.24 WET Charalampos Stratakis wrote: > Makes a lot of sense to error out the build in this case. I agree. I can not imagine a case where this makes sense, or if I ever found an example where that was ever the case... -- José Abílio ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051536] perl-Sereal-Encoder-4.019 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051536 Paul Howarth changed: What|Removed |Added Resolution|--- |RAWHIDE Status|NEW |CLOSED Fixed In Version||perl-Sereal-Encoder-4.019-1 ||.fc36 Doc Type|--- |If docs needed, set a value Last Closed||2022-02-07 14:12:34 --- Comment #1 from Paul Howarth --- Built for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=82504410 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051536 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?
On 07. 02. 22 15:17, Miro Hrončok wrote: Hello, this is about the following Fedora change: https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect In the tracking bugzilla, the relevant comment is: https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4 If I understand this correctly, the current implementation is not doing what the change described and the change owner says the feature cannot be implemented as described. There are several options and we should probably decide what to do before beta freeze. Hence opening this discussion. The change summarizes as "We would like to change a default behavior dnf/PackageKit/microdnf to install only newly recommended packages on upgrades." however the current impementation disbales weak depndencies in various other scenarios, as reported by various of our packagers e.g. in Bug 2048394 - dnf should pull weak dependencies in install transaction Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich weak dependencies useless Bug 2042808 - weakdeps not working on rawhide system The change owner proposed 4 options to move forward. I understand them as follows: And here I am to reply to myself. 1. do nothing, keep it broken I pretty much dislike this option. Clearly, the current behavior is not what was approved in this change proposal. For me, it's a bad option. 2. disable this behavior by default, keep it optional, but keep it broken This only makes sense if it's likely to get fixed and enabled again in later Fedora release. If the plan is to disable it by default and never touch it again, I suppose we might as well revert it entirely. I would very much to see the change happening as it was advertised, even if we cannot make ti to Fedora 36. For the sake of an open minded discussion, I am ignoring the fact that the change owners themselves don't consider it doable (I think that it is doable, but I honestly don't know if it is realistic with the current resources). 3. do not ignore already broken weak rich deps (partially reverts the change) This sounds like a possible path forward -- it would probably still be an improvement over the the Fedora 35 status quo, however the results might be quite surprising for the users. If we decide to do this, I think we should postpone to Fedora 37 neverthelss to see it in action and figure out if it's actually a good idea or an UX nightmare. 4. change the behavior on dynamically depending on the dnf command used (discouraged) As stated by the change owner in the bugzilla, this is probably not a good idea. Even when the user types `dnf install` it sometimes upgrades some already installed packages and even if they type `dnf upgrade` it sometimes installs some new packages. (Go see the linked comment for details.) Please let us know what you think is best or if there is a better solution. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Orphaning javahelp2
Hi,
I have just orphaned javahelp2:
https://src.fedoraproject.org/rpms/javahelp2
As far as I can tell, nothing needs it:
$ repoquery -q --repo=rawhide{,-source,-modular} --whatrequires '*javahelp*'
Upstream has been dead for years and the last commit was in 2017:
https://github.com/javaee/javahelp/
javahelp2 implements a Java Swing Platform Look and Feel - which
requires access to internal APIs and those have been strongly
encapsulated and locked down in OpenJDK 17. It now fails to build from
source and will probably need extensive changes to build from source.
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)
It looks like that the feature made a user case with langpacks broken. See additional reports: Bug 2048394 - dnf should pull weak dependencies in install transaction Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich weak dependencies useless Bug 2042808 - weakdeps not working on rawhide system The feature was requested: Bug 2005305 - dnf should not pull (already unmet) weak dependencies on updates Bug 1699672 - RFE: dnf should not pull (already broken) weak dependencies on updates Firs of all I need to clarify that the feature cannot be implemented only on upgrades - because there are technical reasons for that - 1. DNF creates one transaction for all operations (install, upgrades are performed together). 2.a Install operation or commands (not only install) also triggers update. (example - I have already installed foo-1-1.noarch. Then I will install bar-2-2.noarch that requires foo-2. It means the install command will trigger upgrade that dnf cannot detect in advance. And if foo recommends something, it will be installed) 2.b Install operation with --best (default in RHEL) triggers always upgrade when package is already installed but in lower version. Be honest I do not know what to do. Basically I see only 3 option with one additional: 1. Keep it like it is 2. Disable autodetection 3. Start to ignore rich dependencies for autodetection of unmet weak dependencies. We have a problem to detect rich dependencies correctly in autodetections because we do not know whether their conditions were met or not in past. 4. In theory the auto-detection can be only triggered by upgrade command but it will create an inconsistency in DNF behavior when upgrade operation is triggered by the another command (install, buildeps, downgrade, ...) - not preferable, see above. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
What should we do about the "Install only newly recommended packages on upgrades" F36 change?
Hello, this is about the following Fedora change: https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect In the tracking bugzilla, the relevant comment is: https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4 If I understand this correctly, the current implementation is not doing what the change described and the change owner says the feature cannot be implemented as described. There are several options and we should probably decide what to do before beta freeze. Hence opening this discussion. The change summarizes as "We would like to change a default behavior dnf/PackageKit/microdnf to install only newly recommended packages on upgrades." however the current impementation disbales weak depndencies in various other scenarios, as reported by various of our packagers e.g. in Bug 2048394 - dnf should pull weak dependencies in install transaction Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich weak dependencies useless Bug 2042808 - weakdeps not working on rawhide system The change owner proposed 4 options to move forward. I understand them as follows: 1. do nothing, keep it broken 2. disable this behavior by default, keep it optional, but keep it broken 3. do not ignore already broken weak rich deps (partially reverts the change) 4. change the behavior on dynamically depending on the dnf command used (discouraged) (Go see the linked comment for details.) Please let us know what you think is best or if there is a better solution. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2046802] perl: FTBFS in Fedora rawhide/f36
https://bugzilla.redhat.com/show_bug.cgi?id=2046802 Tulio Magno Quites Machado Filho changed: What|Removed |Added CC||tul...@ascii.art.br --- Comment #9 from Tulio Magno Quites Machado Filho --- I can't reproduce this issue with gcc-12.0.1-0.6.fc36. I tested with commit a471b953f462f, which doesn't disable the 2 test cases. I suspect this issue has been fixed by bug 2050569. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2046802 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Should python3dist(...) provides generator fail when the version is = 0?
On Sat, Jan 29, 2022 at 10:12 PM Miro Hrončok wrote: > Hello Pythonistas, > > today, I've looked up packages in rawhide providing python3dist(...) = 0 > and I > opened bugzillas for them: > > https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0 > > While version 0 (or equal versions like 0.0 or 0.0.0) is probably > technically > valid, it most certainly indicates a packaging error (most likely but not > necessarily a downstream packaging error). > > Should we prevent this error from happening by explicitly erroring (and > failing > the build) when it happens? I think it would make the dependency > generators > more robust. > > In an unlikely scenario when packagers actually want to package version 0, > they > can reach out and we can allow it via some configuration (but [YAGNI], so > I > don't want to clutter the generator with yet another option right away). > > [YAGNI] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > python-devel mailing list -- python-devel@lists.fedoraproject.org > To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > Makes a lot of sense to error out the build in this case. -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-SQL-Translator] PR #1: Split GraphViz-dependent components into subpackages
jplesnik commented on the pull-request: `Split GraphViz-dependent components into subpackages` that you are following: `` The change looks fine for me. I only recommend to change the sub package name to sqlt-graph. It means use in spec: %package -n sqlt-graph %description -n sqlt-graph %files -n sqlt-graph And move /usr/share/man/man1/sqlt-graph.1.gz to the subpackage sqlt-graph Please rebase the PR, then I merge it. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-SQL-Translator/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051537] New: perl-Sereal-Decoder-4.019 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051537 Bug ID: 2051537 Summary: perl-Sereal-Decoder-4.019 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Sereal-Decoder Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, jples...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 4.019 Current version/release in rawhide: 4.018-6.fc36 URL: http://search.cpan.org/dist/Sereal-Decoder/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/8066/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051537 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051536] New: perl-Sereal-Encoder-4.019 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051536 Bug ID: 2051536 Summary: perl-Sereal-Encoder-4.019 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Sereal-Encoder Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, jples...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 4.019 Current version/release in rawhide: 4.018-5.fc36 URL: http://search.cpan.org/dist/Sereal-Encoder/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/8065/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051536 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051535] New: perl-Sereal-4.019 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051535 Bug ID: 2051535 Summary: perl-Sereal-4.019 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Sereal Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 4.019 Current version/release in rawhide: 4.018-5.fc36 URL: http://search.cpan.org/dist/Sereal/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/7605/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051535 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051011] perl-App-Cme-1.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051011 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-Cme-1.037-1.fc36 Resolution|--- |RAWHIDE Last Closed||2022-02-07 12:30:47 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051011 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
non-responsive maintainer: spredzy
Hello, does anyone know how to reach spredzy (CC'd)? https://bugzilla.redhat.com/show_bug.cgi?id=2051519 Regards, Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051011] perl-App-Cme-1.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2051011 Jitka Plesnikova changed: What|Removed |Added CC|jples...@redhat.com | Doc Type|--- |If docs needed, set a value 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=2051011 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2050091] perl-CGI-4.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2050091 --- Comment #1 from Fedora Update System --- FEDORA-2022-632a984213 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-632a984213 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2050091 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Marc-André Lureau wrote: >FYI, UCRT can be installed on various Windows: >https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c Sure, it *can* be. But that doesn't mean I can rely on my end users to be able to do that. Currently I can ship a single 32-bit MSVCRT binary and be sure it'll work on any version of Windows that matters. It'll also work in Wine or ReactOS. >Release build should be tested on Windows. It is easy to build and test >natively with msys2 nowadays, or build for other targets. Why not use that? Because I don't consider Microsoft Windows to be a suitable development platform. I have Windows virtual machines for testing but they expire every 90 days. Indeed, one of my chores for today is to reinstall three Windows VMs that have expired. I don't want to then have to reinstall a development environment when I already have everything I need on Fedora. Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Mon, Feb 7, 2022 at 2:00 PM Daniel P. Berrangé wrote: > On Mon, Feb 07, 2022 at 01:38:17PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé > > wrote: > > > > > On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > > > > Hi > > > > > > > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > > > > devel@lists.fedoraproject.org> wrote: > > > > > > > > > For the record: > > > > > > > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > > > > MSVCRT […] Works out of the box on every Microsoft Windows > versions. > > > > > > > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 > OSR > > > 2. > > > > > The original Windows 95, with or without the only service pack > released > > > > > for > > > > > it (SP1, because OSR 2 was not released as a service pack, only as > an > > > "OEM > > > > > service release" for new computers), shipped only the even older > > > > > CRTDLL.DLL > > > > > (which MinGW stopped supporting years ago) out of the box, > MSVCRT.DLL > > > had > > > > > to > > > > > be installed through a redistributable (which was included with > many > > > > > applications including Microsoft Office, but it was not part of the > > > > > operating system). > > > > > > > > > > But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows > > > version > > > > > numbers are not anywhere near monotonic ;-) ), MSVCRT is included > out > > > of > > > > > the > > > > > box, UCRT is not. Is it really a good default to depend on a > runtime > > > > > library > > > > > that is only included in Windows ≥ 10? > > > > > > > > > > > > > This proposal doesn't change the default. Although we can discuss > whether > > > > deprecating msvcrt support in Fedora-MinGW would make sense today. > > > > > > There's a variety of sites claiming to have stats on different > > > Windows versions. They all show Windows 10 with the majority, > > > but disagree on just how much older stuff still gets used. As > > > one example though, this shows Windows 7 with 12 % and > > > Windows 8.1 on 3 %. That 15% is too significant to declare > > > that MSVCRT is deprecated yet. > > > > > > > > > > https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/ > > > > > > FYI, UCRT can be installed on various Windows: > > > https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c > > Can be done automatically by the application's own MSI/NSIS installer ? > Requiring the users to do that separately is not desirable. > Those are MSU, they can be installed with wusa.exe. From NSIS should be trivial. With WiX, MsuPackage (not supported by wixl atm) or CustomAction. > > > We should also look at the cost/benefit for Fedora to ship and maintain > > MSVCRT environments. > > Or we could look at the cost/benefit of adding UCRT to Fedora, since > that's the change being proposed in this thread. In this thread > > > https://lists.fedoraproject.org/archives/list/mi...@lists.fedoraproject.org/message/6G2EAKYSNWMLDBWZ2BYQS3BEIRKJ2EEG/ > > you're proposing that Fedora stop shipping any mingw packages at all, > and just rely on MSys2 to do the packaging work. If that is the desired > solution, is it actually a benefit to spend any effort adding -ucrt64 > sub-RPMs to every mingw package in Fedora today ? > If the msys2 solution works, then there isn't much benefit shipping mingw*-packages, except for what Sandro said, to sync the Fedora native and windows versions. -- Marc-André Lureau ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: how to do epel8 fedpkg mockbuild?
I wrote: > What do you need to do these days to run an epel-8 mock build? > fedpkg mockbuild fails for me with > > Error: Error downloading packages: > Status code: 403 for > https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/audit-libs-3.0-0.17.20191104git1c2f876.el8.x86_64.rpm > (IP: 38.145.60.16) It turns out that it works if you link, say, the alma+epel mock config into ~/.config/mock/epel-8-x86_64.cfg, per Richard Shaw's question at around the same time. I might have guessed that was the problem if it reported an error about epel-8-x86_64.cfg rather than failing to download RHEL rpms. (I just had alma linked to default.cfg on the RHEL8 system I use, not to epel-8.) ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
As noted in the mingw list thread, for me the objective of version parity between native and mingw packages of the current mingw-environment is a big selling point. My real-world experience reflects what others shared in this post, namely that by far most issues which pop up during testing are target independent, i.e. will affect both the native build as the cross-compiled build. It's true that version partiy is not 100% reflected in the current package state, but I still believe the overall state is pretty good, and personally I'd rather look at building cross and native packages from the same spec to reduce the maintenance burden. I know that there was a proposal in this direction some months ago, I'd like to start moving in this direction at least with packages where I maintain both the native and the cross packages. Yes, I proposed that last year. I was supposed to move it forward by providing a copr repo illustrating it in real world, but I'm afraid I got side tracked. I also wasn't able to participate in the discussion having had too much going on then, but I'd be happy to help (re-)launching the effort. Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Mon, Feb 07, 2022 at 10:50:00AM +0100, Sandro Mani wrote: > > On 07.02.22 10:29, Marc-André Lureau wrote: > > Hi > > > > On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé > > wrote: > > > > On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel > > wrote: > > > Marc-André Lureau wrote: > > > > Fwiw, given that the primary use case for a cross-toolchain is for > > > > developer needs, I think it is reasonable to have only UCRT > > target in the > > > > future. > > > > > > > > Projects releasing for Windows should probably natively build > > and test > > > > their releases with Msys2, and they can do so for msvcrt targets. > > > > > > Well, with cross-MinGW and cross-NSIS, I can package software > > for Windows > > > without ever touching a Windows machine. I have done so more > > than once > > > already. I do not even have a Windows installation on which I > > can run Msys2. > > > > Exactly, this is the precise reason why a group of us started > > the Fedora mingw packaging effort all those years ago. > > > > I have a Windows machine for testing / debugging on, but it is so > > much simpler if we can do cross builds from Linux, as it means we > > don't have to switch context between machines when developing. > > > > > > Nowadays, with the built-in ssh server, git, msys2, meson, docker and > > CI..., developing for Windows is much easier than it was 10y ago! > > > > For me, it's barely a context switch, sync the repo and run "meson > > test" (or cmake) there. I haven't tried the shared folder yet. Testing > > the windows build is not something you can really do on Linux... So I > > will prefer a native build whenever possible. > > > > Anyway, no need to convince me about the need for cross-compilers :) > > However, I regret that we have undermaintained and duplicated > > mingw*-pkg. I am looking at whether we can use msys2 packages instead > > (for developpers). > > As noted in the mingw list thread, for me the objective of version parity > between native and mingw packages of the current mingw-environment is a big > selling point. My real-world experience reflects what others shared in this > post, namely that by far most issues which pop up during testing are target > independent, i.e. will affect both the native build as the cross-compiled > build. It's true that version partiy is not 100% reflected in the current > package state, but I still believe the overall state is pretty good, and > personally I'd rather look at building cross and native packages from the > same spec to reduce the maintenance burden. I know that there was a proposal > in this direction some months ago, I'd like to start moving in this > direction at least with packages where I maintain both the native and the > cross packages. Yes, I proposed that last year. I was supposed to move it forward by providing a copr repo illustrating it in real world, but I'm afraid I got side tracked. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Mon, Feb 07, 2022 at 01:38:17PM +0400, Marc-André Lureau wrote: > Hi > > On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé > wrote: > > > On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > > > Hi > > > > > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > > > devel@lists.fedoraproject.org> wrote: > > > > > > > For the record: > > > > > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > > > MSVCRT […] Works out of the box on every Microsoft Windows versions. > > > > > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR > > 2. > > > > The original Windows 95, with or without the only service pack released > > > > for > > > > it (SP1, because OSR 2 was not released as a service pack, only as an > > "OEM > > > > service release" for new computers), shipped only the even older > > > > CRTDLL.DLL > > > > (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL > > had > > > > to > > > > be installed through a redistributable (which was included with many > > > > applications including Microsoft Office, but it was not part of the > > > > operating system). > > > > > > > > But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows > > version > > > > numbers are not anywhere near monotonic ;-) ), MSVCRT is included out > > of > > > > the > > > > box, UCRT is not. Is it really a good default to depend on a runtime > > > > library > > > > that is only included in Windows ≥ 10? > > > > > > > > > > This proposal doesn't change the default. Although we can discuss whether > > > deprecating msvcrt support in Fedora-MinGW would make sense today. > > > > There's a variety of sites claiming to have stats on different > > Windows versions. They all show Windows 10 with the majority, > > but disagree on just how much older stuff still gets used. As > > one example though, this shows Windows 7 with 12 % and > > Windows 8.1 on 3 %. That 15% is too significant to declare > > that MSVCRT is deprecated yet. > > > > > > https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/ > > > FYI, UCRT can be installed on various Windows: > https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c Can be done automatically by the application's own MSI/NSIS installer ? Requiring the users to do that separately is not desirable. > We should also look at the cost/benefit for Fedora to ship and maintain > MSVCRT environments. Or we could look at the cost/benefit of adding UCRT to Fedora, since that's the change being proposed in this thread. In this thread https://lists.fedoraproject.org/archives/list/mi...@lists.fedoraproject.org/message/6G2EAKYSNWMLDBWZ2BYQS3BEIRKJ2EEG/ you're proposing that Fedora stop shipping any mingw packages at all, and just rely on MSys2 to do the packaging work. If that is the desired solution, is it actually a benefit to spend any effort adding -ucrt64 sub-RPMs to every mingw package in Fedora today ? > Release build should be tested on Windows. It is easy to build and test > natively with msys2 nowadays, or build for other targets. Why not use that? See my answers to this question elsewhere in this thread. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051034] Removal of gethostbyname2 breaks Shorewall6
https://bugzilla.redhat.com/show_bug.cgi?id=2051034 --- Comment #4 from Michal Josef Spacek --- The best way is rewrite Shorewall6 to remove dependency to Socket6. There are IO::Socket::IP or Socket with IPv6 support now. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051034 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On 07.02.22 10:29, Marc-André Lureau wrote: Hi On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé wrote: On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote: > Marc-André Lureau wrote: > > Fwiw, given that the primary use case for a cross-toolchain is for > > developer needs, I think it is reasonable to have only UCRT target in the > > future. > > > > Projects releasing for Windows should probably natively build and test > > their releases with Msys2, and they can do so for msvcrt targets. > > Well, with cross-MinGW and cross-NSIS, I can package software for Windows > without ever touching a Windows machine. I have done so more than once > already. I do not even have a Windows installation on which I can run Msys2. Exactly, this is the precise reason why a group of us started the Fedora mingw packaging effort all those years ago. I have a Windows machine for testing / debugging on, but it is so much simpler if we can do cross builds from Linux, as it means we don't have to switch context between machines when developing. Nowadays, with the built-in ssh server, git, msys2, meson, docker and CI..., developing for Windows is much easier than it was 10y ago! For me, it's barely a context switch, sync the repo and run "meson test" (or cmake) there. I haven't tried the shared folder yet. Testing the windows build is not something you can really do on Linux... So I will prefer a native build whenever possible. Anyway, no need to convince me about the need for cross-compilers :) However, I regret that we have undermaintained and duplicated mingw*-pkg. I am looking at whether we can use msys2 packages instead (for developpers). As noted in the mingw list thread, for me the objective of version parity between native and mingw packages of the current mingw-environment is a big selling point. My real-world experience reflects what others shared in this post, namely that by far most issues which pop up during testing are target independent, i.e. will affect both the native build as the cross-compiled build. It's true that version partiy is not 100% reflected in the current package state, but I still believe the overall state is pretty good, and personally I'd rather look at building cross and native packages from the same spec to reduce the maintenance burden. I know that there was a proposal in this direction some months ago, I'd like to start moving in this direction at least with packages where I maintain both the native and the cross packages. Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive packagers: lef, msehnout, shaneallcroft
On Mon, Feb 7, 2022 at 9:58 AM Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > The packagers listed here have been receiving a daily email asking them to > either adjust their bugzilla or their FAS account so the email address in FAS > matches an existing bugzilla account. > > Having a bugzilla account is mandatory per: > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account > > - msehnout contacted since December 15th > > msehnout is watching rpms/bind > msehnout is watching rpms/bind99 > msehnout is maintainer of rpms/ipcalc > msehnout is watching rpms/libpcap > msehnout is maintainer of rpms/osbuild > msehnout is maintainer of rpms/osbuild-composer > msehnout is watching rpms/pure-ftpd > msehnout is watching rpms/tcpdump > msehnout is watching rpms/vsftpd > msehnout is watching rpms/wireshark > > (I will be opening a FESCo ticket for msehnout right now as this is the second > email sent to the devel list) > > - shaneallcroft contacted since January 28th > > shaneallcroft is main admin of rpms/pyplane > shaneallcroft has a bugzilla override on rpms/pyplane > > - lef contacted since January 22nd > > (lef's package list is quite large, so I'm putting it at the very end of this > email) We already went through the non-responsive maintainer process for lef in 2019: https://pagure.io/fesco/issue/2160 Looks like the script to remove them from packages either hasn't been around, or hasn't been run (or they since came back and added themselves back on everything, but otherwise didn't contribute, so I doubt that possibility). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220207.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220206.0): ID: 1120609 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1120609 ID: 1120622 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1120622 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Mon, Feb 07, 2022 at 01:29:45PM +0400, Marc-André Lureau wrote: > Hi > > On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé > wrote: > > > On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote: > > > Marc-André Lureau wrote: > > > > Fwiw, given that the primary use case for a cross-toolchain is for > > > > developer needs, I think it is reasonable to have only UCRT target in > > the > > > > future. > > > > > > > > Projects releasing for Windows should probably natively build and test > > > > their releases with Msys2, and they can do so for msvcrt targets. > > > > > > Well, with cross-MinGW and cross-NSIS, I can package software for > > Windows > > > without ever touching a Windows machine. I have done so more than once > > > already. I do not even have a Windows installation on which I can run > > Msys2. > > > > Exactly, this is the precise reason why a group of us started > > the Fedora mingw packaging effort all those years ago. > > > > I have a Windows machine for testing / debugging on, but it is so > > much simpler if we can do cross builds from Linux, as it means we > > don't have to switch context between machines when developing. > > > > Nowadays, with the built-in ssh server, git, msys2, meson, docker and > CI..., developing for Windows is much easier than it was 10y ago! That's an entire second OS and suite of development tools to maintain on an ongoing basis. If you're working on this every day, maybe that's a worthwhile investment, but for most developers that's not at all compelling. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé wrote: > On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > > devel@lists.fedoraproject.org> wrote: > > > > > For the record: > > > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > > MSVCRT […] Works out of the box on every Microsoft Windows versions. > > > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR > 2. > > > The original Windows 95, with or without the only service pack released > > > for > > > it (SP1, because OSR 2 was not released as a service pack, only as an > "OEM > > > service release" for new computers), shipped only the even older > > > CRTDLL.DLL > > > (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL > had > > > to > > > be installed through a redistributable (which was included with many > > > applications including Microsoft Office, but it was not part of the > > > operating system). > > > > > > But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows > version > > > numbers are not anywhere near monotonic ;-) ), MSVCRT is included out > of > > > the > > > box, UCRT is not. Is it really a good default to depend on a runtime > > > library > > > that is only included in Windows ≥ 10? > > > > > > > This proposal doesn't change the default. Although we can discuss whether > > deprecating msvcrt support in Fedora-MinGW would make sense today. > > There's a variety of sites claiming to have stats on different > Windows versions. They all show Windows 10 with the majority, > but disagree on just how much older stuff still gets used. As > one example though, this shows Windows 7 with 12 % and > Windows 8.1 on 3 %. That 15% is too significant to declare > that MSVCRT is deprecated yet. > > > https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/ FYI, UCRT can be installed on various Windows: https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c We should also look at the cost/benefit for Fedora to ship and maintain MSVCRT environments. If it's merely for developers to check the build, one target is probably enough. Release build should be tested on Windows. It is easy to build and test natively with msys2 nowadays, or build for other targets. Why not use that? -- Marc-André Lureau ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive packagers: lef, msehnout, shaneallcroft
On Mon, Feb 07, 2022 09:58:07 +0100, Pierre-Yves Chibon wrote: > Good Morning Everyone, Hello, > - shaneallcroft contacted since January 28th > > shaneallcroft is main admin of rpms/pyplane > shaneallcroft has a bugzilla override on rpms/pyplane Shane is active. I'll contact him on the channels and ask him to fix this. (He's usually online in the Neuro-SIG matrix channel) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé wrote: > On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote: > > Marc-André Lureau wrote: > > > Fwiw, given that the primary use case for a cross-toolchain is for > > > developer needs, I think it is reasonable to have only UCRT target in > the > > > future. > > > > > > Projects releasing for Windows should probably natively build and test > > > their releases with Msys2, and they can do so for msvcrt targets. > > > > Well, with cross-MinGW and cross-NSIS, I can package software for > Windows > > without ever touching a Windows machine. I have done so more than once > > already. I do not even have a Windows installation on which I can run > Msys2. > > Exactly, this is the precise reason why a group of us started > the Fedora mingw packaging effort all those years ago. > > I have a Windows machine for testing / debugging on, but it is so > much simpler if we can do cross builds from Linux, as it means we > don't have to switch context between machines when developing. > Nowadays, with the built-in ssh server, git, msys2, meson, docker and CI..., developing for Windows is much easier than it was 10y ago! For me, it's barely a context switch, sync the repo and run "meson test" (or cmake) there. I haven't tried the shared folder yet. Testing the windows build is not something you can really do on Linux... So I will prefer a native build whenever possible. Anyway, no need to convince me about the need for cross-compilers :) However, I regret that we have undermaintained and duplicated mingw*-pkg. I am looking at whether we can use msys2 packages instead (for developpers). > I rather wish we had full cross build facilities for all Fedora > arches in fact. As well as for Mingw, upstream we cross build > libvirt / QEMU for all non-x86 arches too by simplying having > a set of containers populated with all the relevant cross compilers > and foreign libraries. While we can use Fedora for our Mingw cross > targets, we have to use Debian for all the Linux non-x86 targets. > > It is very compelling to be able to just run things like > >make docker-build@debian-ppc64el-cross > >make docker-build@fedora-win32-cross > > giving throwaway container buildroots, instead of having to deal with > full VM installs. > I also wish we would have more cross-compilers available. I imagine with use of container/namespaces, the target Fedora sys-root could be simply mounted in a well-known location (instead of duplicating packages, or developing a rpm multi-arch solution) -- Marc-André Lureau ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: some dnf dependency quirks in rawhide?
On 2/7/22 01:00, Marius Schwarz wrote: Am 06.02.22 um 22:43 schrieb Fabio Valentini: On Sun, Feb 6, 2022 at 10:34 PM Marius Schwarz wrote: Hi, deinstalling the rpmfusion package "pulseaudio-module-bluetooth-freeworld", which should not be required by anything: [root@fedorapine ~]# rpm -q --whatrequires pulseaudio-module-bluetooth-freeworld Kein Paket benötigt pulseaudio-module-bluetooth-freeworld (no package needs ... ) Looks like you fell into the trap of not considering "virtual provides". The rpm query you pasted above only queries for exact matches, but not for dependencies on virtual provides provided by the package of the same name. Yes, that may cause the missing output in rpm, but it wasn't the point of my post: Why can a rpmfusion rpm be so deep "chained" into the tree, that it removes i.e. gnome-shell, a major package from Fedora repo, which does not have even heared about that subpackage in rpmfusion. if the "pulseaudio-module-bluetooth-freeworld" package has been installed independently from all those (in the erase tree) additional considered packages, why can it trigger such a cascade? It is simply not important enough to cause this. If it never had been installed, the functionality of all those apps would not change. I want to understand, why this could happen. What caused this big cascade, if we add some unimportant part, noone needs to operate correctly?!? You need to read the previous email again more carefully. The chain is gnome-shell -> gnome-bluetooth -> pulseaudio-module-bluetooth. # dnf repoquery --whatprovides pulseaudio-module-bluetooth pipewire-pulseaudio-0:0.3.45-1.fc35.x86_64 pulseaudio-module-bluetooth-0:15.0-2.fc35.x86_64 pulseaudio-module-bluetooth-freeworld-0:1.4-8.fc35.x86_64 You can only have one of those installed at a time, they conflict with each other. But you have to have one installed for gnome-shell. If you remove the package that is currently providing that requirement, you will take out gnome-shell and many other things as well. It's not an "additional" package. At some point you must have installed it yourself and it would have required removing the pulseaudio-module-bluetooth package at the same time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > Hi > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > > > For the record: > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > MSVCRT […] Works out of the box on every Microsoft Windows versions. > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. > > The original Windows 95, with or without the only service pack released > > for > > it (SP1, because OSR 2 was not released as a service pack, only as an "OEM > > service release" for new computers), shipped only the even older > > CRTDLL.DLL > > (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had > > to > > be installed through a redistributable (which was included with many > > applications including Microsoft Office, but it was not part of the > > operating system). > > > > But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version > > numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of > > the > > box, UCRT is not. Is it really a good default to depend on a runtime > > library > > that is only included in Windows ≥ 10? > > > > This proposal doesn't change the default. Although we can discuss whether > deprecating msvcrt support in Fedora-MinGW would make sense today. There's a variety of sites claiming to have stats on different Windows versions. They all show Windows 10 with the majority, but disagree on just how much older stuff still gets used. As one example though, this shows Windows 7 with 12 % and Windows 8.1 on 3 %. That 15% is too significant to declare that MSVCRT is deprecated yet. https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/ > Fwiw, given that the primary use case for a cross-toolchain is for > developer needs, I think it is reasonable to have only UCRT target in the > future. At some point off in the future maybe, but we would need to see the stats for older Windows 7/8 releases drop significantly lower than they are today. > > Projects releasing for Windows should probably natively build and test > their releases with Msys2, and they can do so for msvcrt targets. Testing yes, but building no. I do all Windows builds using Fedora cross compilation, using pristine mock chroots. The idea of building under Msys2 on a Windows machine I now have to maintain in a pristine condition, is not at all appealing. I don't want to have to figure out a different way to build that's equivalent to what mock offers me. It is much more appealing to have a single machine from which I can do both Linux and Windows builds using the same basic infra for both Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2050091] perl-CGI-4.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2050091 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-CGI-4.54-1.fc36 Status|NEW |MODIFIED Doc Type|--- |If docs needed, set a value CC|jples...@redhat.com,| |mmasl...@redhat.com,| |mspa...@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=2050091 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20220207.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220206.0): ID: 1120591 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1120591 ID: 1120604 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1120604 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1964649] F35FailsToInstall: perl-MouseX-App-Cmd
https://bugzilla.redhat.com/show_bug.cgi?id=1964649 Miro Hrončok changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #3 from Miro Hrončok --- This package has been orphaned. You can pick it up at https://src.fedoraproject.org/rpms/perl-MouseX-App-Cmd by clicking button "Take". If nobody picks it up, it will be retired and removed from a distribution. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1964649 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: some dnf dependency quirks in rawhide?
Am 06.02.22 um 22:43 schrieb Fabio Valentini: On Sun, Feb 6, 2022 at 10:34 PM Marius Schwarz wrote: Hi, deinstalling the rpmfusion package "pulseaudio-module-bluetooth-freeworld", which should not be required by anything: [root@fedorapine ~]# rpm -q --whatrequires pulseaudio-module-bluetooth-freeworld Kein Paket benötigt pulseaudio-module-bluetooth-freeworld (no package needs ... ) Looks like you fell into the trap of not considering "virtual provides". The rpm query you pasted above only queries for exact matches, but not for dependencies on virtual provides provided by the package of the same name. Yes, that may cause the missing output in rpm, but it wasn't the point of my post: Why can a rpmfusion rpm be so deep "chained" into the tree, that it removes i.e. gnome-shell, a major package from Fedora repo, which does not have even heared about that subpackage in rpmfusion. if the "pulseaudio-module-bluetooth-freeworld" package has been installed independently from all those (in the erase tree) additional considered packages, why can it trigger such a cascade? It is simply not important enough to cause this. If it never had been installed, the functionality of all those apps would not change. I want to understand, why this could happen. What caused this big cascade, if we add some unimportant part, noone needs to operate correctly?!? I hope, i made myself clear this time ;) Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote: > Marc-André Lureau wrote: > > Fwiw, given that the primary use case for a cross-toolchain is for > > developer needs, I think it is reasonable to have only UCRT target in the > > future. > > > > Projects releasing for Windows should probably natively build and test > > their releases with Msys2, and they can do so for msvcrt targets. > > Well, with cross-MinGW and cross-NSIS, I can package software for Windows > without ever touching a Windows machine. I have done so more than once > already. I do not even have a Windows installation on which I can run Msys2. Exactly, this is the precise reason why a group of us started the Fedora mingw packaging effort all those years ago. I have a Windows machine for testing / debugging on, but it is so much simpler if we can do cross builds from Linux, as it means we don't have to switch context between machines when developing. I rather wish we had full cross build facilities for all Fedora arches in fact. As well as for Mingw, upstream we cross build libvirt / QEMU for all non-x86 arches too by simplying having a set of containers populated with all the relevant cross compilers and foreign libraries. While we can use Fedora for our Mingw cross targets, we have to use Debian for all the Linux non-x86 targets. It is very compelling to be able to just run things like make docker-build@debian-ppc64el-cross make docker-build@fedora-win32-cross giving throwaway container buildroots, instead of having to deal with full VM installs. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2037669] Please branch and build perl-Crypt-CBC for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2037669 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-0cc4391af4 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0cc4391af4 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2037669 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2037672] Please branch and build perl-Crypt-Blowfish for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2037672 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-0cc4391af4 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0cc4391af4 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2037672 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Non-responsive packagers: lef, msehnout, shaneallcroft
Good Morning Everyone, The packagers listed here have been receiving a daily email asking them to either adjust their bugzilla or their FAS account so the email address in FAS matches an existing bugzilla account. Having a bugzilla account is mandatory per: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account - msehnout contacted since December 15th msehnout is watching rpms/bind msehnout is watching rpms/bind99 msehnout is maintainer of rpms/ipcalc msehnout is watching rpms/libpcap msehnout is maintainer of rpms/osbuild msehnout is maintainer of rpms/osbuild-composer msehnout is watching rpms/pure-ftpd msehnout is watching rpms/tcpdump msehnout is watching rpms/vsftpd msehnout is watching rpms/wireshark (I will be opening a FESCo ticket for msehnout right now as this is the second email sent to the devel list) - shaneallcroft contacted since January 28th shaneallcroft is main admin of rpms/pyplane shaneallcroft has a bugzilla override on rpms/pyplane - lef contacted since January 22nd (lef's package list is quite large, so I'm putting it at the very end of this email) Does anyone know how to contact them? Thanks, Pierre lef is maintainer of rpms/HikariCP lef has a bugzilla override on rpms/HikariCP lef is maintainer of rpms/PyXB lef has a bugzilla override on rpms/PyXB lef is maintainer of rpms/aesh lef has a bugzilla override on rpms/aesh lef is maintainer of rpms/airline lef has a bugzilla override on rpms/airline lef is maintainer of rpms/antlr-maven-plugin lef has a bugzilla override on rpms/antlr-maven-plugin lef is maintainer of rpms/antlr3 lef is maintainer of rpms/antlr4 lef has a bugzilla override on rpms/antlr4 lef is watching rpms/apache-commons-csv lef has a bugzilla override on rpms/apache-commons-csv lef is maintainer of rpms/apache-james-project lef has a bugzilla override on rpms/apache-james-project lef is watching rpms/apache-mime4j lef has a bugzilla override on rpms/apache-mime4j lef is maintainer of rpms/apache-poi lef has a bugzilla override on rpms/apache-poi lef is maintainer of rpms/apiviz lef has a bugzilla override on rpms/apiviz lef is maintainer of rpms/aries-blueprint-annotation-api lef has a bugzilla override on rpms/aries-blueprint-annotation-api lef is maintainer of rpms/aries-blueprint-api lef has a bugzilla override on rpms/aries-blueprint-api lef is maintainer of rpms/aries-blueprint-core lef has a bugzilla override on rpms/aries-blueprint-core lef is maintainer of rpms/aries-blueprint-parser lef has a bugzilla override on rpms/aries-blueprint-parser lef is maintainer of rpms/aries-proxy-api lef has a bugzilla override on rpms/aries-proxy-api lef is maintainer of rpms/aries-proxy-impl lef has a bugzilla override on rpms/aries-proxy-impl lef is maintainer of rpms/aries-quiesce-api lef has a bugzilla override on rpms/aries-quiesce-api lef is maintainer of rpms/aries-util lef has a bugzilla override on rpms/aries-util lef is maintainer of rpms/arquillian-core lef has a bugzilla override on rpms/arquillian-core lef is maintainer of rpms/artemis lef has a bugzilla override on rpms/artemis lef is maintainer of rpms/artemis-wildfly-integration lef has a bugzilla override on rpms/artemis-wildfly-integration lef is maintainer of rpms/atool lef has a bugzilla override on rpms/atool lef is watching rpms/auto lef has a bugzilla override on rpms/auto lef is maintainer of rpms/avro lef has a bugzilla override on rpms/avro lef is watching rpms/bean-validation-api lef has a bugzilla override on rpms/bean-validation-api lef is maintainer of rpms/bytelist lef has a bugzilla override on rpms/bytelist lef is watching rpms/c3p0 lef is maintainer of rpms/castor lef has a bugzilla override on rpms/castor lef is maintainer of rpms/checkstyle lef is maintainer of rpms/classmate lef has a bugzilla override on rpms/classmate lef is maintainer of rpms/cli-parser lef has a bugzilla override on rpms/cli-parser lef is maintainer of rpms/conakry-fonts lef has a bugzilla override on rpms/conakry-fonts lef is maintainer of rpms/cookcc lef has a bugzilla override on rpms/cookcc lef is maintainer of rpms/cryptacular lef has a bugzilla override on rpms/cryptacular lef is watching rpms/crypto-policies lef is maintainer of rpms/cxf lef has a bugzilla override on rpms/cxf lef is maintainer of rpms/cxf-build-utils lef has a bugzilla override on rpms/cxf-build-utils lef is maintainer of rpms/cxf-xjc-utils lef has a bugzilla override on rpms/cxf-xjc-utils lef is maintainer of rpms/deltaspike lef has a bugzilla override on rpms/deltaspike lef is watching rpms/derby lef has a bugzilla override on rpms/derby lef is watching rpms/disruptor lef is maintainer of rpms/easymock3 lef has a bugzilla override on rpms/easymock3 lef is maintainer of rpms/eclipse lef is maintainer of rpms/eclipse-filesystem lef has a bugzilla override on rpms/eclipse-filesystem lef is maintainer of rpms/eclipselink lef has a bugzilla override on rpms/eclipselink lef is maintainer of
[Bug 2051427] Please branch and build perl-Hash-Flatten for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051427 Paul Howarth changed: What|Removed |Added Blocks||2032430 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2032430 [Bug 2032430] perl-Type-Tiny for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051427 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2032430] perl-Type-Tiny for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032430 Paul Howarth changed: What|Removed |Added Depends On||2051427 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051427 [Bug 2051427] Please branch and build perl-Hash-Flatten for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032430 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051426] Please branch and build perl-Test-Assertions for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051426 Paul Howarth changed: What|Removed |Added Blocks||2051427 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051427 [Bug 2051427] Please branch and build perl-Hash-Flatten for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051426 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051427] Please branch and build perl-Hash-Flatten for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051427 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Depends On||2051424, 2051426 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051424 [Bug 2051424] Please branch and build perl-Log-Trace for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2051426 [Bug 2051426] Please branch and build perl-Test-Assertions for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051427 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051424] Please branch and build perl-Log-Trace for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051424 Paul Howarth changed: What|Removed |Added Blocks||2051427 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051427 [Bug 2051427] Please branch and build perl-Hash-Flatten for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051424 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051427] New: Please branch and build perl-Hash-Flatten for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051427 Bug ID: 2051427 Summary: Please branch and build perl-Hash-Flatten for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Hash-Flatten Assignee: jples...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Could you please branch and build perl-Hash-Flatten for EPEL 9 ? If you like you could add me (FAS: pghmcfc) as a committer to the package and I'll do it myself. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051427 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051424] Please branch and build perl-Log-Trace for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051424 Paul Howarth changed: What|Removed |Added Blocks||2051426 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051426 [Bug 2051426] Please branch and build perl-Test-Assertions for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051424 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051426] Please branch and build perl-Test-Assertions for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051426 Paul Howarth changed: What|Removed |Added Depends On||2051424 Doc Type|--- |If docs needed, set a value Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051424 [Bug 2051424] Please branch and build perl-Log-Trace for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051426 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051426] New: Please branch and build perl-Test-Assertions for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051426 Bug ID: 2051426 Summary: Please branch and build perl-Test-Assertions for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Test-Assertions Assignee: jples...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Could you please branch and build perl-Test-Assertions for EPEL 9 ? If you like you could add me (FAS: pghmcfc) as a committer to the package and I'll do it myself. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051426 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051422] Please branch and build perl-Data-Serializer for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051422 Paul Howarth changed: What|Removed |Added Blocks||2051424 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051424 [Bug 2051424] Please branch and build perl-Log-Trace for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051422 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051424] Please branch and build perl-Log-Trace for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051424 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Depends On||2051422 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2051422 [Bug 2051422] Please branch and build perl-Data-Serializer for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051424 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051424] New: Please branch and build perl-Log-Trace for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051424 Bug ID: 2051424 Summary: Please branch and build perl-Log-Trace for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Log-Trace Assignee: jples...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Could you please branch and build perl-Log-Trace for EPEL 9 ? If you like you could add me (FAS: pghmcfc) as a committer to the package and I'll do it myself. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051424 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
