Fedora Rawhide-20181219.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 4 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 13/131 (x86_64), 1/24 (i386), 1/2 (arm) New failures (same test not failed in Rawhide-20181216.n.1): ID: 321299 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/321299 ID: 321300 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/321300 ID: 321328 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/321328 ID: 321405 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/321405 ID: 321406 Test: x86_64 universal install_repository_http_variation **GATING** URL: https://openqa.fedoraproject.org/tests/321406 ID: 321407 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/321407 ID: 321418 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/321418 Old failures (same test failed in Rawhide-20181216.n.1): ID: 321323 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/321323 ID: 321337 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/321337 ID: 321352 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/321352 ID: 321370 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/321370 ID: 321383 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/321383 ID: 321389 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/321389 ID: 321390 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/321390 ID: 321402 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/321402 Soft failed openQA tests: 4/131 (x86_64), 5/24 (i386) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Rawhide-20181216.n.1): ID: 321310 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/321310 ID: 321314 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/321314 ID: 321315 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/321315 ID: 321332 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/321332 ID: 321333 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/321333 ID: 321336 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/321336 ID: 321413 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/321413 ID: 321433 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/321433 ID: 321434 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/321434 Passed openQA tests: 114/131 (x86_64), 18/24 (i386) New passes (same test not passed in Rawhide-20181216.n.1): ID: 321320 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/321320 Skipped non-gating openQA tests: 1 of 157 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 1.34 to 1.20 Previous test data: https://openqa.fedoraproject.org/tests/320253#downloads Current test data: https://openqa.fedoraproject.org/tests/321287#downloads Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 1.06 to 1.50 Previous test data: https://openqa.fedoraproject.org/tests/320254#downloads Current test data: https://openqa.fedoraproject.org/tests/321288#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: Filesystem for mount / changed from /dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root to /dev/mapper/fedora-root Previous test data: https://openqa.fedoraproject.org/tests/320257#downloads Current test data: https://openqa.fedoraproject.org/tests/321291#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 1.42 to 1.68 Previous test data: https://openqa.fedoraproject.org/tests/320258#downloads Current test data: https://openqa.fedoraproject.org/tests/321292#downloads Installed system changes in test x86_64 Everything-boot-iso install_default@uefi: System load changed from 0.28 to 0.54 Previous test data:
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
On Thu, Dec 20, 2018 at 07:38:29AM +0100, Igor Gnatenko wrote: > So what process should I use? Pull Requests or just removing obsolete > stuff? I'm ready to do either way. Should I leave this to FESCo? The choice of implementation details is yours. You can always ask FESCo for opinion, but I don't think you'll get one that is much more definitive than the discussion here on the list. Zbyszek > On Wed, Dec 19, 2018 at 8:00 PM Jason L Tibbitts III > wrote: > > > > > "KL" == Kalev Lember writes: > > > > KL> I agree with Zbyszek, I think it would be best to push the changes > > KL> directly to git. > > > > But then we're back to the same problem: Do you remove the ldconfig > > calls entirely or do you add the macros? Prepare for flames if you get > > it wrong, even though it's nontrivial to get it right and reverting is > > far quicker than flaming. Then again, getting people more used to the > > idea that automated process are going to be making changes to packages > > is a good thing. > > > > All of this reminds me that it's well past time to move forward with the > > mass Group: removal. At least that one is a trivial change. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wasn't gpg supposed to be renamed to gpg1?
On 12/19/18 4:31 PM, John Harris wrote: On Wednesday, December 19, 2018 5:10:21 AM EST Bruno Wolff III wrote: gnupg2 is now obsoleting gnupg and the previous gpg command is not available. The change page said gpg would be renamed gpg1, but this was not done. Unfortunately gpg2 will not read my existing secret keys. (They are pretty old and probably should be replaced.) For now using rpm --nodeps allowed me to replaced the gnupg2 version of gpg with the gnupg version so I could get at some encrypted data, but it would be nice if the plan from the change page had been used instead of what was done. If the plan has changed, then updating the change page to match what was done would be nice. Though in the latter case there should be a warning about breaking things for some people. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org I can't believe this was done without using the alternatives system! Alternatives is not a solution, it's trouble looking for opportunities to make more. There are a handful of cases where it is appropriate, but using alternatives means retaining support for all of the variants throughout the distro. That's pretty much the opposite direction from obsoleting, which is the purpose here. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
So what process should I use? Pull Requests or just removing obsolete stuff? I'm ready to do either way. Should I leave this to FESCo? On Wed, Dec 19, 2018 at 8:00 PM Jason L Tibbitts III wrote: > > > "KL" == Kalev Lember writes: > > KL> I agree with Zbyszek, I think it would be best to push the changes > KL> directly to git. > > But then we're back to the same problem: Do you remove the ldconfig > calls entirely or do you add the macros? Prepare for flames if you get > it wrong, even though it's nontrivial to get it right and reverting is > far quicker than flaming. Then again, getting people more used to the > idea that automated process are going to be making changes to packages > is a good thing. > > All of this reminds me that it's well past time to move forward with the > mass Group: removal. At least that one is a trivial change. > > - J< > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] please review: PR 50105 - Fix UI/CLI bugs
https://pagure.io/389-ds-base/pull-request/50105 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[Bug 1646730] CVE-2018-18311 perl: Integer overflow leading to buffer overflow in Perl_my_setenv()
https://bugzilla.redhat.com/show_bug.cgi?id=1646730 Doran Moppert changed: What|Removed |Added Depends On||1661064 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2018-12-20 - 92% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2018/12/20/report-389-ds-base-1.4.0.20-20181220gitecdf6d8.fc29.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: packages for chat limited repo
On 12/19/18 5:38 AM, Cătălin George Feștilă wrote: Read all error (Problem: conflicting requests) and my dnf search (not xchat) is reported like : I don't like flame. I'm not quite sure what you're trying to say here, but the "conflicting requests" is because the package you want to install (gyachi) hasn't been successfully compiled since F24. The library versions that were available then aren't available now, so you can't install it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
On Wed, Dec 19, 2018 at 12:49:51PM -0600, Jason L Tibbitts III wrote: > > "KL" == Kalev Lember writes: > > KL> I agree with Zbyszek, I think it would be best to push the changes > KL> directly to git. > > But then we're back to the same problem: Do you remove the ldconfig > calls entirely or do you add the macros? Prepare for flames if you get > it wrong, even though it's nontrivial to get it right and reverting is > far quicker than flaming. For me that is the crucial point: why do we make such a big thing out of those issues, when 'git reset -p HEAD~' takes less time then writing a mail. > Then again, getting people more used to the > idea that automated process are going to be making changes to packages > is a good thing. Exactly. > All of this reminds me that it's well past time to move forward with the > mass Group: removal. At least that one is a trivial change. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intent to retire: yaml-cpp03
At the time yaml-cpp 0.6 was released several packages still needed the 0.3 API so the yaml-cpp03 package was created. Currently no package requires the library on F28 through Rawhide and it has a couple of CVE's attached to it that will not get fixed. My intention since there are no dependencies in Fedora is to retire it immediately. I have not yet evaluated EPEL... 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30 Self-Contained Change proposal: DeepinDE
https://fedoraproject.org/wiki/Changes/DeepinDE == Summary == Package the Deepin Desktop Environment for Fedora. == Owner == * Name: [[User:Zsun|Zamir SUN]] - main coordinator, packager * Email: zsun#AT#fedoraproject.org * [[User:Mosquito|Bowen Li]] - main packager * Email: mosquito#AT#fedoraproject.org == Detailed Description == [https://www.deepin.org/en/dde/ Deepin Desktop Environment] is the desktop environment released with [https://en.wikipedia.org/wiki/Deepin deepin]. It aims at being elegant and easy to use. == Benefit to Fedora == Deepin Desktop Environment will make Fedora a more interesting for users who prefer another choice of a shining desktop environment. == Scope == * Proposal owners: DeepinDE packages are already packaged and built in Fedora Rawhide (Fedora 30). * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/8003 #8003] ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == How To Test == You can install the Deepin Desktop Environment in Fedora like below. If you don't have other desktop installed before, ` sudo dnf install xorg-x11-server-Xorg`. Otherwise, just do the following sudo dnf update sudo dnf install deepin-desktop sudo dnf install deepin-calendar deepin-calculator deepin-editor deepin-image-viewer deepin-picker deepin-screenshot deepin-system-monitor And try your normal tasks on any desktop environment. == User Experience == Deepin Desktop Environment focuses on being elegant and easy to use. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Not announce the availability of Deepin Desktop in Fedora. * Contingency deadline: Beta Freeze * Blocks release? No. * Blocks product? None. == Documentation == * [https://github.com/FZUG/deepin-desktop The staging git repo of all spec files]. * [https://www.deepin.org/en/dde/ Deepin Desktop Environment] website. * [[SIGs/DeepinDE|DeepinDE SIG page]] -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 30 Self-Contained Change proposal: DeepinDE
https://fedoraproject.org/wiki/Changes/DeepinDE == Summary == Package the Deepin Desktop Environment for Fedora. == Owner == * Name: [[User:Zsun|Zamir SUN]] - main coordinator, packager * Email: zsun#AT#fedoraproject.org * [[User:Mosquito|Bowen Li]] - main packager * Email: mosquito#AT#fedoraproject.org == Detailed Description == [https://www.deepin.org/en/dde/ Deepin Desktop Environment] is the desktop environment released with [https://en.wikipedia.org/wiki/Deepin deepin]. It aims at being elegant and easy to use. == Benefit to Fedora == Deepin Desktop Environment will make Fedora a more interesting for users who prefer another choice of a shining desktop environment. == Scope == * Proposal owners: DeepinDE packages are already packaged and built in Fedora Rawhide (Fedora 30). * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/8003 #8003] ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == How To Test == You can install the Deepin Desktop Environment in Fedora like below. If you don't have other desktop installed before, ` sudo dnf install xorg-x11-server-Xorg`. Otherwise, just do the following sudo dnf update sudo dnf install deepin-desktop sudo dnf install deepin-calendar deepin-calculator deepin-editor deepin-image-viewer deepin-picker deepin-screenshot deepin-system-monitor And try your normal tasks on any desktop environment. == User Experience == Deepin Desktop Environment focuses on being elegant and easy to use. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Not announce the availability of Deepin Desktop in Fedora. * Contingency deadline: Beta Freeze * Blocks release? No. * Blocks product? None. == Documentation == * [https://github.com/FZUG/deepin-desktop The staging git repo of all spec files]. * [https://www.deepin.org/en/dde/ Deepin Desktop Environment] website. * [[SIGs/DeepinDE|DeepinDE SIG page]] -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Change proposal deadlines approaching
As a reminder, several Change proposal deadlines for Fedora 30 are approaching: * 2019-01-02 — Changes requiring infrastructure changes * 2019-01-08 — Changes requiring mass rebuild * 2019-01-08 — System-Wide changes * 2019-01-29 — Self-Contained changes For more information on Changes, see the Changes Policy page[1] on the Fedora Wiki. Changes processing will slow to a crawl (or slower) next week due to Red Hat's holiday shutdown. Fear not, you just need to have the Change proposal submitted by the deadline and I will process them once I return to the office. [1] https://fedoraproject.org/wiki/Changes/Policy -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Re: Fedora 30 Change proposal deadlines approaching
As a reminder, several Change proposal deadlines for Fedora 30 are approaching: * 2019-01-02 — Changes requiring infrastructure changes * 2019-01-08 — Changes requiring mass rebuild * 2019-01-08 — System-Wide changes * 2019-01-29 — Self-Contained changes For more information on Changes, see the Changes Policy page[1] on the Fedora Wiki. Changes processing will slow to a crawl (or slower) next week due to Red Hat's holiday shutdown. Fear not, you just need to have the Change proposal submitted by the deadline and I will process them once I return to the office. [1] https://fedoraproject.org/wiki/Changes/Policy -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
> "KL" == Kalev Lember writes: KL> I agree with Zbyszek, I think it would be best to push the changes KL> directly to git. But then we're back to the same problem: Do you remove the ldconfig calls entirely or do you add the macros? Prepare for flames if you get it wrong, even though it's nontrivial to get it right and reverting is far quicker than flaming. Then again, getting people more used to the idea that automated process are going to be making changes to packages is a good thing. All of this reminds me that it's well past time to move forward with the mass Group: removal. At least that one is a trivial change. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1456772] CVE-2017-0373 CVE-2017-0374 perl-Config-Model: various flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1456772 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |CURRENTRELEASE Flags|needinfo?(david.hannequin@g | |mail.com) | Last Closed||2018-12-19 14:47:59 --- Comment #5 from Jitka Plesnikova --- The CVEs are fixed for Fedora 27 and later. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1456771] CVE-2017-0374 perl-Config-Model: Local privilege escalation via crafted model
https://bugzilla.redhat.com/show_bug.cgi?id=1456771 Bug 1456771 depends on bug 1456772, which changed state. Bug 1456772 Summary: CVE-2017-0373 CVE-2017-0374 perl-Config-Model: various flaws [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1456772 What|Removed |Added Status|NEW |CLOSED Resolution|--- |CURRENTRELEASE -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1456770] CVE-2017-0373 perl-Config-Model: gen_class_pod implementation has dangerous "use lib" line
https://bugzilla.redhat.com/show_bug.cgi?id=1456770 Bug 1456770 depends on bug 1456772, which changed state. Bug 1456772 Summary: CVE-2017-0373 CVE-2017-0374 perl-Config-Model: various flaws [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1456772 What|Removed |Added Status|NEW |CLOSED Resolution|--- |CURRENTRELEASE -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Wasn't gpg supposed to be renamed to gpg1?
On Wednesday, December 19, 2018 5:10:21 AM EST Bruno Wolff III wrote: > gnupg2 is now obsoleting gnupg and the previous gpg command is not > available. > The change page said gpg would be renamed gpg1, but this was > not done. Unfortunately gpg2 will not read my existing secret keys. (They > are pretty old and probably should be replaced.) For now using rpm --nodeps > allowed me to replaced the gnupg2 version of gpg with the gnupg version so > I could get at some encrypted data, but it would be nice if the plan from > the change page had been used instead of what was done. If the plan has > changed, then updating the change page to match what was done would be > nice. Though in the latter case there should be a warning about breaking > things for some people. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org I can't believe this was done without using the alternatives system! -- John M. Harris, Jr. Splentity https://splentity.com/ signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wasn't gpg supposed to be renamed to gpg1?
Bruno Wolff III wrote: > In my case it would have helped if gnupg1 had obsoleted gnupg IMO, that is a better and safer approach ^^ -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 1 week)
On 19. 12. 18 15:03, Kevin Kofler wrote: Unfortunately, this list still contains many packages that were already retired eons ago. (The information that the packages are retired must have been lost for some reason during the migration to Pagure or during a Pagure upgrade.) E.g., kdelibs4 was renamed to kdelibs years ago. (It might make sense to rename it back now that we have KF5, but that is a different story.) So it is hard to find the packages that are really affected. I guess all the "orphan 71 weeks ago" packages are suspicious, though those are probably all the packages that were orphaned or retired before the Pagure migration, so some of them might have been just orphaned and not retired. This should all be gone after I mass retire on Monday. If the package is already retired but not known to be, retiring it again will make sure it is retired correctly. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
On Wed, Dec 19, 2018, 15:09 Zbigniew Jędrzejewski-Szmek On Wed, Dec 19, 2018 at 11:22:21AM +0100, Igor Gnatenko wrote: > > I've updated change which is explicitly mentions that I'm going to > > send Pull Requests to packages, so it should not make anyone unhappy. > > Are you sure this is a viable approach? > > $ rpm -qa --scripts|grep ldconfig|wc -l > 1130 > > (and I have only 5k packages installed, 20% of the whole distro?). > Counting one PR for every two ldconfigs, you'd have to open maybe > 500-2000 PRs. Not only is it a waste of _your_ time, but of the other > 500-2000 people to answer this. > I agree with Zbyszek, I think it would be best to push the changes directly to git. Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
On Wed, Dec 19, 2018 at 11:22:21AM +0100, Igor Gnatenko wrote: > On Wed, Dec 19, 2018 at 2:20 AM Jason L Tibbitts III > wrote: > > > > > "ZJ" == Zbigniew Jędrzejewski-Szmek writes: > > > > ZJ> I think it's pretty clear: all the standard invocations of > > ZJ> scriptlets that have by replaced by transfiletriggers will be > > ZJ> removed, along with the whole %post/%postun sections if its the only > > ZJ> thing in them. > > > > I do think it would be better to list exactly what is expected to be > > changed (and which packages actually need which changes). > > Done. > > * ldconfig scriptlets will be removed (or by maintainer request will > be replaced by %ldconfig_scriptlets macro which exists on Fedora and > EPEL) > * gtk-update-icon-cache, glib-compile-schemas, > gdk-pixbuf-query-loaders, gtk-query-immodules-3.0, gio-querymodules > and install-info will be removed (or by maintainer request will be > guarded with %if's) > > > > ZJ> I think that the way this should be handled is that if maintainers > > ZJ> of a package want to use a single branch for F30+ and > > ZJ> EPEL/RHEL/whatever, it is on them to arrange the spec file with the > > ZJ> appropriate conditionals. > > > > Well, that's what makes it tough. You can remove the scriptlets, or you > > can replace them with the various sets of macros which do nothing on > > Fedora and do something on EPEL (to the extent that is even possible). > > The macros needed are often context-dependent. Certainly just removing > > things is simplest but will cause the most upset. > > > > It's not trivial to know if a maintainer insists on the single spec > > approach, so it can be rather difficult to do this in an automated > > fashion. Of course it would be easy if everyone just fixed the packages > > they maintain so that there's no need for automated fixup. I'd hope > > that some of that might happen if the lists of packages which need > > changes are provided. I did some of that a couple of releases ago and I > > could try to do it again if someone could lengthen the day by a few > > hours. > > I've updated change which is explicitly mentions that I'm going to > send Pull Requests to packages, so it should not make anyone unhappy. Are you sure this is a viable approach? $ rpm -qa --scripts|grep ldconfig|wc -l 1130 (and I have only 5k packages installed, 20% of the whole distro?). Counting one PR for every two ldconfigs, you'd have to open maybe 500-2000 PRs. Not only is it a waste of _your_ time, but of the other 500-2000 people to answer this. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 1 week)
Unfortunately, this list still contains many packages that were already retired eons ago. (The information that the packages are retired must have been lost for some reason during the migration to Pagure or during a Pagure upgrade.) E.g., kdelibs4 was renamed to kdelibs years ago. (It might make sense to rename it back now that we have KF5, but that is a different story.) So it is hard to find the packages that are really affected. I guess all the "orphan 71 weeks ago" packages are suspicious, though those are probably all the packages that were orphaned or retired before the Pagure migration, so some of them might have been just orphaned and not retired. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1660774] Upgrade perl-Module-CoreList to 5.20181218
https://bugzilla.redhat.com/show_bug.cgi?id=1660774 --- Comment #2 from Fedora Update System --- perl-Module-CoreList-5.20181218-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ebe1bf77c3 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1660774] Upgrade perl-Module-CoreList to 5.20181218
https://bugzilla.redhat.com/show_bug.cgi?id=1660774 --- Comment #3 from Fedora Update System --- perl-Module-CoreList-5.20181218-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8e1115ec21 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1660774] Upgrade perl-Module-CoreList to 5.20181218
https://bugzilla.redhat.com/show_bug.cgi?id=1660774 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Module-CoreList-5.2018 ||1218-1.fc30 --- Comment #1 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: packages for chat limited repo
Read all error (Problem: conflicting requests) and my dnf search (not xchat) is reported like : I don't like flame. On Wed, Dec 19, 2018 at 3:30 PM Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 19 December 2018 at 14:25, Cătălin George Feștilă wrote: > > Can the problem of packet dependencies create such results? I do not > > see X-chat software. > > Try hexchat: > > $ rpm -q hexchat > hexchat-2.14.2-1.fc29.x86_64 > > Also, this is a user question, not a developer one, so please ask such > questions in the user list in the future. > > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Modularity] Working Group IRC meeting minutes (2018-12-18)
= #fedora-meeting-3: Weekly Meeting of the Modularity Working Group = Meeting started by nils at 15:00:00 UTC. Minutes: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-12-18/modularity_wg.2018-12-18-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-3/2018-12-18/modularity_wg.2018-12-18-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-12-18/modularity_wg.2018-12-18-15.00.log.html Meeting summary --- * Roll Call (nils, 15:00:12) * Agenda (nils, 15:04:37) * #112 Discussion: Module lifecycles (nils, 15:04:49) * #115 Discussion: Stream branch ownership for packages & modules (nils, 15:04:58) * #119 Modularity WG Charter (contd.) (nils, 15:05:09) * #112 Discussion: Module lifecycles (nils, 15:05:29) * LINK: https://pagure.io/modularity/issue/112 (nils, 15:05:41) * LINK: https://pagure.io/fesco/issue/2027 corresponding FESCo ticket (nils, 15:07:03) * #115 Discussion: Stream branch ownership for packages & modules (nils, 15:07:19) * LINK: https://pagure.io/fesco/issue/2028 corresponding FESCo ticket (nils, 15:07:57) * #119 Modularity WG Charter (contd.) (nils, 15:08:19) * LINK: https://pagure.io/modularity/issue/119 (nils, 15:08:32) * ACTION: nils updates #119, clarifying that the Council is informed of this charter and substantial changes (nils, 15:36:36) Meeting ended at 15:42:59 UTC. Action Items * nils updates #119, clarifying that the Council is informed of this charter and substantial changes Action Items, by person --- * nils * nils updates #119, clarifying that the Council is informed of this charter and substantial changes * **UNASSIGNED** * (none) People Present (lines said) --- * nils (73) * contyk (46) * langdon (27) * zodbot (9) * Son_Goku (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: packages for chat limited repo
On Wednesday, 19 December 2018 at 14:25, Cătălin George Feștilă wrote: > Can the problem of packet dependencies create such results? I do not > see X-chat software. Try hexchat: $ rpm -q hexchat hexchat-2.14.2-1.fc29.x86_64 Also, this is a user question, not a developer one, so please ask such questions in the user list in the future. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedora-rawhide-kernel-nodebug is not getting updates
On Sat, Dec 15, 2018 at 7:39 AM Bruno Wolff III wrote: > > On Wed, Dec 12, 2018 at 12:37:24 -0600, > Bruno Wolff III wrote: > >On Thu, Dec 06, 2018 at 14:29:15 +, > > "Richard W.M. Jones" wrote: > >> > >>Anyway it seems like Rawhide isn't getting new nodebug kernels. > >> > >>- Latest nodebug kernel: > >> kernel-4.20.0-0.rc1.git4.2.fc30.x86_64.rpm > >> (https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/) > >> > >>- Latest Rawhide kernel: > >> kernel-4.20.0-0.rc5.git2.1.fc30 > >> (https://koji.fedoraproject.org/koji/packageinfo?packageID=8) > > > >Something weird is going on. The git0.1 kernels make it in, but the > >other gitX.2 kernels don't. It keeps reverting to 4.20.0-0.rc1.git4.2. > >It reverted again today. > > Is this issue being tracked somewhere? If not, where is the correct place > to report it? Kernel list is the best place to report it, but I am looking into it. I occasionally miss the push, but I know I have pushed 2 already this week, yet for some reason it is still showing the 4.20.0-rc1.git4.2 I just pushed rc7 again as a test, and it seems to be updated. Let's see if it reverts. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: packages for chat limited repo
Can the problem of packet dependencies create such results? I do not see X-chat software. [root@desk mythcat]# dnf search chat Last metadata expiration check: 0:18:23 ago on Tue 18 Dec 2018 07:53:20 PM EET. ... On Tue, Dec 18, 2018 at 9:00 PM Scott Talbert wrote: > > On Tue, 18 Dec 2018, Cătălin George Feștilă wrote: > > > I try to install gyachi.x86_64 but I got errors. > > A full search gives just some packages, I don't know if this is a bug > > or a repo limited area. see my output. > > > > root@desk mythcat]# dnf install gyachi.x86_64 > > Last metadata expiration check: 0:16:07 ago on Tue 18 Dec 2018 07:33:15 PM > > EET. > > Error: > > Problem: conflicting requests > > - nothing provides libjavascriptcoregtk-1.0.so.0()(64bit) needed by > > gyachi-1.2.11-14.fc24.x86_64 > > - nothing provides libwebkitgtk-1.0.so.0()(64bit) needed by > > gyachi-1.2.11-14.fc24.x86_64 > > - nothing provides libjasper.so.1()(64bit) needed by > > gyachi-1.2.11-14.fc24.x86_64 > > gyachi hasn't been built successfully since F24: > https://koji.fedoraproject.org/koji/packageinfo?packageID=5764 > > It ought to be retired. > > Scott___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1646738] CVE-2018-18313 perl: Heap-based buffer read overflow in S_grok_bslash_N()
https://bugzilla.redhat.com/show_bug.cgi?id=1646738 Tomas Hoger changed: What|Removed |Added Summary|CVE-2018-18313 perl:|CVE-2018-18313 perl: |Heap-buffer-overflow read |Heap-based buffer read |in S_grok_bslash_N()|overflow in ||S_grok_bslash_N() -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1646734] CVE-2018-18312 perl: Heap-based buffer overflow in S_handle_regex_sets()
https://bugzilla.redhat.com/show_bug.cgi?id=1646734 Tomas Hoger changed: What|Removed |Added Summary|CVE-2018-18312 perl:|CVE-2018-18312 perl: |Heap-buffer-overflow write |Heap-based buffer overflow |/ reg_node overrun |in S_handle_regex_sets() --- Comment #6 from Tomas Hoger --- Upstream commit: https://github.com/Perl/perl5/commit/4db502b8711307951dfadc62a8f2c2eda922ca22 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1646738] CVE-2018-18313 perl: Heap-buffer-overflow read in S_grok_bslash_N()
https://bugzilla.redhat.com/show_bug.cgi?id=1646738 Tomas Hoger changed: What|Removed |Added Summary|CVE-2018-18313 perl:|CVE-2018-18313 perl: |Heap-buffer-overflow read |Heap-buffer-overflow read |in regcomp.c|in S_grok_bslash_N() -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1646751] CVE-2018-18314 perl: Heap-based buffer overflow in S_regatom()
https://bugzilla.redhat.com/show_bug.cgi?id=1646751 Tomas Hoger changed: What|Removed |Added Summary|CVE-2018-18314 perl:|CVE-2018-18314 perl: |Heap-based buffer overflow |Heap-based buffer overflow ||in S_regatom() -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1646730] CVE-2018-18311 perl: Integer overflow leading to buffer overflow in Perl_my_setenv()
https://bugzilla.redhat.com/show_bug.cgi?id=1646730 Tomas Hoger changed: What|Removed |Added Summary|CVE-2018-18311 perl:|CVE-2018-18311 perl: |Integer overflow leading to |Integer overflow leading to |buffer overflow |buffer overflow in ||Perl_my_setenv() -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Wasn't gpg supposed to be renamed to gpg1?
On Wed, Dec 19, 2018 at 11:28:16 +0100, Igor Gnatenko wrote: Seems that I missed writing announcement, but there is a package called `gnupg1` which provides `gpg1` binary. So you should be fine with that I hope. And sorry for this trouble. Thanks for the help. I'm not sure why I didn't find it with dnf search. It might be a good idea to mention it on the change page, on the off chance that someone else using it thinks to look at the change page. It might also help get it noted in the release notes. In my case it would have helped if gnupg1 had obsoleted gnupg, but I don't know if that was true for most people who had gnupg installed. I also already had gnupg2 installed already so I didn't need its installation triggered as part of the update. Other people might have needed that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wasn't gpg supposed to be renamed to gpg1?
Seems that I missed writing announcement, but there is a package called `gnupg1` which provides `gpg1` binary. So you should be fine with that I hope. And sorry for this trouble. On Wed, Dec 19, 2018 at 11:25 AM Bruno Wolff III wrote: > > gnupg2 is now obsoleting gnupg and the previous gpg command is not available. > The change page said gpg would be renamed gpg1, but this was not done. > Unfortunately gpg2 will not read my existing secret keys. (They are pretty > old and probably should be replaced.) For now using rpm --nodeps allowed > me to replaced the gnupg2 version of gpg with the gnupg version so I could > get at some encrypted data, but it would be nice if the plan from the change > page had been used instead of what was done. If the plan has changed, then > updating the change page to match what was done would be nice. Though in > the latter case there should be a warning about breaking things for some > people. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
On Wed, Dec 19, 2018 at 2:20 AM Jason L Tibbitts III wrote: > > > "ZJ" == Zbigniew Jędrzejewski-Szmek writes: > > ZJ> I think it's pretty clear: all the standard invocations of > ZJ> scriptlets that have by replaced by transfiletriggers will be > ZJ> removed, along with the whole %post/%postun sections if its the only > ZJ> thing in them. > > I do think it would be better to list exactly what is expected to be > changed (and which packages actually need which changes). Done. * ldconfig scriptlets will be removed (or by maintainer request will be replaced by %ldconfig_scriptlets macro which exists on Fedora and EPEL) * gtk-update-icon-cache, glib-compile-schemas, gdk-pixbuf-query-loaders, gtk-query-immodules-3.0, gio-querymodules and install-info will be removed (or by maintainer request will be guarded with %if's) > ZJ> I think that the way this should be handled is that if maintainers > ZJ> of a package want to use a single branch for F30+ and > ZJ> EPEL/RHEL/whatever, it is on them to arrange the spec file with the > ZJ> appropriate conditionals. > > Well, that's what makes it tough. You can remove the scriptlets, or you > can replace them with the various sets of macros which do nothing on > Fedora and do something on EPEL (to the extent that is even possible). > The macros needed are often context-dependent. Certainly just removing > things is simplest but will cause the most upset. > > It's not trivial to know if a maintainer insists on the single spec > approach, so it can be rather difficult to do this in an automated > fashion. Of course it would be easy if everyone just fixed the packages > they maintain so that there's no need for automated fixup. I'd hope > that some of that might happen if the lists of packages which need > changes are provided. I did some of that a couple of releases ago and I > could try to do it again if someone could lengthen the day by a few > hours. I've updated change which is explicitly mentions that I'm going to send Pull Requests to packages, so it should not make anyone unhappy. > - J< > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Wasn't gpg supposed to be renamed to gpg1?
gnupg2 is now obsoleting gnupg and the previous gpg command is not available. The change page said gpg would be renamed gpg1, but this was not done. Unfortunately gpg2 will not read my existing secret keys. (They are pretty old and probably should be replaced.) For now using rpm --nodeps allowed me to replaced the gnupg2 version of gpg with the gnupg version so I could get at some encrypted data, but it would be nice if the plan from the change page had been used instead of what was done. If the plan has changed, then updating the change page to match what was done would be nice. Though in the latter case there should be a warning about breaking things for some people. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[HEADS UP] Mesa is now built with meson
Hey folks, since 18.3.1-2 mesa is built using meson. Please let me know if it breaks anything. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity implementation with rpm DistTag
On Wed, Dec 19, 2018 at 09:54:07AM +0100, Michal Novotny wrote:
> Hello Fedora devels!
>
> TL;DR: let's use rpm DistTag (DistTag, not the %dist macro) to denote
> stream names
>
> As we all know, modularity was created to provide
> parallel-availability, that is providing the same package in its
> different major versions from the same rpm repository.
>
> The first question to ask is: "Why can't we just place two major
> versions of a package alongside in the repo?"
>
> That's possible but there are two problems with this. The first one is
> that when you type
>
> $ sudo dnf install git
>
> dnf needs to determine what major version of git it should install.
> User should be able to provide the information explicitly on
> command-line, that is:
>
> $ sudo dnf install git-1
>
> or
>
> $ sudo dnf install git-2
>
> but doing that always for each package you install could be quite demanding.
>
> The second problem is that once you have a git package of a certain
> major version installed, you want to keep it on that version when
> running an ordinary update command:
>
> $ sudo dnf update git
>
> dnf shouldn't be tempted to install git-2 (e.g. git-2.17.2-2) but it
> should instead update git-1 on the system to the latest available
> minor version if git-1 is the major version of git currently
> installed.
>
> Modularity solves the second problem by "streams" and the first
> problem by a "default stream".
>
> That's okay but I would argue there is much more simple solution to
> those two problems, which reuses already known terminology and
> technology.
>
> What can be done is to put the information into which stream a package
> belongs into the package spec file. That means, a packager will not
> need to edit some additional files to enable parallel-availability.
>
> I would argue that if every single package in Fedora used semantic
> versioning, then we wouldn't need streams at all. dnf could simply
> have a config option that would assure staying on the same major
> version during updates unless told otherwise.
>
> The concept of "stream" is only needed if there are upstreams/packages
> that do not exactly conform to semantic versioning where change in the
> first number means API breakage. I suspect there are quite a lot of
> them still and maybe, in some cases, we would like to have streams
> that stand for something else than a major version? E.g. devel that
> stores always the latest upstream state and is updated automatically.
>
> For that reason, I assume the concept of stream might be useful.
>
> But the question is how to provide a stream name through rpm?
>
> I was looking at
> https://github.com/rpm-software-management/rpm/blob/master/lib/rpmtag.h
> and found there is DistTag rpm tag that you can put into a spec file
> and that seems to be unused these days.
>
> According to what I have found in a comment in /usr/lib/rpm/macros on this
> tag:
>
> # Configurable distribution tag, same as DistTag: tag in a specfile.
> # The tag will be used to supply reliable information to tools like
> # rpmfind.
> #
> #%disttag
>
> Fedora packages do not have it set:
>
> E.g.:
>
> $ rpm -q --queryformat '%{DISTTAG}\n' prunerepo-1.13-1.fc28.noarch.rpm
> (none)
>
> and I don't think we need to care that much about rpmfind at least as
> far as DistTag is the concern.
>
> So it could be used to provide a "stream" name. I mean we don't really
> need to call it stream either. What we essentially want is to group
> packages of the same name by their major version or in some case by a
> descriptive string like "devel".
>
> Once we have this grouping provided for dnf, we can add an option like:
>
> updates_maintain_disttag=true/false
>
> which will make dnf updates stable if true and if packagers keep their
> DistTags set to package major versions.
>
> Another thing is that DistTag value can be automatically derived from
> DistGit branch name. Meaning that if you use arbitrary branching like
> e.g. nodejs uses (https://src.fedoraproject.org/rpms/nodejs/branches)
> where branch names correspond to major versions, then with some kind
> of auto-generation in place you can be just-about done only by
> creating a branch with a proper name.
>
> Funny thing is that this would work even if used with distro branches
> because in distro branches, packagers should not update majors per
> packaging guidelines (only maybe for leaf nodes with FESCo exception
> it might be possible) so even though such stream (e.g. f29) would be a
> mix of many different packages, those packages would maintain the same
> major version during the stream active existence.
>
> The second problem was to make
>
> $ sudo dnf update git
>
> work if there are e.g. two DistTags ("streams") 1 and 2.
>
> Do you pick git-1 from DistTag 1 or git-2 from DistTag 2?
>
> I would leave the decision what version to pick on a dnf config
> option, which could be e.g.:
>
> default_disttag_select_strategy=lowest_compatible
>
>
Re: Package bear got mixed with bear-factory, erlang-bear and bear-devel
> Hi list, > > I have discovered a very weird problem with the package bear on > apps.fedoraproject.org: it got somehow mixed with the (completely > unrelated) packages erlang-bear, bear-devel and bear-factory. > My actual question: what is going on? How do I get out of this mess? > > > Thanks in advance, > > Dan File a bug at https://github.com/fedora-infra/fedora-packages/issues/new The build is fine and you haven't broken anything. https://koji.fedoraproject.org/koji/buildinfo?buildID=1174017 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Modularity implementation with rpm DistTag
Hello Fedora devels!
TL;DR: let's use rpm DistTag (DistTag, not the %dist macro) to denote
stream names
As we all know, modularity was created to provide
parallel-availability, that is providing the same package in its
different major versions from the same rpm repository.
The first question to ask is: "Why can't we just place two major
versions of a package alongside in the repo?"
That's possible but there are two problems with this. The first one is
that when you type
$ sudo dnf install git
dnf needs to determine what major version of git it should install.
User should be able to provide the information explicitly on
command-line, that is:
$ sudo dnf install git-1
or
$ sudo dnf install git-2
but doing that always for each package you install could be quite demanding.
The second problem is that once you have a git package of a certain
major version installed, you want to keep it on that version when
running an ordinary update command:
$ sudo dnf update git
dnf shouldn't be tempted to install git-2 (e.g. git-2.17.2-2) but it
should instead update git-1 on the system to the latest available
minor version if git-1 is the major version of git currently
installed.
Modularity solves the second problem by "streams" and the first
problem by a "default stream".
That's okay but I would argue there is much more simple solution to
those two problems, which reuses already known terminology and
technology.
What can be done is to put the information into which stream a package
belongs into the package spec file. That means, a packager will not
need to edit some additional files to enable parallel-availability.
I would argue that if every single package in Fedora used semantic
versioning, then we wouldn't need streams at all. dnf could simply
have a config option that would assure staying on the same major
version during updates unless told otherwise.
The concept of "stream" is only needed if there are upstreams/packages
that do not exactly conform to semantic versioning where change in the
first number means API breakage. I suspect there are quite a lot of
them still and maybe, in some cases, we would like to have streams
that stand for something else than a major version? E.g. devel that
stores always the latest upstream state and is updated automatically.
For that reason, I assume the concept of stream might be useful.
But the question is how to provide a stream name through rpm?
I was looking at
https://github.com/rpm-software-management/rpm/blob/master/lib/rpmtag.h
and found there is DistTag rpm tag that you can put into a spec file
and that seems to be unused these days.
According to what I have found in a comment in /usr/lib/rpm/macros on this tag:
# Configurable distribution tag, same as DistTag: tag in a specfile.
# The tag will be used to supply reliable information to tools like
# rpmfind.
#
#%disttag
Fedora packages do not have it set:
E.g.:
$ rpm -q --queryformat '%{DISTTAG}\n' prunerepo-1.13-1.fc28.noarch.rpm
(none)
and I don't think we need to care that much about rpmfind at least as
far as DistTag is the concern.
So it could be used to provide a "stream" name. I mean we don't really
need to call it stream either. What we essentially want is to group
packages of the same name by their major version or in some case by a
descriptive string like "devel".
Once we have this grouping provided for dnf, we can add an option like:
updates_maintain_disttag=true/false
which will make dnf updates stable if true and if packagers keep their
DistTags set to package major versions.
Another thing is that DistTag value can be automatically derived from
DistGit branch name. Meaning that if you use arbitrary branching like
e.g. nodejs uses (https://src.fedoraproject.org/rpms/nodejs/branches)
where branch names correspond to major versions, then with some kind
of auto-generation in place you can be just-about done only by
creating a branch with a proper name.
Funny thing is that this would work even if used with distro branches
because in distro branches, packagers should not update majors per
packaging guidelines (only maybe for leaf nodes with FESCo exception
it might be possible) so even though such stream (e.g. f29) would be a
mix of many different packages, those packages would maintain the same
major version during the stream active existence.
The second problem was to make
$ sudo dnf update git
work if there are e.g. two DistTags ("streams") 1 and 2.
Do you pick git-1 from DistTag 1 or git-2 from DistTag 2?
I would leave the decision what version to pick on a dnf config
option, which could be e.g.:
default_disttag_select_strategy=lowest_compatible
where sorting of DistTags follows the rules used by sort linux command
in en_US.UTF-8 locale:
$ sort
0
1.1
devel
3
1.11
0
1.1
1.11
3
devel
This means git-1 in its highest minor version is picked but only if
its compatible with already installed packages in the system. If not
compatbile, git-2 (having the next lowest DistTag)
[Bug 1660774] New: Upgrade perl-Module-CoreList to 5.20181218
https://bugzilla.redhat.com/show_bug.cgi?id=1660774 Bug ID: 1660774 Summary: Upgrade perl-Module-CoreList to 5.20181218 Product: Fedora Version: rawhide Status: NEW Component: perl-Module-CoreList Assignee: ppi...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, st...@silug.org, tcall...@redhat.com Target Milestone: --- Classification: Fedora Latest Fedora delivers 5.20181130 version. Upstream released 5.20181218. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1660773] New: Upgrade perl-File-Map to 0.66
https://bugzilla.redhat.com/show_bug.cgi?id=1660773 Bug ID: 1660773 Summary: Upgrade perl-File-Map to 0.66 Product: Fedora Version: rawhide Status: NEW Component: perl-File-Map Assignee: emman...@seyman.fr Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, lkund...@v3.sk, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.65 version. Upstream released 0.66. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
