Python 2 exodus is happening now
Dear maintainers, here is an updated list of packages that (transitively, at build or run time) require Python 2 and have not yet requested a FESCo exception to do so. Packages with open exception requests have been excluded for now to be able to finish the conversation with FESCo. If you were bcced on this e-mail, it affects one or more of your packages. We are removing the packages from rawhide **now**. We won't take any mass actions before the weekend, but maintainers of the mentioned packages are free to retire their packages or drop Python 2 subpackages on rawhide. If your Python 2 package is not listed it means that there is an exception request open for it. Even if you were not informed by the person who requested it, we encourage you to delay the removal before the exception is finalized. When in doubt, ask me. If you talked to us (on e-mail or Bugzilla) and think your package is fine as it is, but you don't have a FESCo exception (or a request for one), then there was a misunderstanding. We're sorry for our side of it. Please request a FESCo exception for your package now. Note: Packages that BuildRequire python27, and have no other Python 2 dependencies, have a blanket exception for Fedora 32: https://pagure.io/fesco/issue/2250 They aren't listed below. ## What exactly is happening? The formal change proposal is here: https://fedoraproject.org/wiki/Changes/RetirePython2 Packages requiring Python 2 will be removed starting November 15 (that is today) (unless they have an exception). Components with all essential subpackages removed will be retired. The removal will be (semi-)automated. Source packages only BuildRequiring removed packages will fail to build, and will be removed according to the regular FTBFS policy. https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ ## Three lists There are three lists. 1. Breakdown by maintainers 2. Packages to retire 3. Subpackages to drop ### Breakdown by maintainers Here is the package breakdown sorted by maintainers. The list contains the shortest dependency path to Python 2. The arrow means "depends on". Orphaned Python 2 packages aren't listed. The data is based on current Koji build repo to be as up to date as possible. If you find a bogus dependency, such as a dependency that can be resolved in a non-Python 2 way, please let us know ASAP before we remove the package or even after we do so, so we can restore it. aarem pdf-stapler (→ PY2) python2-staplelib (→ PY2) python-PyPDF2 python2-PyPDF2 (→ PY2) python2-more-itertools (→ PY2) abbot protobuf python2-protobuf (→ PY2) abompard python-mako python2-mako (→ PY2) python-pysocks python2-pysocks (→ PY2) python-urllib3 python2-urllib3 (→ PY2) alsadi dumb-init (BuildRequires: python2-mock → PY2) amluto python-musicbrainzngs python2-musicbrainzngs (→ PY2) apevec pyparsing python2-pyparsing (→ PY2) python-distutils-extra python2-distutils-extra (→ PY2) python-pbr python2-pbr (→ PY2) python-prettytable python2-prettytable (→ PY2) aviso python-configparser python2-configparser (→ PY2) python-scandir python2-scandir (→ PY2) beckerde miniupnpc python2-miniupnpc (→ PY2) bowlofeggs python-mako python2-mako (→ PY2) python-pycodestyle python2-pycodestyle (→ PY2) rocket-depot (→ PY2) brouhaha python-attrs python2-attrs (→ PY2) python-enum34 python2-enum34 (→ PY2) bsjones python-poppler-qt4 (BuildRequires: PyQt4-devel → PyQt4 → PY2) carlwgeorge python-subprocess32 python2-subprocess32 (→ PY2) cheese freeorion (→ PY2) churchyard python-pygments python2-pygments (→ PY2) python2-more-itertools (→ PY2) python2-pluggy (→ PY2) python2-pytest (→ PY2) cicku exaile (→ PY2) python-mutagen python2-mutagen (→ PY2) clalance python-prettytable python2-prettytable (→ PY2) corsepiu k3d (→ PY2) k3d-devel (→ k3d → PY2) cstratak python-setuptools_scm python2-setuptools_scm (→ PY2) ctria configsnap (→ PY2) cverna python-mako python2-mako (→ PY2) dang nfs-ganesha (BuildRequires: python2-qt5-devel → python2-sip-devel → PY2) deji exaile (→ PY2) mpich python2-mpich (→ PY2) openmpi python2-openmpi (→ PY2) denisarnaud boost boost-mpich-python2 (→ PY2) boost-mpich-python2-devel (→ boost-mpich-python2 → PY2) boost-numpy2 (→ PY2) boost-openmpi-python2 (→ PY2) boost-openmpi-python2-devel (→ boost-openmpi-python2 → PY2) boost-python2 (→ PY2) boost-python2-devel (→ boost-python2 → PY2) devos nfs-ganesha (BuildRequires: python2-qt5-devel → python2-sip-devel → PY2) dledford openmpi python2-openmpi (→ PY2) dmalcolm squeal (→ PY2) dwrobel dxf2gcode (BuildRequires: python2-qt5-base → PY2) ersin ddiskit (→ PY2) fab captcp (→ PY2) python-distutils-extra python2-distutils-extra
[Bug 1772789] New: Upgrade perl-Type-Tiny to 1.006000
https://bugzilla.redhat.com/show_bug.cgi?id=1772789 Bug ID: 1772789 Summary: Upgrade perl-Type-Tiny to 1.006000 Product: Fedora Version: rawhide Status: NEW Component: perl-Type-Tiny Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.004004 version. Upstream released 1.006000. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772787] New: Upgrade perl-Mail-DKIM to 0.58
https://bugzilla.redhat.com/show_bug.cgi?id=1772787 Bug ID: 1772787 Summary: Upgrade perl-Mail-DKIM to 0.58 Product: Fedora Version: rawhide Status: NEW Component: perl-Mail-DKIM Assignee: emman...@seyman.fr Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, ky...@kylev.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.57 version. Upstream released 0.58. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772785] New: Upgrade perl-Devel-CheckLib to 1.14
https://bugzilla.redhat.com/show_bug.cgi?id=1772785 Bug ID: 1772785 Summary: Upgrade perl-Devel-CheckLib to 1.14 Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-CheckLib Assignee: de...@fateyev.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.13 version. Upstream released 1.14. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772783] New: Upgrade perl-Crypt-X509 to 0.52
https://bugzilla.redhat.com/show_bug.cgi?id=1772783 Bug ID: 1772783 Summary: Upgrade perl-Crypt-X509 to 0.52 Product: Fedora Version: rawhide Status: NEW Component: perl-Crypt-X509 Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.51 version. Upstream released 0.52. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1771119] perl-Excel-Writer-XLSX-1.02 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1771119 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Excel-Writer-XLSX-1.02 ||-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2019-11-15 07:38:23 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762233] [RFE] Please build for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762233 Johan Cwiklinski changed: What|Removed |Added CC||jo...@x-tnd.be --- Comment #3 from Johan Cwiklinski --- Hi, I'm co-maintainer with Marianne on the fusioninventory-agent package; which depends on this package to work on EL8. Paul, I guess she's currently not available, could you (or one of the other maintainers) please do the build? Thank you very much! :) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1768068] perl-perlfaq-5.20191102 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1768068 --- Comment #16 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1763924] perl-Sys-Syslog-0.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1763924 --- Comment #9 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1763515] perl-Module-CoreList-5.20191020 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1763515 --- Comment #15 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1765091] perl-Scalar-List-Utils-1.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1765091 --- Comment #11 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762085] perl-Term-Table-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1762085 --- Comment #15 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1770716] Upgrade perl-Module-CoreList to 5.20191110
https://bugzilla.redhat.com/show_bug.cgi?id=1770716 --- Comment #13 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1770717] Upgrade perl-Module-Load-Conditional to 0.70
https://bugzilla.redhat.com/show_bug.cgi?id=1770717 --- Comment #14 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #16 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1758970] perl-Archive-Zip-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1758970 --- Comment #9 from Fedora Update System --- perl-5.30-3020191114081842.bba63816 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cbc1010f1b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #15 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1763924] perl-Sys-Syslog-0.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1763924 --- Comment #8 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1768068] perl-perlfaq-5.20191102 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1768068 --- Comment #15 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1758970] perl-Archive-Zip-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1758970 --- Comment #8 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1770716] Upgrade perl-Module-CoreList to 5.20191110
https://bugzilla.redhat.com/show_bug.cgi?id=1770716 --- Comment #12 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762085] perl-Term-Table-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1762085 --- Comment #14 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1770717] Upgrade perl-Module-Load-Conditional to 0.70
https://bugzilla.redhat.com/show_bug.cgi?id=1770717 --- Comment #13 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1765091] perl-Scalar-List-Utils-1.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1765091 --- Comment #10 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1763515] perl-Module-CoreList-5.20191020 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1763515 --- Comment #14 from Fedora Update System --- perl-5.30-2920191114081842.fafb7136 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2fc4b7cd4f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1744785] (RFE) EPEL8 branch of perl-Proc-Daemon
https://bugzilla.redhat.com/show_bug.cgi?id=1744785 --- Comment #4 from Johan Cwiklinski --- Please test and give karma ;) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772558] perl-Devel-PatchPerl-1.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772558 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Devel-PatchPerl-1.78-1 ||.fc32 Resolution|--- |RAWHIDE Last Closed||2019-11-15 07:09:25 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772725] perl-HTTP-Date-6.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772725 --- Comment #4 from Fedora Update System --- FEDORA-2019-8ecd333c9d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8ecd333c9d -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772056] perl-HTTP-Date-6.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772056 Fedora Update System changed: What|Removed |Added Status|ON_QA |MODIFIED --- Comment #9 from Fedora Update System --- FEDORA-2019-8ecd333c9d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8ecd333c9d -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772725] perl-HTTP-Date-6.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772725 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-HTTP-Date-6.04-1.fc32 --- Comment #3 from Petr Pisar --- An enhancement release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772725] perl-HTTP-Date-6.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772725 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772056] perl-HTTP-Date-6.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772056 --- Comment #8 from Fedora Update System --- perl-HTTP-Date-6.03-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-283236fda2 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1764822] [RFE] EPEL-8 branch for perl-Test-Refcount
https://bugzilla.redhat.com/show_bug.cgi?id=1764822 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Test-Refcount-0.10-3.e ||l8 Resolution|--- |ERRATA Last Closed||2019-11-15 05:52:15 --- Comment #6 from Fedora Update System --- perl-Test-Refcount-0.10-3.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1764823] [RFE] EPEL-8 branch for perl-Test-Trap
https://bugzilla.redhat.com/show_bug.cgi?id=1764823 Bug 1764823 depends on bug 1764822, which changed state. Bug 1764822 Summary: [RFE] EPEL-8 branch for perl-Test-Refcount https://bugzilla.redhat.com/show_bug.cgi?id=1764822 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761852] perl-Email-Sender for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761852 Bug 1761852 depends on bug 1762254, which changed state. Bug 1762254 Summary: perl-MooX-Types-MooseLike for EL8 https://bugzilla.redhat.com/show_bug.cgi?id=1762254 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762449] perl-Type-Tiny for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762449 Bug 1762449 depends on bug 1765271, which changed state. Bug 1765271 Summary: [RFE] EPEL-8 branch for perl-Object-Accessor https://bugzilla.redhat.com/show_bug.cgi?id=1765271 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1766727] Please package perl-URL-Encode-XS for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=1766727 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-URL-Encode-XS-0.03-17. ||el8 Resolution|--- |ERRATA Last Closed||2019-11-15 05:52:08 --- Comment #4 from Fedora Update System --- perl-URL-Encode-XS-0.03-17.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762254] perl-MooX-Types-MooseLike for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762254 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-MooX-Types-MooseLike-0 ||.29-13.el8 Resolution|--- |ERRATA Last Closed||2019-11-15 05:52:12 --- Comment #5 from Fedora Update System --- perl-MooX-HandlesVia-0.001008-16.el8, perl-MooX-Types-MooseLike-0.29-13.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1770716] Upgrade perl-Module-CoreList to 5.20191110
https://bugzilla.redhat.com/show_bug.cgi?id=1770716 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #11 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1763515] perl-Module-CoreList-5.20191020 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1763515 --- Comment #13 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1765091] perl-Scalar-List-Utils-1.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1765091 --- Comment #9 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1758970] perl-Archive-Zip-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1758970 --- Comment #7 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #14 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1768068] perl-perlfaq-5.20191102 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1768068 --- Comment #14 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762085] perl-Term-Table-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1762085 --- Comment #13 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1763924] perl-Sys-Syslog-0.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1763924 --- Comment #7 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1770717] Upgrade perl-Module-Load-Conditional to 0.70
https://bugzilla.redhat.com/show_bug.cgi?id=1770717 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #12 from Fedora Update System --- perl-5.30-3120191114081842.a9ea5770 has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-25d3b174b6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1771707] [RFE] EPEL8 branch of perl-HTTP-Server-Simple-PSGI
https://bugzilla.redhat.com/show_bug.cgi?id=1771707 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- perl-HTTP-Server-Simple-0.52-10.el8, perl-HTTP-Server-Simple-PSGI-0.16-15.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0e8e96d963 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1771711] [RFE] EPEL8 branch of perl-LWP-Protocol-http10
https://bugzilla.redhat.com/show_bug.cgi?id=1771711 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-LWP-Protocol-http10-6.03-21.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9edac849d6 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1771717] [RFE] EPEL8 branch of perl-WWW-Form-UrlEncoded
https://bugzilla.redhat.com/show_bug.cgi?id=1771717 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-WWW-Form-UrlEncoded-0.26-3.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5b9b2f8f8d -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772395] perl-MooX-late for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1772395 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-MooX-0.101-19.el8, perl-MooX-late-0.015-19.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-75622791e3 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1771702] [RFE] EPEL8 branch of perl-Cookie-Baker
https://bugzilla.redhat.com/show_bug.cgi?id=1771702 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Cookie-Baker-0.11-2.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-976dfc9f6c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772356] perl-GnuPG-Interface EPEL 8 package
https://bugzilla.redhat.com/show_bug.cgi?id=1772356 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-GnuPG-Interface-0.52-14.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d82b2822df -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1771703] [RFE] EPEL8 branch of perl-Devel-StackTrace-AsHTML
https://bugzilla.redhat.com/show_bug.cgi?id=1771703 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Devel-StackTrace-AsHTML-0.15-9.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-22555352c4 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1771715] [RFE] EPEL8 branch of perl-Stream-Buffered
https://bugzilla.redhat.com/show_bug.cgi?id=1771715 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #7 from Fedora Update System --- perl-Stream-Buffered-0.03-14.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-cadfa198ac -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772056] perl-HTTP-Date-6.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772056 --- Comment #7 from Fedora Update System --- perl-HTTP-Date-6.03-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0c3fe87583 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772056] perl-HTTP-Date-6.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772056 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System --- perl-HTTP-Date-6.03-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1aa29fc047 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1763473] ack-3.2.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1763473 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||ack-3.2.0-1.fc31 Resolution|--- |ERRATA Last Closed||2019-11-15 03:01:19 --- Comment #8 from Fedora Update System --- ack-3.2.0-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
Stephen Gallagher wrote: > I really feel like we are approaching the finish line and shouldn’t give > up just yet! Unfortunately, the feeling that I get is that what looks like a finish line to you is actually the edge of a deep cliff. ;-) To explain my metaphore: I think the biggest trouble and chaos has yet to come and is unavoidable with the way Modularity works, unless we put some very strong policy restrictions on it (which you are not going to like). E.g., I fear that desktop Fedora may end up splittered into a KDE/Plasma module, a GNOME module, an Xfce module, etc. all shipping different versions of some shared (freedesktop.org etc.) libraries, and that all desktop applications would end up depending on one of those modules and no longer being installable for users of any other desktop. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
Stephen Gallagher wrote: > You're assuming that parallel-install is a thing that everyone needs > from every package on their system. Our research and surveys > determined that this was not in fact the case for the overwhelming > majority of real-world deployments. Most[1] deployments function with > a "one app per VM/container" mentality. In such cases, > parallel-installability is at best unnecessary and (such as with SCLs) > actively annoying to them. Modules offers the availability of multiple > streams of software like SCLs does, but it sacrifices the ability to > install them in parallel for the ability to install them in the > standard locations on disk so that other software doesn't need to > adapt to alternate locations (the number-one complaint received about > SCLs). > > [1] Yes, I realize that "most" may not include you. Every environment > is unique, but we have to try and optimize our efforts for the largest > set of consumers possible. We reasoned that containers were a > sufficient workaround for the cases not following the "one app per > VM/container" approach. That may be true for RHEL, but I do not see how that would be the case in Fedora (or even CentOS), at all. It is also a very server-centric view: I do not know any desktop user working that way. I would really like to know where your data comes from exactly, whom you surveyed, and how you counted the deployments. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
Stephen Gallagher wrote:
> On Wed, Nov 13, 2019 at 5:29 PM Kevin Kofler
> wrote:
>> What about libgit2, was that not a default stream?
>
> It was not. It was a dependency of other modules.
So it looks like we really also (in addition to the proposed ban on default
streams) need a ban on non-leaf modules. It would also fix the version
conflict issue.
You have stated yourself: "If you have a library that can be installed in
parallel, make a compat package. Modularity is not the correct solution for
that case". And any library can be installed with parallel given sufficient
packaging skills.
>> And what we are missing here is a list of modular packages with no
>> default version at all (i.e., neither an ursine build nor a default
>> stream), a state which is completely broken (but which seems to currently
>> exist in Fedora, unfortunately).
>
> Could you define "broken"? Because I have no idea what you're talking
> about here. If it is module-only and has no default stream, it means
> it's effectively invisible unless you enable a stream knowingly.
That is exactly what I mean by "broken": The packages are not discoverable
unless you enable some module first, and they are not installable without
opting in to the potential replacement of arbitrary system libraries (or
"frameworks") (e.g., Django getting downgraded by the ReviewBoard module),
which may or may not actually be possible without conflicts on the specific
installation.
I should be able to just dnf install the packages that I want (or
point them in Dnfdragora) and get some version (which may or
may not be the latest) that works with the distribution libraries (which
also may or may not be the latest). If the application does not work with
the default version of the library, if no version of the application that
works with it is available, and if the application cannot be patched to port
it to the system version of the library, a compatibility version of the
library is needed. This also holds for programming language interpreters
(such as Node.js), sets of libraries (such as the Node.js packages), or
"frameworks" (such as Django, which are really just one of the preceding or
a combination thereof). I consider it the whole point of a distribution to
package the software in such a way. If I get to deal myself with
incompatible version requirements, I may just as well install the
applications directly from upstream.
>> (Please note that I also read those 2 points as implicitly banning
>> filtering packages from modules, but if that is not obvious to someone,
>> then it should be added as a separate rule.)
>
> It does not implicitly ban filtering packages. It implicitly bans
> filtering out *sub*-packages. It still think it's acceptable to filter
> out *all* produced subpackages of a component that is used only at
> build-time.
I do not see how that makes a difference, considering that banning some or
all subpackages behaves exactly the same way. In both cases, the filter will
interfere with versions of that component packaged elsewhere (see the
complaints about the filters in RHEL). In both cases, you are deliberately
hiding a component that you packaged from users and making it hard to
obtain. In both cases, you are hindering cooperation and risk introducing
conflicts (when other maintainers will do the logical thing and repackage
that component elsewhere because you won't let them use the version you
packaged).
And both violate the rules I am proposing ("1. any package that exists in a
module MUST have a default version and 2. that version MUST be packaged in
the ursine/non-modular repository, not as a default stream") in exactly the
same way (because those subpackages or entire packages definitely do EXIST
in a module, even if you are hiding them).
> This is literally the entire point of a distribution. We provide an
> opinionated collection of software packaged for people to use.
I think the point of the collection of software packaged in a distribution
is not to be opinionated, but to be consistent and interoperable. That it
sometimes ends up being opinionated is an unfortunate side effect (mostly
caused by upstreams refusing to listen to user requests, forcing the
distribution maintainer to make a decision on which side to irritate). It
should NOT be the goal. Being consistent and interoperable should. And that
is exactly what Modularity is endangering.
The remainder of your message (your last 3 paragraphs) has been answered
quite well by John M. Harris, Jr. already, so I am not going to repeat the
same thing.
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:
Re: What are the benefits of default modular streams over non-modular packages?
On 11/14/19 7:56 AM, Miro Hrončok wrote: **What are the benefits of default modular streams over non-modular packages?** I think Adam Williamson tried to answer that in a message in the thread "Re: Modularity and the system-upgrade path" (link below) when he wrote: "if you just don't modularize FreeIPA ... we're stuck shipping this one version of FreeIPA for the next seventy jillion years" I didn't really understand that, but maybe he'll clarify (possibly again) in this thread. I think I don't understand what he meant because I'm not clear on what he meant to imply would happen when the default module changes. Perhaps the idea is that nothing happens. The packages in that module just stop getting updates and it's up to the end user to enable a new module and migrate their data. That could, conceivably, be seen as better than rebasing the packages on a new version that requires a data migration that can't reliably be done automatically. That's speculation on my part, however, and it's inconsistent with the behavior that Stephen described in the first message in that thread, which was "When running `dnf update` or `dnf system-upgrade`, if the default stream for a module installed on the system changes and the module's current state is `default_enabled`, then the transaction should cause the new default stream to be enabled." And I'm not sure how that's different or better than simply rebasing, as RHEL sometimes does. Anyway, among the messages I've read in the earlier threads, Adam's came closest to answering this question, so I hope he'll weigh in again. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7BITVJLX23OBZDTJUAJZAG43FQKSLZ4A/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On Thu, Nov 14, 2019 at 8:19 PM Kevin Kofler wrote: > > Stephen Gallagher wrote: > > Modular packages without defaults makes sense if they have > > dependencies on a non-default stream. For example: ReviewBoard depends > > on the Django:1.6 stream because of complicated upstream reasons. I > > have to choose between "modular without a default stream" or "not > > available on Fedora", because we have agreed on a prohibition on > > default streams with dependencies on non-default streams. > > The right fix would be to package Django 1.6 as a parallel-installable > compatibility package instead. I don't see why I cannot install ReviewBoard > together with another Django web app on the same web server (without > containers/VMs). (Admittedly a hypothetical example because I am running > neither ReviewBoard nor another Django app on a server I maintain. I also do > not run Fedora on a server. But if I were faced with this issue as a server > administrator, I would curse loudly at Fedora and switch the server to a > distribution that does not get in my way that way.) > The only really reasonable ways to do that would be to support a mechanism to package virtualenvs or do mutations to vendor it with the app. Either way is uglier than the modules mechanism. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python 2 exodus is happening now
On Thu, 2019-11-14 at 18:20 -0700, John M. Harris Jr wrote: > On Thursday, November 14, 2019 6:07:57 PM MST John M. Harris Jr > wrote: > > There are a *lot* of useful, working Python 2 packages here. The > > future of > > Fedora will certainly be interesting. > > Looking through this list, it's really a shame that so many good, > working > packages are being removed without any real cause. python2 still > works, not > everything will be "upgraded" to python 3. For example, freeorion > still works, > and asterisk certainly still works as well. I totally agree, the simplest solution is someone ask for an Python2 exception, IIUC. Because maintainers and co-maintainers doesn't had time to do that . > -- > John M. Harris, Jr. > Splentity > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1772725] perl-HTTP-Date-6.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772725 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring@fedoraproject.org's scratch build of perl-HTTP-Date-6.04-1.fc29.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=39005420 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On 15. 11. 19 2:18, Kevin Kofler wrote: Stephen Gallagher wrote: Modular packages without defaults makes sense if they have dependencies on a non-default stream. For example: ReviewBoard depends on the Django:1.6 stream because of complicated upstream reasons. I have to choose between "modular without a default stream" or "not available on Fedora", because we have agreed on a prohibition on default streams with dependencies on non-default streams. The right fix would be to package Django 1.6 as a parallel-installable compatibility package instead. I don't see why I cannot install ReviewBoard together with another Django web app on the same web server (without containers/VMs). (Admittedly a hypothetical example because I am running neither ReviewBoard nor another Django app on a server I maintain. I also do not run Fedora on a server. But if I were faced with this issue as a server administrator, I would curse loudly at Fedora and switch the server to a distribution that does not get in my way that way.) And I would use pip or pipenv to do this. Obviously, people have different workflows and different opinions. However, since neither me or you use ReviewBoard, but it also stays out of our way, why don't we focus on the problem at hand and leave non-default modular streams exist? -- 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
[Bug 1772725] New: perl-HTTP-Date-6.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772725 Bug ID: 1772725 Summary: perl-HTTP-Date-6.04 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-Date Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 6.04 Current version/release in rawhide: 6.03-1.fc32 URL: http://search.cpan.org/dist/HTTP-Date/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/2976/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1772725] perl-HTTP-Date-6.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1772725 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1636342 --> https://bugzilla.redhat.com/attachment.cgi?id=1636342=edit [patch] Update to 6.04 (#1772725) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Python 2 exodus is happening now
On Thursday, November 14, 2019 6:07:57 PM MST John M. Harris Jr wrote: > There are a *lot* of useful, working Python 2 packages here. The future of > Fedora will certainly be interesting. Looking through this list, it's really a shame that so many good, working packages are being removed without any real cause. python2 still works, not everything will be "upgraded" to python 3. For example, freeorion still works, and asterisk certainly still works as well. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
Stephen Gallagher wrote: > Modular packages without defaults makes sense if they have > dependencies on a non-default stream. For example: ReviewBoard depends > on the Django:1.6 stream because of complicated upstream reasons. I > have to choose between "modular without a default stream" or "not > available on Fedora", because we have agreed on a prohibition on > default streams with dependencies on non-default streams. The right fix would be to package Django 1.6 as a parallel-installable compatibility package instead. I don't see why I cannot install ReviewBoard together with another Django web app on the same web server (without containers/VMs). (Admittedly a hypothetical example because I am running neither ReviewBoard nor another Django app on a server I maintain. I also do not run Fedora on a server. But if I were faced with this issue as a server administrator, I would curse loudly at Fedora and switch the server to a distribution that does not get in my way that way.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python 2 exodus is happening now
On 15. 11. 19 2:11, Sérgio Basto wrote: On Fri, 2019-11-15 at 02:02 +0100, Miro Hrončok wrote: python-inotify python2-inotify (→ PY2) python2-inotify-examples (→ PY2) python-qt5 python2-qt5 (→ PY2) python2-qt5-base (→ PY2) python2-qt5-devel (→ python2-sip-devel → PY2) python2-qt5-webkit (→ PY2) python-inotify and python-qt5 have python3 packages , you will remove all , or just python2 part ? Just python2 parts. See the two bottom lists. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python 2 exodus is happening now
On Fri, 2019-11-15 at 02:02 +0100, Miro Hrončok wrote: >python-inotify > python2-inotify (→ PY2) > python2-inotify-examples (→ PY2) > >python-qt5 > python2-qt5 (→ PY2) > python2-qt5-base (→ PY2) > python2-qt5-devel (→ python2-sip-devel → PY2) > python2-qt5-webkit (→ PY2) python-inotify and python-qt5 have python3 packages , you will remove all , or just python2 part ? Best regards, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python 2 exodus is happening now
There are a *lot* of useful, working Python 2 packages here. The future of Fedora will certainly be interesting. -- John M. Harris, Jr. Splentity ___ 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
Python 2 exodus is happening now
Dear maintainers, here is an updated list of packages that (transitively, at build or run time) require Python 2 and have not yet requested a FESCo exception to do so. Packages with open exception requests have been excluded for now to be able to finish the conversation with FESCo. If you were bcced on this e-mail, it affects one or more of your packages. We are removing the packages from rawhide **now**. We won't take any mass actions before the weekend, but maintainers of the mentioned packages are free to retire their packages or drop Python 2 subpackages on rawhide. If your Python 2 package is not listed it means that there is an exception request open for it. Even if you were not informed by the person who requested it, we encourage you to delay the removal before the exception is finalized. When in doubt, ask me. If you talked to us (on e-mail or Bugzilla) and think your package is fine as it is, but you don't have a FESCo exception (or a request for one), then there was a misunderstanding. We're sorry for our side of it. Please request a FESCo exception for your package now. Note: Packages that BuildRequire python27, and have no other Python 2 dependencies, have a blanket exception for Fedora 32: https://pagure.io/fesco/issue/2250 They aren't listed below. ## What exactly is happening? The formal change proposal is here: https://fedoraproject.org/wiki/Changes/RetirePython2 Packages requiring Python 2 will be removed starting November 15 (that is today) (unless they have an exception). Components with all essential subpackages removed will be retired. The removal will be (semi-)automated. Source packages only BuildRequiring removed packages will fail to build, and will be removed according to the regular FTBFS policy. https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ ## Three lists There are three lists. 1. Breakdown by maintainers 2. Packages to retire 3. Subpackages to drop ### Breakdown by maintainers Here is the package breakdown sorted by maintainers. The list contains the shortest dependency path to Python 2. The arrow means "depends on". Orphaned Python 2 packages aren't listed. The data is based on current Koji build repo to be as up to date as possible. If you find a bogus dependency, such as a dependency that can be resolved in a non-Python 2 way, please let us know ASAP before we remove the package or even after we do so, so we can restore it. aarem pdf-stapler (→ PY2) python2-staplelib (→ PY2) python-PyPDF2 python2-PyPDF2 (→ PY2) python2-more-itertools (→ PY2) abbot protobuf python2-protobuf (→ PY2) abompard python-mako python2-mako (→ PY2) python-pysocks python2-pysocks (→ PY2) python-urllib3 python2-urllib3 (→ PY2) alsadi dumb-init (BuildRequires: python2-mock → PY2) amluto python-musicbrainzngs python2-musicbrainzngs (→ PY2) apevec pyparsing python2-pyparsing (→ PY2) python-distutils-extra python2-distutils-extra (→ PY2) python-pbr python2-pbr (→ PY2) python-prettytable python2-prettytable (→ PY2) aviso python-configparser python2-configparser (→ PY2) python-scandir python2-scandir (→ PY2) beckerde miniupnpc python2-miniupnpc (→ PY2) bowlofeggs python-mako python2-mako (→ PY2) python-pycodestyle python2-pycodestyle (→ PY2) rocket-depot (→ PY2) brouhaha python-attrs python2-attrs (→ PY2) python-enum34 python2-enum34 (→ PY2) bsjones python-poppler-qt4 (BuildRequires: PyQt4-devel → PyQt4 → PY2) carlwgeorge python-subprocess32 python2-subprocess32 (→ PY2) cheese freeorion (→ PY2) churchyard python-pygments python2-pygments (→ PY2) python2-more-itertools (→ PY2) python2-pluggy (→ PY2) python2-pytest (→ PY2) cicku exaile (→ PY2) python-mutagen python2-mutagen (→ PY2) clalance python-prettytable python2-prettytable (→ PY2) corsepiu k3d (→ PY2) k3d-devel (→ k3d → PY2) cstratak python-setuptools_scm python2-setuptools_scm (→ PY2) ctria configsnap (→ PY2) cverna python-mako python2-mako (→ PY2) dang nfs-ganesha (BuildRequires: python2-qt5-devel → python2-sip-devel → PY2) deji exaile (→ PY2) mpich python2-mpich (→ PY2) openmpi python2-openmpi (→ PY2) denisarnaud boost boost-mpich-python2 (→ PY2) boost-mpich-python2-devel (→ boost-mpich-python2 → PY2) boost-numpy2 (→ PY2) boost-openmpi-python2 (→ PY2) boost-openmpi-python2-devel (→ boost-openmpi-python2 → PY2) boost-python2 (→ PY2) boost-python2-devel (→ boost-python2 → PY2) devos nfs-ganesha (BuildRequires: python2-qt5-devel → python2-sip-devel → PY2) dledford openmpi python2-openmpi (→ PY2) dmalcolm squeal (→ PY2) dwrobel dxf2gcode (BuildRequires: python2-qt5-base → PY2) ersin ddiskit (→ PY2) fab captcp (→ PY2) python-distutils-extra python2-distutils-extra
Re: Something wrong with kernel-headers on fedora 30?
> kernel-headers is related to the userspace API and is not tied to a > particular kernel version. > If the userspace API doesn't change there's no need to rebuild. Is there a > problem you're > seeing by not having an updated kernel-headers? That does not be it works in all cases. I have Highpoint RSSD 7101A card with 2TB of NVME storage, which I would like to use! With the latest Fedora 30 update (5.3.7) the kernel will not boot because the modprobe can find the driver (rsnvme). Interestingly the two previous kernels (5.1.19 and 5.1.20) have the same complaint but boot anyway. The HighPoint storage is not used for normal Linux OS or /home So what is different with the 5.3.7 kernel So I download latest HighPoint RDDS 7101A driver and run there magic build script. Which fines three kernels: compile:default boot kernel: /boot/vmlinuz-5.3.7-200.fc30.x86_64 dumpkernels:kernel installed kernel-5.1.20-300.fc30.x86_64 kernel-5.1.19-300.fc30.x86_64 kernel-5.3.7-200.fc30.x86_64 And tries to build its driver against each kernel. But that fails because: kernelver: compile:kernel file /boot/vmlinuz-5.3.7-200.fc30.x86_64 version 5.3.7-200.fc30.x86_64 [default boot kernel] installkerndev:install kerneldev 5.3.7-200.fc30.x86_64 installkerndev:install package kernel-core-devel-5.3.7-200.fc30 Error: Unable to find a match: kernel-devel-5.3.7-200.fc30 compile:kernel 5.3.7-200.fc30.x86_64 does not contain kernel headers, active[1]. Ok so I install kernel-devel and get 5.3.11-200.fc30 and install kernel-headers and get 5.3.6-200.fc30 I run the HighPoint driver build again and it fails again because none of the installed kernels have matching headers. And I cant find any way to convince the 5.3.7 kernel not to care about the missing rsnvme driver. And I cant seem to find the matched kernel headers for the kernel fedora desided to install I am stuck here. I really don't want to be forced into a clean reinstall And I really want to be able to use this fast NVME storage. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1759801] please build perl-gtk3 for epel 8
https://bugzilla.redhat.com/show_bug.cgi?id=1759801 --- Comment #1 from Sergio Monteiro Basto --- perl-Gtk3 is a BuildRequired of debconf -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: rpmbuild signature check failure
Björn Persson wrote:
>Baxi wrote:
>> Hi. I am trying to package a program. The upstream provided sha256sum.asc
>> file. Verifying tarball with that signature says, Can't check signature: No
>> public key. I found his public key in key directory by searching his email
>> and added that key. Now gpg says Bad signature from that person. Also
>> upstream didn't provide gpg keyring in his project. What should I do?
>
>Please post URLs to the files so I can see what kind of signatures or
>checksums they actually contain.
As I still haven't seen the files I'm going to post some advice based
on what I read in the guts of this freshly caught bleak.
First you should ask the upstream developer to publish his public key on
his website, and make sure to use HTTPS when you download it. Anyone
can make a key with someone else's email address on it and upload it to
a key server, so you don't know whether the key you found is the right
one.
Once you know that you have the right key, the fish entrails tell me
that you should use sha256sum.asc to verify the file named sha256sum
like this:
%{gpgverify} --keyring=... --signature=sha256sum.asc --data=sha256sum
Then you should use the program sha256sum to verify the tarball against
the checksum in the file sha256sum:
sha256sum --check sha256sum
That should print the filename of the tarball followed by "OK".
Or, when you contact the developer to ask him to publish the key, you
could also ask him to sign the tarball directly instead of going the
detour through sha256sum.
If the bleak is off the mark, then I'm still willing to look at the
actual files instead.
Björn Persson
pgpG0baeR4TdN.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1772356] perl-GnuPG-Interface EPEL 8 package
https://bugzilla.redhat.com/show_bug.cgi?id=1772356 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-d82b2822df has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d82b2822df -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Will orphan packages with NEW F31FTBFS bugs tomorrow
On Monday, 11 November 2019 at 13:53, Miro Hrončok wrote: > On 08. 11. 19 13:16, Miro Hrončok wrote: > > According to the policy for packages that fail to build from source: > > > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > > > > > I plan to orphan packages with NEW Fedora 31 Fail To Build From Source > > bugzillas tomorrow. > > Due to a general "panic" response and the fact that today is a holiday in > the US and in many European countries, the current plan is to do this on > Wednesday. [...] > > The list would now be: [...] > lbzip2 Taking this one as I actually use it: https://pagure.io/releng/issue/9021 Co-maintainers are welcome. I think it could be the default for mock to speed-up some builds. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fatal error: x86intrin.h: No such file or directory
On Thursday, 14 November 2019 at 23:02, Richard Shaw wrote: > The package is building fine in mock but when I try to do a scratch build > I'm getting the following error: > > fatal error: x86intrin.h: No such file or directory > > It seems to be random too, on this attempt x86_64 actually completed but > all other arches failed: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=39000850 > > Something weird going on with koji right now? Does it work in mock on non-x86? x86intrin.h is x86-specific header and won't be present on other arches, but it looks like it's included unconditionally. My guess is upstream never tested on anything else than x86_64. Your build link above shows that it's failing even on i686, although for a different reason (redefined method). Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fatal error: x86intrin.h: No such file or directory
The package is building fine in mock but when I try to do a scratch build I'm getting the following error: fatal error: x86intrin.h: No such file or directory It seems to be random too, on this attempt x86_64 actually completed but all other arches failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=39000850 Something weird going on with koji right now? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On Thu, Nov 14, 2019 at 4:49 PM Miro Hrončok wrote: > On 14. 11. 19 22:30, Stephen Gallagher wrote: > > On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok > wrote: > > > >> Easy is subjective. I don't consider this easy. I consider it seriously > >> overcomplicated. The idea that going modular will somehow help with > current > >> problems in modularity is exactly what happened to eclipse. > > > > No, what happened to Eclipse is that the maintainers of maven and ant > > ran ahead without asking for input, created an environment that caused > > problems for Eclipse and Eclipse got backed into a corner. > > > > As for overcomplicated, I think we can simplify it quite a lot, but I > > think I'm doing a poor job of explaining it over email. Perhaps we > > could do a Google Hangout tomorrow and discuss it real-time? > > Sure thing. Please contact me off-list to discuss when to do this. I'm not > entirely sure it can be tomorrow. I would like to have other Python > maintainers > there, especially those who have been involved in RHEL 8 Python > modularization > and Petr Viktorin (the team-lead) is on vacation tomorrow. > After tomorrow, I’m out of the office for two weeks. So I may see if I can brain-dump to Petr and have him meet with you folks. > >> I'm not going to do this. I guess that after the RHEL 8 experience, > neither are > >> the remaining Python maintainers. > > > > Please defer judgement until we've talked out the whole idea. That's all > I ask. > > I will try to do that, but I'm seriously biased here. I try not to be, but > it's > getting harder with every modularity thread on this list. > I understand. It’s been a rough road and it’s easy to get discouraged. I really feel like we are approaching the finish line and shouldn’t give up just yet! Thank you for keeping an open mind. Your help and feedback has been invaluable. > -- > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On 14. 11. 19 22:30, Stephen Gallagher wrote: On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok wrote: Easy is subjective. I don't consider this easy. I consider it seriously overcomplicated. The idea that going modular will somehow help with current problems in modularity is exactly what happened to eclipse. No, what happened to Eclipse is that the maintainers of maven and ant ran ahead without asking for input, created an environment that caused problems for Eclipse and Eclipse got backed into a corner. As for overcomplicated, I think we can simplify it quite a lot, but I think I'm doing a poor job of explaining it over email. Perhaps we could do a Google Hangout tomorrow and discuss it real-time? Sure thing. Please contact me off-list to discuss when to do this. I'm not entirely sure it can be tomorrow. I would like to have other Python maintainers there, especially those who have been involved in RHEL 8 Python modularization and Petr Viktorin (the team-lead) is on vacation tomorrow. I'm not going to do this. I guess that after the RHEL 8 experience, neither are the remaining Python maintainers. Please defer judgement until we've talked out the whole idea. That's all I ask. I will try to do that, but I'm seriously biased here. I try not to be, but it's getting harder with every modularity thread on this list. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Jenkins upgrade to change from fedmsg to fedora-messaging
Thank you for the clarification, Pierre! I meant to do that yesterday, but I got sidetracked. =) The upgrade went well this morning and all jobs appear to be running smoothly. We will make the change to fedora-messaging sometime next week, most likely on either Monday or Tuesday. Once we've setup a time for it, I'll reply back here with the chosen time. Thanks! -Jim On Thu, Nov 14, 2019 at 2:28 AM Pierre-Yves Chibon wrote: > On Wed, Nov 13, 2019 at 05:34:40PM +, Sérgio Basto wrote: > >BTW , Jenkins was retired from rawhide [1]. > >I tried built Jenkins on rawhide but build failed with a lot of > missing > >packages that are BuildRequires. > >[1] > https://src.fedoraproject.org/rpms/jenkins/c/9e8c8fe1695dbf811e101ef829c51fdf240a02d3?branch=master > > This email was about the jenkins instance running at: > https://jenkins-continuous-infra.apps.ci.centos.org/ which is used for > running > the tests gating package updates. > I believe it's a jenkins instance deployed in openshift and I'm fairly > sure it > does not rely on RPM packages. > > So your email and Jim's are both be correct, they just speak about > different > things. > > Pierre > > >On Wed, 2019-11-13 at 09:17 -0600, Jim Bair wrote: > > > > Hello Fedora CI and Devel Teams! > > The CI team will be performing a Jenkins upgrade and jms-messaging > > plugin upgrade this Thursday to allow us to switch from fedmsg to > > fedora-messaging. While performing this upgrade, dist-git tests > will be > > temporarily unavailable. When things are back to normal, we will > > reply-all here. > > Much like our last maintenance window, the intent is to upgrade the > > software but not actually change from fedmsg to fedora-messaging > just > > yet. If you have any questions or concerns, by all means please > reach > > out. > > Thank you! > > -Jim Bair > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok wrote: > Easy is subjective. I don't consider this easy. I consider it seriously > overcomplicated. The idea that going modular will somehow help with current > problems in modularity is exactly what happened to eclipse. No, what happened to Eclipse is that the maintainers of maven and ant ran ahead without asking for input, created an environment that caused problems for Eclipse and Eclipse got backed into a corner. As for overcomplicated, I think we can simplify it quite a lot, but I think I'm doing a poor job of explaining it over email. Perhaps we could do a Google Hangout tomorrow and discuss it real-time? > I'm not going to do this. I guess that after the RHEL 8 experience, neither > are > the remaining Python maintainers. Please defer judgement until we've talked out the whole idea. That's all I ask. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Thu, Nov 14, 2019 at 2:10 PM Miro Hrončok wrote: > > On 14. 11. 19 19:39, Stephen Gallagher wrote: > > On Thu, Nov 14, 2019 at 12:12 PM Miro Hrončok wrote: > >> > >> On 09. 10. 19 22:46, Ben Cotton wrote: > >>> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot > >>> > >>> Enable module default streams in the buildroot repository for modular > >>> and non-modular RPMs. > >>> > >>> == Summary == > >>> This Change (colloquially referred to as "Ursa Prime") enables the > >>> Koji build-system to include the RPM artifacts provided by module > >>> default streams in the buildroot when building non-modular (or > >>> "traditional") RPMs. > >> > >> I have one more technical concern. > >> > >> Suppose a packager decides to package the "mycoolapp" software as a > >> non-modular > >> package. "mycoolapp" is written in Python, it builds again non-modular > >> Python, > >> currently 3.8, it requires "python(abi) = 3.8" on runtime. > >> > >> The packager decides to use avocado in %check. Avocado comes from a > >> module, it > >> requires "python(abi) = 3.8" as well, because the modular package was > >> built with > >> Python 3.8. Avocado is in the bulidroot, so everything works. > >> > >> The Python maintainers (that includes me) decide to update to Python 3.9 in > >> Fedora 33. They request a side tag to do that. They update the python3 to > >> 3.9 > >> and they mass rebuild all non-modular Python packages in it. "mycoolapp" > >> cannot > >> resolve build dependencies because avocado requires "python(abi) = 3.8". > >> > >> The Python maintainers need to detect this and figure out what happened. > >> Then, the Python maintainers need to either: > >> > >>1. Exclude "mycoolapp" from the rebuild. That is possible until dozens > >> of > >> other packages require "mycoolapp". > >> > >>2. Ask the avocado maintainers to rebuild their module in the side tag > >> and ask > >> releng to add the side-tag-built module into the side-tag buildroot (if it > >> is > >> even possible). > >> > >>3. Modify the spec of "mycoolapp" to temporarily disable %check and > >> loose the > >> avocado dependency. > >> > >> Or is there some other way? > >> > > > > Does Python actually break ABI on minor releases? So a full rebuild is > > required for that case? > > Yes, the full rebuild is needed for various reasons. We've talked about this > on > IRC, but to make this more transparent to others, I will repeat it here. The > main reasons include that "3.8" is in the paths (such as /usr/lib/python3.8) > and > that the bytecode is changed. There are other reasons that may or may not be > relevant to avocade. > > > What we would probably need to do is tag the python39 build into the > > modular buildroot for the appropriate platform and then rebuild > > avocado while that was in the buildroot. > > This would affect all modules that need to be rebuilt before the python39 > side-tag is merged, right? > > If I understand that right, it would also make the avocado module > non-installable for regular rawhide buidlroot before the python39 side tag is > merged. > > One of the purposes that we do this in the side tag is to avoid disrupting > rawhide while we are mid-upgrade. > > > Another option would be to create a `python3` module stream for each > > minor release and make one of them the default stream for the side-tag > > so the non-modular versions could be built against that. > > Modular stream of what module? > > > Then the > > avocado module would set its dependencies to be: > > ``` > > buildrequires: > >platform: [ ] > >python3: [ ] > > ``` > > (Read: build for all streams of python for all available platforms). > > Then whenever the default stream of python3 changes over in Rawhide, > > avocado would follow because it was already built for the next > > version. > > Default stream of python3? python3 is not a module. And even if I wanted it to > be (I don't), it would be a very hard thing to do. > So, what I meant here (as I said in another mail) was actually to create a python3 module with streams for each release version whose purpose is *not* to carry the actual python content. That should stay with the non-modular RPMs. It would instead carry just a (new) python-binaries package that would behave halfway between `alternatives` and a metapackage, in that it would depend on the appropriate non-modular packages and drop symlinks for the correct binary versions into place. Then we could use those module streams as source for doing stream expansion for modules that depend on Python. Then it becomes easy to rebuild things like Avocado, since it will see the new 3.9 stream and add that to the matrix. Am I explaining that well? ___ 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:
Re: Modularity: The Official Complaint Thread
On 14. 11. 19 22:01, Stephen Gallagher wrote: On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok wrote: On 14. 11. 19 21:32, Stephen Gallagher wrote: On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok wrote: On 14. 11. 19 21:15, Stephen Gallagher wrote: Now, python3:3.7 vs. python3:3.8 might be a more interesting question... The way Python is designed, 3.7 and 3.8 is parallel installable by default. The only things that conflict are: - package names, such as python3 or python3-pytest - executable names, such as /usr/bin/python3 or /usr/bin/pytest By having the python3 modules with 3.7 and 3.8 streams, we would kill this feature of Python while gaining a very little benefit (such as that users/admins might select a stream to determine what version /usr/bin/python3 is). Not to mention that dnf itself depends on Python, so we would need to have dnf in those modules, or rewrite dnf in Rust or use mcirodnf or have /usr/libexec/platform-python for dnf. I was actually thinking more along the lines of: leave the actual python packages as non-modular but have a module that acts like the old `alternatives` tool to set up which binaries should own the main executable names. It would allow us to do the thing I proposed earlier around the major upgrade rebuilds (letting us set other modules as `buildrequires:` of `python: [ ]` for stream expansion) without actually having to build the complete python stack in the modules. That might be a really convenient strategy, honestly. Convenient to achieve what exactly? To achieve an easy way to deal with modular rebuilds for new Python 3 versions. Easy is subjective. I don't consider this easy. I consider it seriously overcomplicated. The idea that going modular will somehow help with current problems in modularity is exactly what happened to eclipse. I'm not going to do this. I guess that after the RHEL 8 experience, neither are the remaining Python maintainers. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Sent: Thursday, November 14, 2019 9:32:30 PM > Subject: Re: Modularity: The Official Complaint Thread > > On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok wrote: > > > > On 14. 11. 19 21:15, Stephen Gallagher wrote: > > > Now, python3:3.7 vs. python3:3.8 might be a more interesting question... > > > > The way Python is designed, 3.7 and 3.8 is parallel installable by default. > > > > The only things that conflict are: > > > > - package names, such as python3 or python3-pytest > > - executable names, such as /usr/bin/python3 or /usr/bin/pytest > > > > By having the python3 modules with 3.7 and 3.8 streams, we would kill this > > feature of Python while gaining a very little benefit (such as that > > users/admins > > might select a stream to determine what version /usr/bin/python3 is). > > > > Not to mention that dnf itself depends on Python, so we would need to have > > dnf > > in those modules, or rewrite dnf in Rust or use mcirodnf or have > > /usr/libexec/platform-python for dnf. > > I was actually thinking more along the lines of: leave the actual > python packages as > non-modular but have a module that acts like the old `alternatives` > tool to set up which binaries should own the main executable names. It > would allow us to do the thing I proposed earlier around the major > upgrade rebuilds (letting us set other modules as `buildrequires:` of > `python: [ ]` for stream expansion) without actually having to build > the complete python stack in the modules. That might be a really > convenient strategy, honestly. > ___ > 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 > While that is an interesting approach I really don't see any benefit on doing that (apart from maybe a staging environment to experiment). -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Sent: Thursday, November 14, 2019 9:15:38 PM > Subject: Re: Modularity: The Official Complaint Thread > > On Thu, Nov 14, 2019 at 2:04 PM John M. Harris Jr > wrote: > > > > On Thursday, November 14, 2019 11:45:22 AM MST Stephen Gallagher wrote: > > > You're assuming that parallel-install is a thing that everyone needs > > > from every package on their system. > > > > I'm not. However, if you're going to bring up 'the recommended solution for > > doing "parallel-install" with modules', it makes sense to address this. > > > > > Our research and surveys determined that this was not in fact the case > > > for > > > the overwhelming majority of real-world deployments. Most[1] deployments > > > function with a "one app per VM/container" mentality. > > > > This isn't surprising to me, as that's just an extension of what is done > > with > > physical hosts as well, when serving important services. The physical host > > or > > VM is often dedicated to said service, often at the recommendation of the > > software itself, for example FreeIPA recommends this. > > > > > In such cases, parallel-installability is at best unnecessary and (such > > > as > > > with SCLs) actively annoying to them. > > > > Only if actually implemented as SCLs, in my opinion, but that is definitely > > an > > opinion. > > > > I phrased that wrong. It should have read: "_sometimes_ (such as with SCLs)". > > > > Modules offers the availability of multiple streams of software like SCLs > > > does, but it sacrifices the ability to install them in parallel for the > > > ability to install them in the standard locations on disk so that other > > > software doesn't need to adapt to alternate locations (the number-one > > > complaint received about SCLs). > > > > So, are modules are meant to replace SCLs? If so, surely the inability to > > install multiple versions invalidates that? > > > > They aren't incompatible technologies. If there is a case where > parallel-installability is valuable, an SCL can still be made. But for > the common case, we (Red Hat) determined that parallel-availability > was more valuable and common. > > > For example, one of the issues I'm trying to resolve at work is providing > > both > > Python 2.7 and Python 3.5 on RHEL 6. > > Python 2 and 3 are effectively separate tools and (given that they are > built with parallel-installability in mind) should absolutely not be > streams of the same module. > > Now, python3:3.7 vs. python3:3.8 might be a more interesting question... That is actually a non-issue, they are parallel installable if you exclude the main python3 binary. > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok wrote: > > On 14. 11. 19 21:32, Stephen Gallagher wrote: > > On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok wrote: > >> > >> On 14. 11. 19 21:15, Stephen Gallagher wrote: > >>> Now, python3:3.7 vs. python3:3.8 might be a more interesting question... > >> > >> The way Python is designed, 3.7 and 3.8 is parallel installable by default. > >> > >> The only things that conflict are: > >> > >>- package names, such as python3 or python3-pytest > >>- executable names, such as /usr/bin/python3 or /usr/bin/pytest > >> > >> By having the python3 modules with 3.7 and 3.8 streams, we would kill this > >> feature of Python while gaining a very little benefit (such as that > >> users/admins > >> might select a stream to determine what version /usr/bin/python3 is). > >> > >> Not to mention that dnf itself depends on Python, so we would need to have > >> dnf > >> in those modules, or rewrite dnf in Rust or use mcirodnf or have > >> /usr/libexec/platform-python for dnf. > > > > I was actually thinking more along the lines of: leave the actual > > python packages as > > non-modular but have a module that acts like the old `alternatives` > > tool to set up which binaries should own the main executable names. It > > would allow us to do the thing I proposed earlier around the major > > upgrade rebuilds (letting us set other modules as `buildrequires:` of > > `python: [ ]` for stream expansion) without actually having to build > > the complete python stack in the modules. That might be a really > > convenient strategy, honestly. > > Convenient to achieve what exactly? > To achieve an easy way to deal with modular rebuilds for new Python 3 versions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On 14. 11. 19 21:32, Stephen Gallagher wrote: On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok wrote: On 14. 11. 19 21:15, Stephen Gallagher wrote: Now, python3:3.7 vs. python3:3.8 might be a more interesting question... The way Python is designed, 3.7 and 3.8 is parallel installable by default. The only things that conflict are: - package names, such as python3 or python3-pytest - executable names, such as /usr/bin/python3 or /usr/bin/pytest By having the python3 modules with 3.7 and 3.8 streams, we would kill this feature of Python while gaining a very little benefit (such as that users/admins might select a stream to determine what version /usr/bin/python3 is). Not to mention that dnf itself depends on Python, so we would need to have dnf in those modules, or rewrite dnf in Rust or use mcirodnf or have /usr/libexec/platform-python for dnf. I was actually thinking more along the lines of: leave the actual python packages as non-modular but have a module that acts like the old `alternatives` tool to set up which binaries should own the main executable names. It would allow us to do the thing I proposed earlier around the major upgrade rebuilds (letting us set other modules as `buildrequires:` of `python: [ ]` for stream expansion) without actually having to build the complete python stack in the modules. That might be a really convenient strategy, honestly. Convenient to achieve what exactly? -- 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
[Test-Announce] Proposal to CANCEL: 2019-11-18 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't have any urgent business, but also, I'm going to be off work that day. If you think we do need to have a meeting, you can volunteer to run it - just send out an announcement like the one I normally send, and follow https://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process to run it. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok wrote: > > On 14. 11. 19 21:15, Stephen Gallagher wrote: > > Now, python3:3.7 vs. python3:3.8 might be a more interesting question... > > The way Python is designed, 3.7 and 3.8 is parallel installable by default. > > The only things that conflict are: > > - package names, such as python3 or python3-pytest > - executable names, such as /usr/bin/python3 or /usr/bin/pytest > > By having the python3 modules with 3.7 and 3.8 streams, we would kill this > feature of Python while gaining a very little benefit (such as that > users/admins > might select a stream to determine what version /usr/bin/python3 is). > > Not to mention that dnf itself depends on Python, so we would need to have dnf > in those modules, or rewrite dnf in Rust or use mcirodnf or have > /usr/libexec/platform-python for dnf. I was actually thinking more along the lines of: leave the actual python packages as non-modular but have a module that acts like the old `alternatives` tool to set up which binaries should own the main executable names. It would allow us to do the thing I proposed earlier around the major upgrade rebuilds (letting us set other modules as `buildrequires:` of `python: [ ]` for stream expansion) without actually having to build the complete python stack in the modules. That might be a really convenient strategy, honestly. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On 14. 11. 19 21:15, Stephen Gallagher wrote: Now, python3:3.7 vs. python3:3.8 might be a more interesting question... The way Python is designed, 3.7 and 3.8 is parallel installable by default. The only things that conflict are: - package names, such as python3 or python3-pytest - executable names, such as /usr/bin/python3 or /usr/bin/pytest By having the python3 modules with 3.7 and 3.8 streams, we would kill this feature of Python while gaining a very little benefit (such as that users/admins might select a stream to determine what version /usr/bin/python3 is). Not to mention that dnf itself depends on Python, so we would need to have dnf in those modules, or rewrite dnf in Rust or use mcirodnf or have /usr/libexec/platform-python for dnf. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On Thu, Nov 14, 2019 at 3:17 PM Miro Hrončok wrote: > > On 06. 11. 19 8:29, Miro Hrončok wrote: > > M2. > > > > For traditional packages, it was consistent and easy to find package > > dependencies in Fedora. For a proven packager, Fedora Packaging Committee > > member > > or generally for anybody doing a System Wide Change, being able to run > > queries > > like: > > > > $ repoquery --repo=rawhide --whatrequires 'libpython3.8.so.1.0()(64bit)' > > > > is trivial. Arguably, there are some quirks already (for example it doesn't > > properly work with boolean (rich?) deps). > > > > Witch modules, I still don't remember how to do this, but I know it > > requires > > more than 1 easy repoquery over rawhide. > > This is also currently complicated by the fact that when Fedora N branches, > the > modules are not there on Fedora N+1 until they are rebuilt. > Until they are *successfully* rebuilt, specifically. We do a mass-rebuild for Fedora N+1 when Fedora N branches from Rawhide. If a module (such as scala, right now) fails to build successfully at the Branched mass-rebuild, it doesn't appear in the Rawhide composes. This *should* be a quick way to notice things are not working, but scala has been broken for a while now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On Thu, Nov 14, 2019 at 2:04 PM John M. Harris Jr wrote: > > On Thursday, November 14, 2019 11:45:22 AM MST Stephen Gallagher wrote: > > You're assuming that parallel-install is a thing that everyone needs > > from every package on their system. > > I'm not. However, if you're going to bring up 'the recommended solution for > doing "parallel-install" with modules', it makes sense to address this. > > > Our research and surveys determined that this was not in fact the case for > > the overwhelming majority of real-world deployments. Most[1] deployments > > function with a "one app per VM/container" mentality. > > This isn't surprising to me, as that's just an extension of what is done with > physical hosts as well, when serving important services. The physical host or > VM is often dedicated to said service, often at the recommendation of the > software itself, for example FreeIPA recommends this. > > > In such cases, parallel-installability is at best unnecessary and (such as > > with SCLs) actively annoying to them. > > Only if actually implemented as SCLs, in my opinion, but that is definitely an > opinion. > I phrased that wrong. It should have read: "_sometimes_ (such as with SCLs)". > > Modules offers the availability of multiple streams of software like SCLs > > does, but it sacrifices the ability to install them in parallel for the > > ability to install them in the standard locations on disk so that other > > software doesn't need to adapt to alternate locations (the number-one > > complaint received about SCLs). > > So, are modules are meant to replace SCLs? If so, surely the inability to > install multiple versions invalidates that? > They aren't incompatible technologies. If there is a case where parallel-installability is valuable, an SCL can still be made. But for the common case, we (Red Hat) determined that parallel-availability was more valuable and common. > For example, one of the issues I'm trying to resolve at work is providing both > Python 2.7 and Python 3.5 on RHEL 6. Python 2 and 3 are effectively separate tools and (given that they are built with parallel-installability in mind) should absolutely not be streams of the same module. Now, python3:3.7 vs. python3:3.8 might be a more interesting question... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
On 06. 11. 19 8:29, Miro Hrončok wrote: M2. For traditional packages, it was consistent and easy to find package dependencies in Fedora. For a proven packager, Fedora Packaging Committee member or generally for anybody doing a System Wide Change, being able to run queries like: $ repoquery --repo=rawhide --whatrequires 'libpython3.8.so.1.0()(64bit)' is trivial. Arguably, there are some quirks already (for example it doesn't properly work with boolean (rich?) deps). Witch modules, I still don't remember how to do this, but I know it requires more than 1 easy repoquery over rawhide. This is also currently complicated by the fact that when Fedora N branches, the modules are not there on Fedora N+1 until they are rebuilt. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On 14. 11. 19 20:58, Stephen Gallagher wrote: On Thu, Nov 14, 2019 at 1:33 PM Miro Hrončok wrote: On 14. 11. 19 19:11, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Nov 14, 2019 at 01:00:52PM -0500, Neal Gompa wrote: On Thu, Nov 14, 2019 at 12:59 PM Zbigniew Jędrzejewski-Szmek wrote: On Thu, Nov 14, 2019 at 06:43:42PM +0100, Miro Hrončok wrote: On 14. 11. 19 18:36, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Nov 14, 2019 at 06:08:52PM +0100, Miro Hrončok wrote: On 09. 10. 19 22:46, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot Enable module default streams in the buildroot repository for modular and non-modular RPMs. == Summary == This Change (colloquially referred to as "Ursa Prime") enables the Koji build-system to include the RPM artifacts provided by module default streams in the buildroot when building non-modular (or "traditional") RPMs. I have one more technical concern. Suppose a packager decides to package the "mycoolapp" software as a non-modular package. "mycoolapp" is written in Python, it builds again non-modular Python, currently 3.8, it requires "python(abi) = 3.8" on runtime. Hmm, and what about an even simpler case: "myswankyapp" is also written in Python, and is packaged as a module. Python is rebuilt in a side tag, then the module blocks the upgrade. What is supposed to happen in that case? The module is rebuilt after the side tag is merged. Al least that is what I think happened with avocado when we upgraded to Python 3.8. Automatically? And if the build fails? It's not automatic. Release Engineering has to kick it by hand by making a weird empty commit and triggering a build. And if the build fails? In case this isn't obvious: right now python-sig will pummel all the modules until they stop FTBFSing. If modules don't get the same treatment, we have a problem. Currently, modules don't get the same treatment. The reason basically is: I don't know how to repoquery all modules to see what modular packages still require Python 3.7. I was trying to get this information but at a certain point, I've stopped trying. That's a reasonable concern and a problem we do need to solve. Would you mind adding it to https://pagure.io/modularity/issues ? Done: https://pagure.io/modularity/issue/160 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity: The Official Complaint Thread
Le jeudi 14 novembre 2019 à 13:45 -0500, Stephen Gallagher a écrit : > On Thu, Nov 14, 2019 at 1:33 PM John M. Harris Jr < > joh...@splentity.com> wrote: > > On Thursday, November 14, 2019 11:15:15 AM MST Stephen Gallagher > > wrote: > > > I'm not sure what you're asking here. I thought it was pretty > > > clear > > > from the paragraph you quoted that containers are the recommended > > > solution for doing "parallel-install" with modules. Also, the > > > relationship goes both ways; Modules provide a trusted source of > > > software to run in containers (as opposed to running an image > > > that > > > someone uploaded to a public registry). > > > > Well, containers are currently the only "supported" way to have > > parallel > > installation of any Fedora packages. In essence, we don't have a > > solution for > > parallel installation at all. If Modules are supposed to go with > > containers, > > why not tack them onto Silverblue instead of the main distro? From > > what I've > > read, it seems they would fit that usecase much better than a > > traditional > > distribution, and we wouldn't need to address the issues that come > > from > > modules overriding non-modular packages. > > > > You're assuming that parallel-install is a thing that everyone needs > from every package on their system. Our research and surveys > determined that this was not in fact the case for the overwhelming > majority of real-world deployments. In any way the core problem is not parallel install (I completely agree parallel install is a marginal case), or building multiple versions of the same thing (that has been possible to do in rpm since forever). The problem is *selecting* the correct version, for build, install or update, once several are available, and maintaining a working conflict- less dependency graph. So, my own conclusion from the past years of module experiments, is that something that wanted to achieve the original objectives of modules, would need to invest heavily in dependency graph analysis, instead of trying to create separate module objects we have no clue on how to manage sanely. The module layer has not made any natural self-evident way to handle competing version streams appear. On the contrary, the segregation in module silos makes it harder to identify, diagnose and heal conflicts. If someone manages to define a working solver and a working conflict resolution strategy, I'm more and more certain that the changes needed in packages themselves, to provide the additionnal info required by this solver, will turn out to be minimal. Without a working solver multiple version streams won’t work out, upstream has not more clue (and quite often a lot less clue) on what the dep graph should be, that’s why it constantly creates piles of bundled unmaintainable and unmaintained code, and handwaves the maintainership problem to someone else. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Thu, Nov 14, 2019 at 1:33 PM Miro Hrončok wrote: > > On 14. 11. 19 19:11, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Nov 14, 2019 at 01:00:52PM -0500, Neal Gompa wrote: > >> On Thu, Nov 14, 2019 at 12:59 PM Zbigniew Jędrzejewski-Szmek > >> wrote: > >>> > >>> On Thu, Nov 14, 2019 at 06:43:42PM +0100, Miro Hrončok wrote: > On 14. 11. 19 18:36, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Nov 14, 2019 at 06:08:52PM +0100, Miro Hrončok wrote: > >> On 09. 10. 19 22:46, Ben Cotton wrote: > >>> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot > >>> > >>> Enable module default streams in the buildroot repository for modular > >>> and non-modular RPMs. > >>> > >>> == Summary == > >>> This Change (colloquially referred to as "Ursa Prime") enables the > >>> Koji build-system to include the RPM artifacts provided by module > >>> default streams in the buildroot when building non-modular (or > >>> "traditional") RPMs. > >> > >> I have one more technical concern. > >> > >> Suppose a packager decides to package the "mycoolapp" software as a > >> non-modular package. "mycoolapp" is written in Python, it builds > >> again non-modular Python, currently 3.8, it requires "python(abi) = > >> 3.8" on runtime. > > > > Hmm, and what about an even simpler case: > > "myswankyapp" is also written in Python, and is packaged as a module. > > Python is rebuilt in a side tag, then the module blocks the upgrade. > > What is supposed to happen in that case? > > The module is rebuilt after the side tag is merged. Al least that is > what I think happened with avocado when we upgraded to Python 3.8. > >>> > >>> Automatically? And if the build fails? > >>> > >> > >> It's not automatic. Release Engineering has to kick it by hand by > >> making a weird empty commit and triggering a build. > > > > And if the build fails? > > > > In case this isn't obvious: right now python-sig will pummel all the > > modules until they stop FTBFSing. If modules don't get the same > > treatment, we have a problem. > > Currently, modules don't get the same treatment. The reason basically is: > > I don't know how to repoquery all modules to see what modular packages still > require Python 3.7. I was trying to get this information but at a certain > point, > I've stopped trying. > That's a reasonable concern and a problem we do need to solve. Would you mind adding it to https://pagure.io/modularity/issues ? (Side note: that tracker has gotten badly backlogged, but Petr Sabata and I are planning to go through it tomorrow to clean it up and prioritize things. Don't be frightened by its current state!) ___ 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
