[Bug 1916381] perl-URI-5.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916381 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-URI-5.06-1.fc34 Resolution|--- |RAWHIDE Last Closed||2021-01-15 07:43:33 -- 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 1916381] perl-URI-5.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916381 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|caillon+fedoraproject@gmail | |.com, ka...@ucw.cz, | |p...@city-fan.org, | |rhug...@redhat.com, | |rstr...@redhat.com, | |sandm...@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
Re: Self Introduction: Jan Zerdik
Hi Jan, On Wed, 2021-01-13 at 16:25 +0100, Jan Zerdik wrote: > Hi. My name is Jan and I'm a new red hatter. I'll be a TuneD co- > maintainer. My experience with open source projects is mostly just as > a user, but I'm looking forward to joining the community. > Welcome! I'm an occasional user of tuned and would love to see it get some desktop integration. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 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://docs.fedoraproject.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-server: permanent meeting time?
On Fri, 2021-01-08 at 08:16 -0800, Michel Alexandre Salim wrote: > Hello all, > > Looking at the reboot meeting logs, looks like we initially meant to > reconvene on January 6, then pivoted to finding a next meeting time > and > avoid selection bias... then with the holidays that never happened. > > I've started a WhenIsGood, picking a timezone that should work for > people from the US West Coast all the way to Central Europe -- if > this > doesn't work for you, please chime in and I'll get this edited: > > https://whenisgood.net/dqn59sz > > These are one-hour slots, over a period of two weeks starting next > Monday (UTC); please find a time that will work for you regularly so > we > can then just schedule a permanent meeting. > > I've also slotted in a recurring meeting in the calendar that we can > use by default if we can't find consensus on a new meeting slot -- > it's > two weeks after the initial Jan 6 proposal, at the same time (18:00 > UTC): https://apps.fedoraproject.org/calendar/server/2021/1/20/ > Looks like everyone should be able to make next Wednesday, January 20th at 17:00 UTC (12 PM ET, 9 AM PT). I've updated the calendar since this is one hour earlier than the reboot meeting. There is a monthly CentOS meeting that is held on the 2nd Wednesdays of the month at the same time, and the calendar does not allow setting week-of-month recurrence, so I'll make sure to adjust for any conflict in advance. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 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://docs.fedoraproject.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 1915876] perl-PAR-1.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1915876 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2021-f6d63fd6b1 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f6d63fd6b1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f6d63fd6b1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bd945e3b55 adplug-2.3.3-1.el8 audacious-plugins-4.0.5-3.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e976495093 coturn-4.5.2-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing castxml-0.4.1-1.el8 chromium-87.0.4280.141-1.el8 python-aiodns-2.0.0-6.el8 Details about builds: castxml-0.4.1-1.el8 (FEDORA-EPEL-2021-1e2f276b60) C-family abstract syntax tree XML output tool Update Information: CastXML 0.4.1. ChangeLog: * Thu Jan 14 2021 Mattias Ellert - 0.4.1-1 - Update to version 0.4.1 * Thu Jan 14 2021 Mattias Ellert - 0.4.0-1 - Update to version 0.4.0 - Fix expected test output on 32-bit architectures (i686/armv7hl) References: [ 1 ] Bug #1915610 - castxml-0.4.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1915610 chromium-87.0.4280.141-1.el8 (FEDORA-EPEL-2021-47ea069c76) A WebKit (Blink) powered web browser Update Information: Update Chromium to 87.0.4280.141. Fixes: CVE-2021-21106 CVE-2021-21107 CVE-2021-21108 CVE-2021-21109 CVE-2021-21110 CVE-2021-2 CVE-2021-21112 CVE-2021-21113 CVE-2020-16043 CVE-2021-21114 CVE-2020-15995 CVE-2021-21115 CVE-2021-21116 ChangeLog: * Wed Jan 13 2021 Tom Callaway - 87.0.4280.141-1 - update to 87.0.4280.141 * Wed Dec 30 2020 Tom Callaway - 87.0.4280.88-2 - rebuild against new gcc (rawhide) * Thu Dec 17 2020 Tom Callaway - 87.0.4280.88-1.1 - add two patches for missing headers to build with gcc 11 References: [ 1 ] Bug #1913624 - CVE-2021-21106 chromium-browser: Use after free in autofill https://bugzilla.redhat.com/show_bug.cgi?id=1913624 [ 2 ] Bug #1913625 - CVE-2021-21107 chromium-browser: Use after free in drag and drop https://bugzilla.redhat.com/show_bug.cgi?id=1913625 [ 3 ] Bug #1913626 - CVE-2021-21108 chromium-browser: Use after free in media https://bugzilla.redhat.com/show_bug.cgi?id=1913626 [ 4 ] Bug #1913627 - CVE-2021-21109 chromium-browser: Use after free in payments https://bugzilla.redhat.com/show_bug.cgi?id=1913627 [ 5 ] Bug #1913629 - CVE-2021-21110 chromium-browser: Use after free in safe browsing https://bugzilla.redhat.com/show_bug.cgi?id=1913629 [ 6 ] Bug #1913630 - CVE-2021-2 chromium-browser: Insufficient policy enforcement in WebUI https://bugzilla.redhat.com/show_bug.cgi?id=1913630 [ 7 ] Bug #1913631 - CVE-2021-21112 chromium-browser: Use after free in Blink https://bugzilla.redhat.com/show_bug.cgi?id=1913631 [ 8 ] Bug #1913632 - CVE-2021-21113 chromium-browser: Heap buffer overflow in Skia https://bugzilla.redhat.com/show_bug.cgi?id=1913632 [ 9 ] Bug #1913633 - CVE-2020-16043 chromium-browser: Insufficient data validation in networking https://bugzilla.redhat.com/show_bug.cgi?id=1913633 [ 10 ] Bug #1913634 - CVE-2021-21114 chromium-browser: Use after free in audio https://bugzilla.redhat.com/show_bug.cgi?id=1913634 [ 11 ] Bug #1913635 - CVE-2020-15995 chromium-browser: Out of bounds write in V8 https://bugzilla.redhat.com/show_bug.cgi?id=1913635 [ 12 ] Bug #1913636 - CVE-2021-21115 chromium-browser: Use after free in safe browsing https://bugzilla.redhat.com/show_bug.cgi?id=1913636 [ 13 ] Bug #1913637 - CVE-2021-21116 chromium-browser: Heap buffer overflow in audio https://bugzilla.redhat.com/show_bug.cgi?id=1913637 python-aiodns-2.0.0-6.el8 (FEDORA-EPEL-2021-05afc2bbd3) Simple DNS resolver for asyncio Update Information: Add Patch0 to fix epel8 installation package ChangeLog: * Wed Jan 13 2021 Matthieu Saulnier - 2.0.0-6 - Add Patch0 to fix epel8 installation package Backport from upstream commit: 28111210 References: [ 1 ] Bug #1915746 -
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 28 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599 openjpeg2-2.3.1-10.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-143227c7ed sympa-6.2.60-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5843fdc72c adplug-2.3.3-1.el7 audacious-plugins-4.0.5-3.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6bfa86551f coturn-4.5.2-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing blitz-1.0.1-5.el7 chromium-87.0.4280.141-1.el7 liferea-1.13.5-1.el7 python-junit_xml-1.7-2.el7 qpid-proton-0.33.0-1.el7 Details about builds: blitz-1.0.1-5.el7 (FEDORA-EPEL-2021-77e387a201) C++ class library for matrix scientific computing Update Information: Blitz is a C++ matrix library ChangeLog: References: [ 1 ] Bug #1140772 - Please build an EPEL7 build of blitz https://bugzilla.redhat.com/show_bug.cgi?id=1140772 chromium-87.0.4280.141-1.el7 (FEDORA-EPEL-2021-d851c69e59) A WebKit (Blink) powered web browser Update Information: Update Chromium to 87.0.4280.141. Fixes: CVE-2021-21106 CVE-2021-21107 CVE-2021-21108 CVE-2021-21109 CVE-2021-21110 CVE-2021-2 CVE-2021-21112 CVE-2021-21113 CVE-2020-16043 CVE-2021-21114 CVE-2020-15995 CVE-2021-21115 CVE-2021-21116 ChangeLog: * Wed Jan 13 2021 Tom Callaway - 87.0.4280.141-1 - update to 87.0.4280.141 * Wed Dec 30 2020 Tom Callaway - 87.0.4280.88-2 - rebuild against new gcc (rawhide) * Thu Dec 17 2020 Tom Callaway - 87.0.4280.88-1.1 - add two patches for missing headers to build with gcc 11 References: [ 1 ] Bug #1913624 - CVE-2021-21106 chromium-browser: Use after free in autofill https://bugzilla.redhat.com/show_bug.cgi?id=1913624 [ 2 ] Bug #1913625 - CVE-2021-21107 chromium-browser: Use after free in drag and drop https://bugzilla.redhat.com/show_bug.cgi?id=1913625 [ 3 ] Bug #1913626 - CVE-2021-21108 chromium-browser: Use after free in media https://bugzilla.redhat.com/show_bug.cgi?id=1913626 [ 4 ] Bug #1913627 - CVE-2021-21109 chromium-browser: Use after free in payments https://bugzilla.redhat.com/show_bug.cgi?id=1913627 [ 5 ] Bug #1913629 - CVE-2021-21110 chromium-browser: Use after free in safe browsing https://bugzilla.redhat.com/show_bug.cgi?id=1913629 [ 6 ] Bug #1913630 - CVE-2021-2 chromium-browser: Insufficient policy enforcement in WebUI https://bugzilla.redhat.com/show_bug.cgi?id=1913630 [ 7 ] Bug #1913631 - CVE-2021-21112 chromium-browser: Use after free in Blink https://bugzilla.redhat.com/show_bug.cgi?id=1913631 [ 8 ] Bug #1913632 - CVE-2021-21113 chromium-browser: Heap buffer overflow in Skia https://bugzilla.redhat.com/show_bug.cgi?id=1913632 [ 9 ] Bug #1913633 - CVE-2020-16043 chromium-browser: Insufficient data validation in networking https://bugzilla.redhat.com/show_bug.cgi?id=1913633 [ 10 ] Bug #1913634 - CVE-2021-21114 chromium-browser: Use after free in audio https://bugzilla.redhat.com/show_bug.cgi?id=1913634 [ 11 ] Bug #1913635 - CVE-2020-15995 chromium-browser: Out of bounds write in V8 https://bugzilla.redhat.com/show_bug.cgi?id=1913635 [ 12 ] Bug #1913636 - CVE-2021-21115 chromium-browser: Use after free in safe browsing https://bugzilla.redhat.com/show_bug.cgi?id=1913636 [ 13 ] Bug #1913637 - CVE-2021-21116 chromium-browser: Heap buffer overflow in audio https://bugzilla.redhat.com/show_bug.cgi?id=1913637 liferea-1.13.5-1.el7 (FEDORA-EPEL-2021-9d5b0573f0) An RSS/RDF feed reader Update Information: new version ChangeLog: * Tue Jan 12 2021 josef radinger - 1:1.13.5-1 - bump version References: [ 1 ] Bug #1786583 - liferea switched ui language partly from german to
Fedora-Rawhide-20210114.n.1 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 20/180 (x86_64), 12/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210113.n.0): ID: 756248 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/756248 ID: 756269 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/756269 ID: 756283 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/756283 ID: 756313 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/756313 ID: 756314 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/756314 ID: 756352 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/756352 ID: 756369 Test: aarch64 Server-dvd-iso install_repository_nfs_graphical@uefi URL: https://openqa.fedoraproject.org/tests/756369 ID: 756416 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/756416 ID: 756418 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/756418 ID: 756419 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/756419 ID: 756442 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/756442 ID: 756460 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/756460 ID: 756461 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/756461 ID: 756476 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/756476 ID: 756479 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/756479 ID: 756483 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/756483 ID: 756501 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/756501 ID: 756513 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/756513 ID: 756514 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/756514 ID: 756521 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/756521 ID: 756530 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/756530 ID: 756531 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/756531 ID: 756547 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/756547 Old failures (same test failed in Fedora-Rawhide-20210113.n.0): ID: 756294 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/756294 ID: 756299 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/756299 ID: 756308 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/756308 ID: 756462 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/756462 ID: 756489 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/756489 ID: 756516 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/756516 ID: 756525 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/756525 ID: 756560 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/756560 ID: 756568 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/756568 Soft failed openQA tests: 5/180 (x86_64), 3/122 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210113.n.0): ID: 756236 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/756236 ID: 756240 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/756240 ID: 756330 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/756330 ID: 756340 Test: aarch64 Server-dvd-iso
[Bug 1913160] perl-Gnome2-VFS-1.084 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1913160 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Gnome2-VFS-1.084-1.fc3 |perl-Gnome2-VFS-1.084-1.fc3 |4 |4 ||perl-Gnome2-VFS-1.084-1.fc3 ||3 Resolution|--- |ERRATA Last Closed||2021-01-15 01:26:27 --- Comment #6 from Fedora Update System --- FEDORA-2021-5e973c4eb1 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1913143] perl-Gnome2-GConf-1.047 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1913143 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Gnome2-GConf-1.047-1.f |perl-Gnome2-GConf-1.047-1.f |c34 |c34 ||perl-Gnome2-GConf-1.047-1.f ||c33 Resolution|--- |ERRATA Last Closed||2021-01-15 01:26:25 --- Comment #8 from Fedora Update System --- FEDORA-2021-4d4c4d0a39 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1913111] perl-Gnome2-1.048 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1913111 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Gnome2-1.048-1.fc34|perl-Gnome2-1.048-1.fc34 ||perl-Gnome2-1.048-1.fc33 Resolution|--- |ERRATA Last Closed||2021-01-15 01:26:23 --- Comment #8 from Fedora Update System --- FEDORA-2021-391cafbfed has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
FedoraRespin-33-updates-20210114.0 compose check report
Missing expected images: Mate live x86_64 Failed openQA tests: 6/37 (x86_64) ID: 756196 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/756196 ID: 756198 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/756198 ID: 756206 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/756206 ID: 756214 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/756214 ID: 756223 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/756223 ID: 756226 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/756226 Soft failed openQA tests: 1/37 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 756202 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/756202 Passed openQA tests: 30/37 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20210114.n.1 changes
OLD: Fedora-Rawhide-20210113.n.0 NEW: Fedora-Rawhide-20210114.n.1 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 4 Dropped packages:4 Upgraded packages: 216 Downgraded packages: 0 Size of added packages: 5.47 MiB Size of dropped packages:3.01 MiB Size of upgraded packages: 4.83 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 81.95 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20210114.n.1.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: pg-semver-0.30.0-1.module_f34+10957+daa040f2 Summary: A semantic version data type for PostgreSQL RPMs:pg-semver Size:134.51 KiB Package: postgresql-ip4r-2.4.1-5.module_f34+10957+daa040f2 Summary: IPv4/v6 type and IPv4/v6 range index type for PostgreSQL RPMs:postgresql-ip4r Size:406.70 KiB Package: postgresql-pgpool-II-4.1.2-2.module_f34+10957+daa040f2 Summary: Pgpool is a connection pooling/replication server for PostgreSQL RPMs:postgresql-pgpool-II postgresql-pgpool-II-devel postgresql-pgpool-II-extensions Size:3.81 MiB Package: timescaledb-1.7.4-1.module_f34+10957+daa040f2 Summary: Open-source time-series database powered by PostgreSQL RPMs:timescaledb Size:1.13 MiB = DROPPED PACKAGES = Package: apache-commons-chain-1.2-24.fc33 Summary: An implementation of the GoF Chain of Responsibility pattern RPMs:apache-commons-chain apache-commons-chain-javadoc Size:441.70 KiB Package: golang-github-thomsonreuterseikon-ntlm-0-0.14.20190114gitcf23bd1.fc33 Summary: NTLM Implementation for Go RPMs:golang-github-thomsonreuterseikon-ntlm-devel Size:40.81 KiB Package: skipfish-2.10-0.23.b.fc33 Summary: Web application security scanner RPMs:skipfish Size:1.07 MiB Package: thunderbird-enigmail-2.1.6-2.fc33 Summary: Authentication and encryption extension for Mozilla Thunderbird RPMs:thunderbird-enigmail Size:1.47 MiB = UPGRADED PACKAGES = Package: Add64-3.9.3-4.fc34 Old package: Add64-3.9.3-2.fc34 Summary: An additive synthesizer using JACK RPMs: Add64 Size: 779.54 KiB Size change: -6.36 KiB Package: Cadence-1.0.0-0.13.20200604gitc167f35.fc34 Old package: Cadence-1.0.0-0.12.20200504git5787908.fc33 Summary: A set of tools useful for audio production RPMs: Cadence Size: 8.77 MiB Size change: -3.79 KiB Changelog: * Thu Jan 14 2021 Martin Gansser - 1.0.0-0.13.20200604gitc167f35 - Update to 1.0.0-0.13.20200604gitc167f35 Package: R-BH-1.75.0.0-1.fc34 Old package: R-BH-1.72.0.3-5.fc33 Summary: Boost C++ Header Files for R RPMs: R-BH-devel Size: 9.08 MiB Size change: 606.58 KiB Changelog: * Wed Jan 13 2021 Tom Callaway - 1.75.0.0-1 - update to 1.75.0-0 Package: R-expm-0.999.6-1.fc34 Old package: R-expm-0.999.5-1.fc34 Summary: Computation of the matrix exponential and related quantities RPMs: R-expm Size: 1.08 MiB Size change: 6.30 KiB Changelog: * Wed Jan 13 2021 Tom Callaway - 0.999.6-1 - update to 0.999-6 Package: Thunar-4.16.2-1.fc34 Old package: Thunar-4.16.1-1.fc34 Summary: Thunar File Manager RPMs: Thunar Thunar-devel Thunar-docs Size: 10.24 MiB Size change: -38.38 KiB Changelog: * Wed Jan 13 2021 Mukundan Ragavan - 4.16.2-1 - Update to 4.16.2 Package: annobin-9.57-1.fc34 Old package: annobin-9.52-2.fc34 Summary: Annotate and examine compiled binary files RPMs: annobin annobin-annocheck Size: 1.17 MiB Size change: -24.32 KiB Changelog: * Mon Jan 04 2021 Nick Clifton - 9.53-1 - Add support for -D_FORTIFY_SOURCE=3. * Mon Jan 04 2021 Nick Clifton - 9.54-1 - Fix inconsistency reporting -fcf-protection and -fstack-clash-protection results. * Tue Jan 12 2021 Nick Clifton - 9.55-1 - Improved testing by annocheck. Add fixed format message mode. * Wed Jan 13 2021 Nick Clifton - 9.56-1 - Fix bogus AArch64 test failures. * Wed Jan 13 2021 Nick Clifton - 9.57-1 - Workaround for elflint problems with PPC compiled files. (#1880634) Package: asciidoc-9.0.4-3.fc34 Old package: asciidoc-9.0.4-2.fc34 Summary: Text based document generation RPMs: asciidoc asciidoc-doc asciidoc-latex asciidoc-music Size: 395.04 KiB Size change: 299 B Changelog: * Thu Jan 14 2021 Josef Ridky - 9.0.4-3 - remove ImageMagic requirement Package: awscli-1.18.214-1.fc34 Old package: awscli-1.18.212-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.95 MiB Size change: 1.88 KiB Changelog: * Wed Jan 13 2021 Gwyn Ciesla - 1.18.213-1 - 1.18.213 * Thu Jan 14 2021 Gwyn Ciesla - 1.18.214-1 - 1.18.214 Package: bcm283x-firmware-20210108-1.934252b.fc34 Old package: bcm283x-firmware-20201216-1.8a5549c.fc34 Summary
[389-devel] Re: Deref plugin entries == NULL #4525
> On 14 Jan 2021, at 21:32, Pierre Rogier wrote: > > Hi William, > > > It's a scenario we will need to fix via your BE work because of the MVCC > > transaction model that > > LMDB will force us to adopt :) > > As I see things in the early phases the lmdb read txn will probably only be > managed at the db plugin level rather than at backend level. That means that > we will have the same inconsistency risk than today (i.e as if using bdb and > the implicit txn). > The txn model redesign you are speaking about should only occur in one of the > last phases (once bdb does no more coexists with lmdb). > It must be done because it could provide a serious performance boost for read > operations (IMHO, In most cases we could avoid to duplicate the db data) > But we should not do it while bdb is still around because of the risk of lock > issue and excessive retries. Yep, agreed. It will be needed for a large read performance boost, but just to prevent exactly this kind of issue. We should be able to move to a model where everything is always within a transaction. We could introduce it earlier and have the read txns be a no-op for bdb and continue using the implied transactions that we currently have, but also perhaps there is then no benefit to doing this earlier :) > > Note I put a phasing section in > https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-phase3.html#phasing > explaining that. But I guess I should move it within Ludwig's document that > englobs it. > > Pierre > > On Thu, Jan 14, 2021 at 12:01 AM William Brown wrote: > > > > On 13 Jan 2021, at 21:24, Pierre Rogier wrote: > > > > Thank you Willian, > > So far your scenario (entry found when reading base entry but no more > > existing when computing the candidates) is the only one that matches the > > symptoms. > > It's a scenario we will need to fix via your BE work because of the MVCC > transaction model that LMDB will force us to adopt :) > > > And that triggered a thought: > > We cannot do anything for SUBTREE and ONE_LEVEL searches > > because the fact that the base entry id is not in the candidate may be > > normal > > but IMHO we should improve the BASE search case. > > In this case the candidate list is directly set to the base entry id > > ==> if the candidate entry (in ldbm_back_next_search_entry) is not found > > and the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY error .. > > I suspect that Mark has seen this email and submitted a PR to resolve this > exact case :) > > > > > >Pierre > > > > > > On Wed, Jan 13, 2021 at 1:45 AM William Brown wrote: > > Hey there, > > > > https://github.com/389ds/389-ds-base/pull/4525/files > > > > I had a look and I can see a few possible contributing factors, but without > > a core and the exact state I can't be sure if this is correct. It's all > > just hypothetical from reading the code. > > > > > > The crash is in deref_do_deref_attr() which is called as part of > > deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by > > "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb, > > SLAPI_PLUGIN_PRE_ENTRY_FN);" > > > > > > I think what's important here is that the search is conducted in > > ./ldap/servers/slapd/opshared.c:818 rc = (*be->be_search)(pb); Is *not* > > in a transaction. That means that while the single search in be_search() is > > consistent due to an implied transaction, the subsequent search in > > deref_pre_entry() is likely conducted in a seperate transaction. This > > allows for other operations to potentially interleave and cause changes - > > modrdn or delete would certainly be candidates to cause a DN to be remove > > between these two points. It would be extremely hard to reproduce as a race > > condition of course. > > > > > > A question you asked is why don't we get a "no such entry" error or > > similar? I think that this is because build_candidate_list in ldbm_search.c > > doesn't actually create an error if the base_candidates list is empty, > > because an IDL is allocated with a value of 0 (no matching entries). this > > allows the search to proceed, and there are no errors, and the result set > > is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in > > this process, but without looking further into it, my suspicion is that > > entries of size 0 WONT return an error condition to internal_search_pb, so > > it's valid for this to be empty. > > > > Anyway, again, this is just reading the code for 20 minutes, and is not a > > complete in depth investigation, but maybe it's some ideas about what > > happened? > > > > Hope it helps :) > > > > > > > > — > > Sincerely, > > > > William Brown > > > > Senior Software Engineer, 389 Directory Server > > SUSE Labs, Australia > > ___ > > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > > To
Fedora-IoT-34-20210114.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64) New failures (same test not failed in Fedora-IoT-34-20210104.0): ID: 756124 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/756124 ID: 756139 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/756139 Old failures (same test failed in Fedora-IoT-34-20210104.0): ID: 756117 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/756117 ID: 756126 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/756126 ID: 756131 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/756131 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210104.0): ID: 756110 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/756110 Passed openQA tests: 13/16 (x86_64), 12/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20210104.0): ID: 756121 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/756121 ID: 756125 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/756125 ID: 756128 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/756128 ID: 756129 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/756129 ID: 756135 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/756135 ID: 756136 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/756136 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 180 MiB to 160 MiB System load changed from 0.22 to 0.07 Previous test data: https://openqa.fedoraproject.org/tests/751224#downloads Current test data: https://openqa.fedoraproject.org/tests/756111#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 181 MiB to 160 MiB System load changed from 0.34 to 0.15 Previous test data: https://openqa.fedoraproject.org/tests/751225#downloads Current test data: https://openqa.fedoraproject.org/tests/756112#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: Used mem changed from 192 MiB to 168 MiB System load changed from 0.43 to 0.16 Previous test data: https://openqa.fedoraproject.org/tests/751240#downloads Current test data: https://openqa.fedoraproject.org/tests/756127#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Jan Zerdik
- Original Message - > > > Le 1/13/21 à 4:25 PM, Jan Zerdik a écrit : > > Hi. My name is Jan and I'm a new red hatter. I'll be a TuneD co-maintainer. > > My experience with open source projects is mostly just as a user, but I'm > > looking forward to joining the community. > > > > ___ > > 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 > > > > Hi Jan, > > Welcome and I wish you the best around here. > > Frédéric > > Welcome Jan and enjoy Jaroslav ___ 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
turning off ELN build failure notifications
Hello, Could someone please help me figure out which rule I need to edit over at Fedora Notifications, to stop receiving messages like this one? On Thu, Jan 14, 2021 at 9:53 PM wrote: > > Notification time stamped 2021-01-14 20:53:32 UTC > > bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-25.eln108 > failed to build > http://koji.fedoraproject.org/koji/buildinfo?buildID=1659686 > > -- > You received this message due to your preference settings at > https://apps.fedoraproject.org/notifications/alexpl.id.fedoraproject.org/email/31305 I thought it should be one of the Jenkins or the CI rules, but from their description I don't understand how they could apply to this type of event. Ideally, I'd like to never see anything about ELN builds failing in my inbox. Thanks, A. ___ 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 34 Change: Localization measurement and tooling (Self-Contained Change proposal)
Transtats covers 100 packages, while the change darknao and I do the following (stats are for f33): * use dnf to download all srpm for a fedora relaese (21330 packages) * detect po files (2230 packages have at least one po file, more file format exists, but it will be for the future ;)) * extract all po files (200 337 po files) * deduct language list (344 languages) * produce stats and consolidated files (16GB of files before compression) * publish a website (2 GB once files are compressed) The Transtats UI is good, but it really is focused on translation propagation accross system, bringing a huge complexity. Sometimes we can't prevent complexity, but I don't really understand the main goal/use case transtats want to answer. It may simply solve issues I don't have. I'm really happy of the discussion we are having through this change process, I think we should use change process more often! ___ 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: Needing Some Maintenance Help
Hi Guido, On Thu, 2021-01-14 at 20:38 +0100, Guido Aulisi wrote: > I'm involved in audio/music packaging too, and I have some experience > with lv2 plugins, so I can comaintain your lv2 packages. > I don't know dssi enough, so I can't maintain dssi packages. > I can also help maintain jmeters, meterbridge and soundtracker. > > My FAS account is tartina > I added you to everything beginning with lv2, jmeters, and meterbridge. It turns out I'm not the main for Soundtracker, so I listed that one by mistake. As for dssi, it's pretty much dead as the upstream hasn't seen development in years. The package is pretty much in maintenance mode at this point and will likely get retired at the first signn of a FTBFS, which luckily for people that use dssi, hasn't happened yet. -- Erich Eickmeyer Project LeaderUbuntu Studio Council MemberUbuntu Community Council MaintainerFedora Jam ___ 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: Needing Some Maintenance Help
Hi Erich,
Il giorno gio, 14/01/2021 alle 10.14 -0800, Erich Eickmeyer ha scritto:
> Hi All,
>
> Over the course of the past few months, I have become employed by a
> company to provide their user software experience. This has limited
> the
> time that I have, and, unfortunately, my involvement in Fedora has,
> and
> needs to, decrease.
>
> I currently maintain the Fedora Jam lab, and would like some help
> with
> that. Just last night, while I was trying to relax after my day, I
> was
> CC'd on two bug reports only because I'm Jam's maintainer, when
> really
> the responsibility for the issues in question (pipewire related in
> Rawhide) lie on the change owner(s) for the Pipewire-By-Default
> change.
>
> I fixed a couple of packages only as a courtesy that were related to
> the issue (unable to install the @audio group), but that
> responsibility
> lies with the change owner(s), of which I'm not a part due to time
> restrictions. I removed myself from the bug report after that and had
> explained that they needed to add the change owner(s).
>
> This same person that CC'd me on that decided to then file a bug
> report
> against Jam 34 which is currently FTBFS due to the aforementioned
> issue
> with the @audio group. Since we (spin/lab maintainers) get automated
> emails about these things, I told them not to file bug reports
> against
> spins/labs in the future and closed it as errata. I realize this
> person
> was only trying to help, but it caused me some undo stress.
>
> This made me realize that I need to take a step back. Not only have I
> gained employment with a company that is using Ubuntu as their base
> (specifically Kubuntu with Ubuntu Studio partnership), but I've also
> become a MOTU with Ubuntu ("Master Of The Universe [repository]",
> much
> like a proven packager here). As such, Fedora isn't exactly integral
> to
> what I do, but I'd like to keep my rpm packaging skills somewhat
> sharpened, which is why I'll be keeping certain packages that I have
> direct involvement upstream with (e.g. studio-controls).
>
> So, here's what I'm looking for:
>
> * Someone to help me maintain Jam
> * Including fedora-jam-backgrounds and fedora-jam-kde-theme
> packages
>
> * Co-maintainers and/or new maintainers for the following packages:
>
> * Add64
> * dssi
> * dssi-vst
> * fluidsynth
> * fluidsynth-dssi
> * freqtweak
> * giada
> * gnome-guitar
> * harmonyseq
> * hexter-dssi
> * jackctlmmc
> * jmeters
> * libinstpatch
> * lv2-c++-tools
> * lv2-fabla
> * lv2-ll-plugins
> * lv2-mdaEPiano
> * lv2-newtonator
> * lv2-sorcer
> * lv2-swh-plugins
> * lv2-vocoder-plugins
> * meterbridge
> * python-alsaaudio
> * python-jack-client
> * radium-compressor
> * realTimeConfigQuickScan
> * soundtracker
> * whysynth-dssi
> * xsynth-dssi
I'm involved in audio/music packaging too, and I have some experience
with lv2 plugins, so I can comaintain your lv2 packages.
I don't know dssi enough, so I can't maintain dssi packages.
I can also help maintain jmeters, meterbridge and soundtracker.
My FAS account is tartina
> Simply let me know which package you'd like and if you'd like to
> maintain or co-maintain along with your fas username.
>
> Thanks in advance,
> Erich
Thanks for your work for Jam Lab
> --
> Erich Eickmeyer
> Maintainer
> Fedora Jam
Ciao
Guido
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://docs.fedoraproject.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
Fedora 34 Change: BIND 9.16 (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/BIND9.16
== Summary ==
BIND 9 would be updated to upcoming stable version BIND 9.16.
== Owner ==
* Name: [[User:pemensik| Petr Menšík]]
* Email: pemensik at redhat.com, dns-sig at fedoraproject dot org
== Detailed Description ==
ISC BIND 9 stayed longer time on 9.11 Extended Support Version,
because dhcp and freeipa depended on it. DHCP package no longer
requires bind-export-libs, which new BIND 9.16 does not support.
FreeIPA part bind-dyndb-ldap were also modified to support new
version.
BIND 9.16 includes more easy way to provide DNSSEC
([https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP)
KASP]).
== Benefit to Fedora ==
Stable version under most the active development is packaged again.
Introduces
[https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP)
DNSSEC Key and Signing Policy] without external tools like opendnssec.
Also client tools from '''bind-utils''' now support yaml export format
(''dig, mdig, delv'').
== Scope ==
* Proposal owners:
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
*
[https://downloads.isc.org/isc/bind9/9.11.26/doc/arm/Bv9ARM.ch05.html#lightweight_resolver
lightweight resolver (lwres)] server and nss client plugin are no
longer provided.
* named version with database backends support (bind-sdb) is also no
longer provided as subpackage. Instead several bind-dlz-* plugins are
offered as runtime loadable plugins, which require modification to
named configuration. They offer the same functionality with just
'''bind''' package and selected plugin.
* ''dnssec-enabled'' option is not supported anymore, it is always set
to ''yes''. ''dnssec-validation'' can be still turned off.
== How To Test ==
System administrators would receive the most recent stable version of
BIND, with improved performance and features.
Prerelease is available on
[https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/ COPR].
== User Experience ==
* named service supports ''dnssec-policy'' option, merging
''dnssec-keymgr'' into ''named''.
* DNSSEC trust anchors were merged into ''trust-anchors'' section,
replacing previous ''trusted-keys'' and ''managed-keys''.
* '''dig +yaml''' provides machine parseable output in YAML format
== Dependencies ==
* bind-dyndb-ldap (required by freeipa)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
* Blocks product? product
== Documentation ==
* Upstream [https://bind9.readthedocs.io/en/v9_16_10/notes.html BIND
9.16 Release Notes]
* [https://bind9.readthedocs.io/en/v9_16_10/notes.html#notes-for-bind-9-16-0
Added and removed features]
* Upstream
[https://downloads.isc.org/isc/bind9/9.14.0/RELEASE-NOTES-bind-9.14.0.html
BIND 9.14 Release Notes]
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: gate stable release critical path updates on openQA test results
On 14. 01. 21 18:24, Adam Williamson wrote: On Thu, 2021-01-14 at 13:21 +0100, Miro Hrončok wrote: On 14. 01. 21 13:15, Kevin Kofler via devel wrote: Adam Williamson wrote: As feedback on this was mostly positive, I went ahead and did the work. The PR for the Greenwave policy has been merged already, as that does not in itself cause any actual behaviour change: https://pagure.io/fedora-infra/ansible/pull-request/349 The PR for Bodhi is here: https://github.com/fedora-infra/bodhi/pull/4180 merging that *would* cause the proposal to be implemented, and start gating updates. Please yell if you think this isn't ready yet and you didn't yell already, or you see any issues in the practical implementation. Thanks! Shouldn't such a policy change go through a FESCo vote first? (I guess they will just wave it through, sadly, but still, I think it ought to go through a democratic vote.) Or even a change proposal ;) Honestly, I don't really know. To me it doesn't really fit the Change process. If you'd like to have FESCo vote on it I can file a ticket for sure. We've had Changes in the past that really were not coupled with any Fedora releases but rather affected the way we build/ship/test stuff. IMHO it is the best way to raise awareness and collect more feedback. But I don't "insist", it was merely a suggestion. -- 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: [apt-cacher-ng] Resurrect dead package
Le 1/13/21 à 10:36 PM, Pablo Sebastián Greco a écrit : Hi Frederic, thanks for doing this, I have a few local fixes for it but never got around to resurrect it, I'll likely create some PRs after it is back up. You are welcome. If you are interested to test it, you can use my COPR repository: fepitre/fedora. Latest builds corresponds to my master branch version 3.5-2: https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/commits/master where since yesterday I've fixed few things to make it work. In this case, any feedback would help for the review process. Currently I'm testing it on Fedora 32 for caching Debian repositories. Pablo. On 13/1/21 17:41, Frédéric Pierret wrote: Hi, I've resurrected `apt-cacher-ng` on my fork: https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafbb23a43b4279dab045040717a025c83c?branch=master with successful builds on my testing COPR repository for F32+ and EPEL8: https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/. I plan to (already) use this package for my current work on reproducible builds. Is the procedure described in https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?rd=PackageMaintainers/OrphanedPackages#Claiming_Ownership_of_a_Retired_Package still available for such case? Thank you. Best regards, Frédéric Pierret Best, Frédéric OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Needing Some Maintenance Help
Hi All,
Over the course of the past few months, I have become employed by a
company to provide their user software experience. This has limited the
time that I have, and, unfortunately, my involvement in Fedora has, and
needs to, decrease.
I currently maintain the Fedora Jam lab, and would like some help with
that. Just last night, while I was trying to relax after my day, I was
CC'd on two bug reports only because I'm Jam's maintainer, when really
the responsibility for the issues in question (pipewire related in
Rawhide) lie on the change owner(s) for the Pipewire-By-Default change.
I fixed a couple of packages only as a courtesy that were related to
the issue (unable to install the @audio group), but that responsibility
lies with the change owner(s), of which I'm not a part due to time
restrictions. I removed myself from the bug report after that and had
explained that they needed to add the change owner(s).
This same person that CC'd me on that decided to then file a bug report
against Jam 34 which is currently FTBFS due to the aforementioned issue
with the @audio group. Since we (spin/lab maintainers) get automated
emails about these things, I told them not to file bug reports against
spins/labs in the future and closed it as errata. I realize this person
was only trying to help, but it caused me some undo stress.
This made me realize that I need to take a step back. Not only have I
gained employment with a company that is using Ubuntu as their base
(specifically Kubuntu with Ubuntu Studio partnership), but I've also
become a MOTU with Ubuntu ("Master Of The Universe [repository]", much
like a proven packager here). As such, Fedora isn't exactly integral to
what I do, but I'd like to keep my rpm packaging skills somewhat
sharpened, which is why I'll be keeping certain packages that I have
direct involvement upstream with (e.g. studio-controls).
So, here's what I'm looking for:
* Someone to help me maintain Jam
* Including fedora-jam-backgrounds and fedora-jam-kde-theme packages
* Co-maintainers and/or new maintainers for the following packages:
* Add64
* dssi
* dssi-vst
* fluidsynth
* fluidsynth-dssi
* freqtweak
* giada
* gnome-guitar
* harmonyseq
* hexter-dssi
* jackctlmmc
* jmeters
* libinstpatch
* lv2-c++-tools
* lv2-fabla
* lv2-ll-plugins
* lv2-mdaEPiano
* lv2-newtonator
* lv2-sorcer
* lv2-swh-plugins
* lv2-vocoder-plugins
* meterbridge
* python-alsaaudio
* python-jack-client
* radium-compressor
* realTimeConfigQuickScan
* soundtracker
* whysynth-dssi
* xsynth-dssi
Simply let me know which package you'd like and if you'd like to
maintain or co-maintain along with your fas username.
Thanks in advance,
Erich
--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: Migrating the Fedora Developer Portal to Fedora Docs
On Thu, Jan 14, 2021 at 08:41:04AM +, Ankur Sinha wrote: > On Wed, Jan 13, 2021 13:45:23 -0800, Kevin Fenzi wrote: > > > > > > I'm in favor if you can convince them to do it. ;) > > Let's see how it goes :D > > Incidentally: who am I convincing? > > The wiki page doesn't list any names[1]. Is there a SIG or a team that > maintains this? Would this fall under Websites (or Mindshare or CommOps > or Infra?) since it doesn't seem to fall under Docs. > > [1] https://fedoraproject.org/wiki/Websites/Developer#About_The_Project The following folks had permssions on the developer vm back when we had that, otherwise I am not sure: asamalik jstribny phracek pvalena kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-14 at 13:21 +0100, Miro Hrončok wrote: > On 14. 01. 21 13:15, Kevin Kofler via devel wrote: > > Adam Williamson wrote: > > > As feedback on this was mostly positive, I went ahead and did the work. > > > The PR for the Greenwave policy has been merged already, as that does > > > not in itself cause any actual behaviour change: > > > https://pagure.io/fedora-infra/ansible/pull-request/349 > > > > > > The PR for Bodhi is here: > > > https://github.com/fedora-infra/bodhi/pull/4180 > > > > > > merging that *would* cause the proposal to be implemented, and start > > > gating updates. Please yell if you think this isn't ready yet and you > > > didn't yell already, or you see any issues in the practical > > > implementation. Thanks! > > > > Shouldn't such a policy change go through a FESCo vote first? > > > > (I guess they will just wave it through, sadly, but still, I think it ought > > to go through a democratic vote.) > > Or even a change proposal ;) Honestly, I don't really know. To me it doesn't really fit the Change process. If you'd like to have FESCo vote on it I can file a ticket for sure. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-01-15 from 17:00:00 to 18:00:00 US/Eastern At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[Bug 1916381] New: perl-URI-5.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916381 Bug ID: 1916381 Summary: perl-URI-5.06 is available Product: Fedora Version: rawhide Status: NEW Component: perl-URI Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com, ka...@ucw.cz, p...@city-fan.org, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 5.06 Current version/release in rawhide: 5.05-1.fc34 URL: http://search.cpan.org/dist/URI/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3485/ -- 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: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 12, 2021 at 8:22 PM Brian C. Lane wrote: > On Tue, Jan 05, 2021 at 01:05:01PM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents > > > > Note that this change was submitted after the deadline, but since it can > be > > shipped in an complete state, I am still processing it for Fedora 34. > > > > > > == Summary == > > We want to add signatures to individual files that are part of shipped > RPMs. > > These signatures will use the Linux IMA (Integrity Measurement > > Architecture) scheme, which means they can be used to enforce runtime > > policies to ensure execution of only trusted files. > > Who is going to use this feature? My guess is a very limited set of > users, so it seems unfair to dramatically increase the size of their > downloads and install footprint to support something they don't use. > Can't they be shipped on the side? An rpm of signatures that's > optionally installed would be more user friendly. > > Also, I (being unfamiliar with IMA), don't see how this is any better > than trusting the file hash signed by the fedora keys that we currently > have. > > Brian > I work on an upstream security project (https://keylime.dev), we are packaged in Fedora that would hugely benefit from this. In turn our users will be able to more easily manage the remote attestation of a Fedora system (as Fedora is our target environment). > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > ___ > 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: Orphaned perl-XML-SAX-ExpatXS, perl-Math-Libm, perl-Math-NumSeq, perl-Math-PlanePath, perl-Math-Factor-XS
On Wed, Jan 13, 2021 at 02:07:21AM +0100, Miro Hrončok wrote: > I have orphaned: > > perl-XML-SAX-ExpatXS > perl-Math-Libm > perl-Math-NumSeq > perl-Math-PlanePath > perl-Math-Factor-XS > I took them. Many thanks for maintaing them so far. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: proposal: move Data Corruption criterion from Final to Beta
On Mon, Jan 11, 2021 at 1:04 PM Kamil Paral wrote: > Hello, I already sent this proposal (quoted below) to the test list last > week. Please read the existing discussion at: > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/BFN427ECEZTGYCDKHJYH6VWWTGDA2BSG/ > > So far, I collected a thumbs up from Chris Murphy and Ben Cotton. I'm > forwarding it also here to the devel list, to collect more feedback, if > there is any. > Because there have been no concerns, I implemented the change today: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/message/V3XH3DIRZA4TUMTUL5RNKZSXUNPJUCLV/ Cheers, Kamil ___ 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Jan 14, 2021 at 10:48 AM Chris Murphy wrote: > > > > On Thu, Jan 14, 2021, 2:24 AM Vitaly Zaitsev via devel > wrote: >> >> On 31.12.2020 13:36, Javier Martinez Canillas wrote: >> > I'll update the proposal based on the feedback. >> >> And what about users, who use Fedora with other GNU/Linux distributions? >> These distributions can also switch to the same GRUB2 configuration. >> They will all start fighting for the same file. That's why a separate >> /boot/efi/EFI/$distro_name/grub.cfg configuration file was introduced. > > > > That's Fedora specific. Upstream puts it in /boot/grub/ regardless of > firmware. > Also, this only solves the problem when installing different distros. The problem still exists if multiple Fedora are installed since all will share the same EFI vendor directory. But yes, multi boot should probably also be taken into account in the design. That's why it will be important to agree with GRUB upstream on this and have buy-in from the other distros. Best regards, Javier ___ 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: libelf now depends on openssl
On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel wrote: Do the boringssl symbols not have hidden visibility in libwebrtc? If they do, why are they getting interposed anyway? If they don't, why not? I assume the library is private to libwebrtc and its symbols should not be exported. libwebrtc is a static lib, and so is boringssl. So all symbols, except unused symbols, will be directly included in libwebkit2gtk. In release builds, they would then be hidden by a linker script, but in developer builds everything is exported because API tests depend on internal symbols. ___ 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 1910212] perl-Tk-GraphViz-1.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1910212 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Tk-GraphViz-1.10-1.fc3 ||4 Resolution|--- |RAWHIDE Assignee|lkund...@v3.sk |jples...@redhat.com Doc Type|--- |If docs needed, set a value Last Closed||2021-01-14 13:59:02 -- 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: libdnet in Fedora
Thanks - it all seemed to go OK. Interestingly the libdnet SONAME did not change. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ 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: protobuf 3.14 update coming to rawhide
On Thu, Jan 07, 2021 at 10:18:37AM +0100, Adrian Reber wrote: > I prepared a protobuf update for rawhide to 3.14. It requires a rebuild > of all dependencies and of the 54 dependencies currently only 3 fail to > rebuild in COPR: > > https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-14/packages/ > > paraview: timeout after 10 hours, should work in koji > > community-mysql: test failure, this usually does not happen in koji > > libgadu: actual build failures, but seems unrelated to protobuf: > > /usr/bin/ld: sha1.o (symbol from plugin): undefined reference to symbol > 'SHA1_Init@@OPENSSL_1_1_0' > /usr/bin/ld: /usr/lib64/libcrypto.so.1.1: error adding symbols: DSO missing > from command line > > > I will start the rebuilds in rawhide in a side-tag in about a week All rebuilds are done, but I have not merged the side tag yet. * community-mysql still fails with test errors: https://koji.fedoraproject.org/koji/buildinfo?buildID=1668254 * libgadu still fails with the same error https://koji.fedoraproject.org/koji/buildinfo?buildID=1669177 * gazebo failed (it did not fail in COPR) with: -- Set runtime path of "/builddir/build/BUILDROOT/gazebo-10.1.0-13.fc34.arm/usr/bin/gzserver-10.1.0" to "" CMake Error at armv7hl-redhat-linux-gnueabi/gazebo/cmake_install.cmake:79 (file): file INSTALL cannot find "/builddir/build/BUILD/gazebo-10.1.0/armv7hl-redhat-linux-gnueabi/gazebo/gzserver.1.gz": No such file or directory. Call Stack (most recent call first): armv7hl-redhat-linux-gnueabi/cmake_install.cmake:100 (include) * I did not try fawkes as it requires a rebuilt version of gazebo I would like to merge the side tag in the next days, please let me know if there are any ideas how to solve the four failures. Adrian ___ 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: libdnet in Fedora
[Adding Cathy who is the open-vm-tools maintainer in RHEL and Ravindra who is the maintainer in Fedora] On Thu, Jan 14, 2021 at 01:36:05PM +0100, Oliver Falk wrote: > On Thu, Jan 14, 2021 at 12:49 PM Richard W.M. Jones wrote: > > Hi Oliver and others, > > I'm trying to fix a few things in Fedora's libdnet and have some > questions. > > (1) I'm unclear what the canonical upstream of libdnet should be. > There seem to be a couple of candidates: > > https://github.com/boundary/libdnet - not updated since 2016 > https://github.com/ofalk/libdnet - recently updated > > The current spec file points to the "boundary" repo, but I think we > should move to Oliver Falk's apparently more active fork. > > (2) If we move to the ofalk repo, then there is a new version (1.14). > > (3) I received a bug report about multilib conflicts with this > package. I previously fixed this > (https://bugzilla.redhat.com/342001), but my fix was reverted, > apparently by a bad revert commit: > > https://src.fedoraproject.org/rpms/libdnet/c/ > 224a9645782f69ae05b0e7caeb2e52e12b5655cb?branch=master > > I would therefore like to include the multilib fix again. > > Please let me know your thoughts on all this. > > Hey Richard! > > Due to the inactivity of the previous maintainer, yes, I took over libdnet and > tried to fix a few long standing issues. Given this also incorporated some ABI > incompatibilities, the version (and soname) were raised. API compatibility, > however, should be OK and if there is any issue, I'm sure we can sort that out > as well. > If there is anything that needs to be fixed, please open an issue on GitHub > and > /or provide a PR and I'll be happy to review and merge! Thanks for confirmation. I will do the update shortly, but only in Rawhide, and we'll see what the fall-out is. Ravindra: I'll also rebuild open-vm-tools against the new package (again, only in Rawhide). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Proposal: gate stable release critical path updates on openQA test results
On 14. 01. 21 13:15, Kevin Kofler via devel wrote: Adam Williamson wrote: As feedback on this was mostly positive, I went ahead and did the work. The PR for the Greenwave policy has been merged already, as that does not in itself cause any actual behaviour change: https://pagure.io/fedora-infra/ansible/pull-request/349 The PR for Bodhi is here: https://github.com/fedora-infra/bodhi/pull/4180 merging that *would* cause the proposal to be implemented, and start gating updates. Please yell if you think this isn't ready yet and you didn't yell already, or you see any issues in the practical implementation. Thanks! Shouldn't such a policy change go through a FESCo vote first? (I guess they will just wave it through, sadly, but still, I think it ought to go through a democratic vote.) Or even a change proposal ;) -- 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 1916189] New: perl-XML-Feed-0.60 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916189 Bug ID: 1916189 Summary: perl-XML-Feed-0.60 is available Product: Fedora Version: rawhide Status: NEW Component: perl-XML-Feed Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.60 Current version/release in rawhide: 0.59-7.fc33 URL: http://search.cpan.org/dist/XML-Feed Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8396/ -- 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: Proposal: gate stable release critical path updates on openQA test results
Adam Williamson wrote: > As feedback on this was mostly positive, I went ahead and did the work. > The PR for the Greenwave policy has been merged already, as that does > not in itself cause any actual behaviour change: > https://pagure.io/fedora-infra/ansible/pull-request/349 > > The PR for Bodhi is here: > https://github.com/fedora-infra/bodhi/pull/4180 > > merging that *would* cause the proposal to be implemented, and start > gating updates. Please yell if you think this isn't ready yet and you > didn't yell already, or you see any issues in the practical > implementation. Thanks! Shouldn't such a policy change go through a FESCo vote first? (I guess they will just wave it through, sadly, but still, I think it ought to go through a democratic vote.) 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: hotplug headphone detection in pipewire? (was: Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change))
On 14/01/2021 11:45, Felix Schwarz wrote: I switched a desktop F33 machine from pulseaudio to pipewire and it seems to work fine at a quick glance: $ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing $ systemctl --user enable pipewire pipewire-pulse Now I have the problem when I re-plug my headphones (old-fashioned headphone jack) that I don't see the headphones as output device via "pactl list sinks" (neither via pavucontrol, gnome's audio settings, ...). There's an upstream ticket that may be related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/533 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: ceph's builds started to fail in Fedora rawhide
On Wed, Jan 13, 2021 at 08:18:27AM -0500, Kaleb Keithley wrote: > > On Wed, Jan 13, 2021 at 8:17 AM Kaleb Keithley wrote: > > > On Tue, Jan 12, 2021 at 3:27 AM wrote: > > Notification time stamped 2021-01-12 08:26:20 UTC > > ceph's builds started to fail in Fedora rawhide >     > https://apps.fedoraproject.org/koschei/package/ceph?collection= > f34 > > > > I updated my rawhide box yesterday and it builds fine on that. > > There is no compiler/compilation error in the build logs, just make > terminating. OOM killed perhaps? > > > I.e. in the build.logs of the the koji scratch builds I have run. We had this happen because of LTO. However I only saw this (for me) on armv7, and IIRC ceph isn't built on 32 bit arches any longer. Anyway if you can't find the answer any other way, try to see if disabling LTO makes a difference. https://fedoraproject.org/wiki/LTOByDefault#Documentation Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: libdnet in Fedora
On Thu, Jan 14, 2021 at 11:49:51AM +, Richard W.M. Jones wrote: > Hi Oliver and others, > > I'm trying to fix a few things in Fedora's libdnet and have some > questions. > > (1) I'm unclear what the canonical upstream of libdnet should be. > There seem to be a couple of candidates: > > https://github.com/boundary/libdnet - not updated since 2016 > https://github.com/ofalk/libdnet - recently updated > > The current spec file points to the "boundary" repo, but I think we > should move to Oliver Falk's apparently more active fork. I meant to ask if Oliver's version is still API compatible. The real reason we have libdnet is because of open-vm-tools, so if it breaks open-vm-tools then we'd have to stick with the "boundary" version. > (2) If we move to the ofalk repo, then there is a new version (1.14). > > (3) I received a bug report about multilib conflicts with this > package. I previously fixed this > (https://bugzilla.redhat.com/342001), but my fix was reverted, > apparently by a bad revert commit: > > https://src.fedoraproject.org/rpms/libdnet/c/224a9645782f69ae05b0e7caeb2e52e12b5655cb?branch=master > > I would therefore like to include the multilib fix again. > > Please let me know your thoughts on all this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
libdnet in Fedora
Hi Oliver and others, I'm trying to fix a few things in Fedora's libdnet and have some questions. (1) I'm unclear what the canonical upstream of libdnet should be. There seem to be a couple of candidates: https://github.com/boundary/libdnet - not updated since 2016 https://github.com/ofalk/libdnet - recently updated The current spec file points to the "boundary" repo, but I think we should move to Oliver Falk's apparently more active fork. (2) If we move to the ofalk repo, then there is a new version (1.14). (3) I received a bug report about multilib conflicts with this package. I previously fixed this (https://bugzilla.redhat.com/342001), but my fix was reverted, apparently by a bad revert commit: https://src.fedoraproject.org/rpms/libdnet/c/224a9645782f69ae05b0e7caeb2e52e12b5655cb?branch=master I would therefore like to include the multilib fix again. Please let me know your thoughts on all this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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
hotplug headphone detection in pipewire? (was: Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change))
I switched a desktop F33 machine from pulseaudio to pipewire and it seems to work fine at a quick glance: $ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing $ systemctl --user enable pipewire pipewire-pulse Now I have the problem when I re-plug my headphones (old-fashioned headphone jack) that I don't see the headphones as output device via "pactl list sinks" (neither via pavucontrol, gnome's audio settings, ...). However the low-level alsa tools can see the headphone jacks (e.g. "alsamixer") and I can use "aplay" to get sound output one the headphone jacks. With pulseaudio I had the same situation but $ pacmd unload-module module-udev-detect && pacmd load-module module-udev-detect fixed the situation for me (though I saw duplicated sinks via pulseaudio for the rest of the session). -> Is there a way to force pipewire to rescan the available sinks? (Ideally there would be auto-detection of course) I guess this is more a support question but I assumed that it might be on topic here as the main goal is to get some testing for pipewire in Fedora :-) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: Deref plugin entries == NULL #4525
Hi William, > It's a scenario we will need to fix via your BE work because of the MVCC transaction model that > LMDB will force us to adopt :) As I see things in the early phases the lmdb read txn will probably only be managed at the db plugin level rather than at backend level. That means that we will have the same inconsistency risk than today (i.e as if using bdb and the implicit txn). The txn model redesign you are speaking about should only occur in one of the last phases (once bdb does no more coexists with lmdb). It must be done because it could provide a serious performance boost for read operations (IMHO, In most cases we could avoid to duplicate the db data) But we should not do it while bdb is still around because of the risk of lock issue and excessive retries. Note I put a phasing section in https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-phase3.html#phasing explaining that. But I guess I should move it within Ludwig's document that englobs it. Pierre On Thu, Jan 14, 2021 at 12:01 AM William Brown wrote: > > > > On 13 Jan 2021, at 21:24, Pierre Rogier wrote: > > > > Thank you Willian, > > So far your scenario (entry found when reading base entry but no more > existing when computing the candidates) is the only one that matches the > symptoms. > > It's a scenario we will need to fix via your BE work because of the MVCC > transaction model that LMDB will force us to adopt :) > > > And that triggered a thought: > > We cannot do anything for SUBTREE and ONE_LEVEL searches > > because the fact that the base entry id is not in the candidate may be > normal > > but IMHO we should improve the BASE search case. > > In this case the candidate list is directly set to the base entry id > > ==> if the candidate entry (in ldbm_back_next_search_entry) is not > found and the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY > error .. > > I suspect that Mark has seen this email and submitted a PR to resolve this > exact case :) > > > > > >Pierre > > > > > > On Wed, Jan 13, 2021 at 1:45 AM William Brown wrote: > > Hey there, > > > > https://github.com/389ds/389-ds-base/pull/4525/files > > > > I had a look and I can see a few possible contributing factors, but > without a core and the exact state I can't be sure if this is correct. It's > all just hypothetical from reading the code. > > > > > > The crash is in deref_do_deref_attr() which is called as part of > deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by > "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb, > SLAPI_PLUGIN_PRE_ENTRY_FN);" > > > > > > I think what's important here is that the search is conducted in > ./ldap/servers/slapd/opshared.c:818 rc = (*be->be_search)(pb); Is *not* > in a transaction. That means that while the single search in be_search() is > consistent due to an implied transaction, the subsequent search in > deref_pre_entry() is likely conducted in a seperate transaction. This > allows for other operations to potentially interleave and cause changes - > modrdn or delete would certainly be candidates to cause a DN to be remove > between these two points. It would be extremely hard to reproduce as a race > condition of course. > > > > > > A question you asked is why don't we get a "no such entry" error or > similar? I think that this is because build_candidate_list in ldbm_search.c > doesn't actually create an error if the base_candidates list is empty, > because an IDL is allocated with a value of 0 (no matching entries). this > allows the search to proceed, and there are no errors, and the result set > is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in > this process, but without looking further into it, my suspicion is that > entries of size 0 WONT return an error condition to internal_search_pb, so > it's valid for this to be empty. > > > > Anyway, again, this is just reading the code for 20 minutes, and is not > a complete in depth investigation, but maybe it's some ideas about what > happened? > > > > Hope it helps :) > > > > > > > > — > > Sincerely, > > > > William Brown > > > > Senior Software Engineer, 389 Directory Server > > SUSE Labs, Australia > > ___ > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org > > > > > > -- > > -- > > > > 389 Directory Server Development Team > > ___ > > 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: >
[Bug 1916153] New: [RFE][EPEL8] Please build perl-IO-Capture for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1916153 Bug ID: 1916153 Summary: [RFE][EPEL8] Please build perl-IO-Capture for EPEL8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-IO-Capture Assignee: spo...@gmail.com Reporter: francois.poiro...@c-s.fr QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Hello, I would like to use perl-IO-Capture on EL8. Could you please branch and build the package for EPEL8? Thank you -- 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: ELN build order
On 14. 01. 21 11:15, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jan 11, 2021 at 09:22:26PM +0100, Fabio Valentini wrote: On Mon, Jan 11, 2021 at 3:57 PM Vít Ondruch wrote: Also, rubygem-eventmachine should be installable after rebuild. But certainly, there might happen race conditions a it happened this time. This reminds me - over a year ago, I triggered discussion about making the dist.rpmdeplint test blocking for all packages, which would solve this exact problem. However, taskotron was retired shortly after, and Fedora CI has only been catching up lately. Is there an installability check in Fedora CI now? Can we make it so that if packages contained in an update do not install correctly the update fails gating checks? Yes, there is: see e.g. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f926ffe2c: fedora-ci.koji-build.tier0.functional fedora-ci.koji-build.installability.functional fedora-ci.koji-build.rpmdeplint.functional fedora-ci.koji-build.compose-ci.static-analysis fedora-ci.koji-build.rpminspect.static-analysis fedora-ci.koji-build.installability.functional would seem like the right thing, but it currently is rather crude: systemd doesn't pass because it has mutually conflicting subpackages (on purpose...). There is no obvious opt-out mechanism, excepting disabling the test as a whole. Hopefully this can be improved to the point where it can be made blocking for all updates. It also report conflicts with the previous version of self: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0b0b2c54db -- 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
pyproject-rpm-macros breaking change: %pyproject_save_files now lists all files explicitly
Hello,
There is an upcoming update to pyproject-rpm-macros-0-34.fc34, fc33 and fc32.
It contains a backwards incompatible change wrt behavior of
%pyproject_save_files:
Previously, when a Python module was a directory, it was listed recursively:
%{python3_sitelib}/foobar/
Now, each file is listed explicitly:
%dir %{python3_sitelib}/foobar
%dir %{python3_sitelib}/foobar/__pycached__
%{python3_sitelib}/foobar/__init__.py
...
This was done to be able to properly list language files and to detect packaging
mistakes.
The list of files is generated from RECORD file:
https://www.python.org/dev/peps/pep-0627/
If you need to manipulate the installed files (rename, move or delete them), try
to do it before building the wheel (e.g. in %prep). If you need to do it after
installing the wheel, using %pyproject_save_files might no longer be possible.
The only affected package in Fedora is:
https://src.fedoraproject.org/rpms/python-matrix-nio/pull-request/1
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: ELN build order
On Mon, Jan 11, 2021 at 09:22:26PM +0100, Fabio Valentini wrote: > On Mon, Jan 11, 2021 at 3:57 PM Vít Ondruch wrote: > > > > Also, rubygem-eventmachine should be installable after rebuild. But > > certainly, there might happen race conditions a it happened this time. > > This reminds me - over a year ago, I triggered discussion about making > the dist.rpmdeplint test blocking for all packages, which would solve > this exact problem. However, taskotron was retired shortly after, and > Fedora CI has only been catching up lately. Is there an installability > check in Fedora CI now? Can we make it so that if packages contained > in an update do not install correctly the update fails gating checks? Yes, there is: see e.g. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f926ffe2c: fedora-ci.koji-build.tier0.functional fedora-ci.koji-build.installability.functional fedora-ci.koji-build.rpmdeplint.functional fedora-ci.koji-build.compose-ci.static-analysis fedora-ci.koji-build.rpminspect.static-analysis fedora-ci.koji-build.installability.functional would seem like the right thing, but it currently is rather crude: systemd doesn't pass because it has mutually conflicting subpackages (on purpose...). There is no obvious opt-out mechanism, excepting disabling the test as a whole. Hopefully this can be improved to the point where it can be made blocking for all updates. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ELN build order
Actually that would not help in this situation, I was talking about Fedora, ELN builds are not planned to be gated .. I stand corrected, thanks @Michal Srb /M On Thu, Jan 14, 2021 at 9:42 AM Miroslav Vadkerti wrote: > Hi, > > can we share the timeline for making rpmdeplint and installability gating > pls? Not sure where we have it. > > Thank you!, > /M > > On Mon, Jan 11, 2021 at 9:23 PM Fabio Valentini > wrote: > >> On Mon, Jan 11, 2021 at 3:57 PM Vít Ondruch wrote: >> > >> > Also, rubygem-eventmachine should be installable after rebuild. But >> certainly, there might happen race conditions a it happened this time. >> >> This reminds me - over a year ago, I triggered discussion about making >> the dist.rpmdeplint test blocking for all packages, which would solve >> this exact problem. However, taskotron was retired shortly after, and >> Fedora CI has only been catching up lately. Is there an installability >> check in Fedora CI now? Can we make it so that if packages contained >> in an update do not install correctly the update fails gating checks? >> >> Fabio >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > > > -- > Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / BaseOS QE / OSCI > IRC mvadkert #tft #baseosci #osci :: GPG 0x7B5B2E95 > TPB-C 2C215 :: Mobile +420 773 944 252 > Red Hat Czech s.r.o, Purkyňova 115, 612 00, Brno, CR > > > -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / BaseOS QE / OSCI IRC mvadkert #tft #baseosci #osci :: GPG 0x7B5B2E95 TPB-C 2C215 :: Mobile +420 773 944 252 Red Hat Czech s.r.o, Purkyňova 115, 612 00, Brno, CR ___ 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Jan 14, 2021, 2:24 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 31.12.2020 13:36, Javier Martinez Canillas wrote: > > I'll update the proposal based on the feedback. > > And what about users, who use Fedora with other GNU/Linux distributions? > These distributions can also switch to the same GRUB2 configuration. > They will all start fighting for the same file. That's why a separate > /boot/efi/EFI/$distro_name/grub.cfg configuration file was introduced. That's Fedora specific. Upstream puts it in /boot/grub/ regardless of firmware. -- Chris Murphy ___ 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 1916075] perl-PPIx-Regexp-0.077 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916075 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PPIx-Regexp-0.077-1.fc ||34 Resolution|--- |RAWHIDE Last Closed||2021-01-14 09:37:09 --- Comment #1 from Petr Pisar --- An enhancement release suitable for Fedora ≥ 34. -- 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: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On 31.12.2020 13:36, Javier Martinez Canillas wrote: I'll update the proposal based on the feedback. And what about users, who use Fedora with other GNU/Linux distributions? These distributions can also switch to the same GRUB2 configuration. They will all start fighting for the same file. That's why a separate /boot/efi/EFI/$distro_name/grub.cfg configuration file was introduced. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: ELN build order
Hi, can we share the timeline for making rpmdeplint and installability gating pls? Not sure where we have it. Thank you!, /M On Mon, Jan 11, 2021 at 9:23 PM Fabio Valentini wrote: > On Mon, Jan 11, 2021 at 3:57 PM Vít Ondruch wrote: > > > > Also, rubygem-eventmachine should be installable after rebuild. But > certainly, there might happen race conditions a it happened this time. > > This reminds me - over a year ago, I triggered discussion about making > the dist.rpmdeplint test blocking for all packages, which would solve > this exact problem. However, taskotron was retired shortly after, and > Fedora CI has only been catching up lately. Is there an installability > check in Fedora CI now? Can we make it so that if packages contained > in an update do not install correctly the update fails gating checks? > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / BaseOS QE / OSCI IRC mvadkert #tft #baseosci #osci :: GPG 0x7B5B2E95 TPB-C 2C215 :: Mobile +420 773 944 252 Red Hat Czech s.r.o, Purkyňova 115, 612 00, Brno, CR ___ 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: Migrating the Fedora Developer Portal to Fedora Docs
On Wed, Jan 13, 2021 13:45:23 -0800, Kevin Fenzi wrote: > > > I'm in favor if you can convince them to do it. ;) Let's see how it goes :D Incidentally: who am I convincing? The wiki page doesn't list any names[1]. Is there a SIG or a team that maintains this? Would this fall under Websites (or Mindshare or CommOps or Infra?) since it doesn't seem to fall under Docs. [1] https://fedoraproject.org/wiki/Websites/Developer#About_The_Project -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 virt-install + ks has some problem switching root
Hi, > An additional problem is I cannot find any way to debug the problem. > Something (systemd? dracut?) asks for a root password in order to get > to the emergency shell, and I can find no way around this nor any > password which works. I wish there was a "stop asking for a password" > option on the kernel command line. Trapped into the same thing a few days ago. dracut uses sulogin now. Run dracut with --no-hostonly. Adding dracut-config-generic to the kickstart package list should have the same effect (not tested though). That'll disable the root login in the initramfs and sulogin gives you a shell when you tap enter. HTH, Gerd ___ 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 1916075] perl-PPIx-Regexp-0.077 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916075 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
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Jan 14, 2021 at 12:35 AM Guido Aulisi wrote: > IMHO boot loaders should not write to filesystems, if this is needed to > hide the GRUB menu when boot is successful, then let's display it > always as it was one time. I don't think it we should follow Windows or > MacOS style here, the boot menu is useful. It's an old design predicated on FAT and ext2. That design is outgrown. That's all. > Yet another partition needed to boot the OS. What when there are no > available paritions in BIOS mode, because other OSes used all the > available 4 partitions? GRUB can read EBRs. For bootloaders that don't understand EBR, they'll need to stick to the simple ways they're doing things already. -- Chris Murphy ___ 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 1915891] perl-Module-ScanDeps-1.30 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1915891 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Module-ScanDeps-1.30-1 ||.fc34 Resolution|--- |RAWHIDE Last Closed||2021-01-14 08:08:12 -- 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
