date:20201117

Fedora-Cloud-33-20201118.0 compose check report

2020-11-17 Thread Fedora compose checker

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20201117.0):

ID: 724374  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/724374
ID: 724381  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/724381

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Announcement: orphaning java-comment-preprocessor

2020-11-17 Thread Ondrej Dubaj

Hello,

orphaning java-comment-preprocessor due to missing dependencies for the new
version (cannot be rebased) and no other package dependents on it.

Regards,

Ondrej
___
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 1898610] perl-Convert-Binary-C-0.80 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1898610

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|al...@users.sourceforge.net |
   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

Fedora-Rawhide-20201117.n.0 compose check report

2020-11-17 Thread Fedora compose checker

Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 9/177 (x86_64), 14/115 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20201116.n.0):

ID: 724111  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/724111
ID: 724189  Test: aarch64 Server-dvd-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/724189
ID: 724198  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/724198
ID: 724288  Test: x86_64 universal install_blivet_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/724288
ID: 724317  Test: aarch64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/724317
ID: 724337  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/724337

Old failures (same test failed in Fedora-Rawhide-20201116.n.0):

ID: 724123  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/724123
ID: 724130  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/724130
ID: 724131  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/724131
ID: 724133  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/724133
ID: 724172  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/724172
ID: 724175  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/724175
ID: 724207  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/724207
ID: 724253  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/724253
ID: 724308  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/724308
ID: 724320  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/724320
ID: 724333  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/724333
ID: 724357  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/724357
ID: 724360  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/724360
ID: 724362  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/724362
ID: 724364  Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/724364
ID: 724366  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/724366
ID: 724367  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/724367

Soft failed openQA tests: 9/177 (x86_64), 3/115 (aarch64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20201116.n.0):

ID: 724059  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/724059
ID: 724091  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/724091

Old soft failures (same test soft failed in Fedora-Rawhide-20201116.n.0):

ID: 724105  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/724105
ID: 724155  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/724155
ID: 724223  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/724223
ID: 724232  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/724232
ID: 724246  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/724246
ID: 724270  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/724270
ID: 724271  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/724271
ID: 724291  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/724291
ID: 724316  Test: aarch64 universal upgrade_2_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/724316
ID: 724334  Test: aarch64 universal upgrade_2_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/724334

Passed openQA tests: 159/177 (x86_64), 98/115 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20201116.n.0):

ID: 724060  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL:

[EPEL-devel] Fedora EPEL 6 updates-testing report

2020-11-17 Thread updates

The following builds have been pushed to Fedora EPEL 6 updates-testing

munin-2.0.65-1.el6

Details about builds:



 munin-2.0.65-1.el6 (FEDORA-EPEL-2020-fdb79d0ad2)
 Network-wide resource monitoring tool

Update Information:

Upstream update to 2.0.65. Also fixes log file owners and plugin-state directory
owner.

ChangeLog:

* Tue Nov 17 2020 Kim B. Heino  - 2.0.65-1
- Upgrade to 2.0.65
- Improve plugin-state directory owners
- Don't require tmpwatch
- Change log file owner to root:adm or munin:adm
* Tue Jul 28 2020 Fedora Release Engineering  - 
2.0.63-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild


___
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 1851872] Wrong tag in comment line of DKIM record: 'i=' should be 's='

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1851872

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-ca1ac5519e has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ca1ac5519e

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

[Bug 1890417] amavisd-new-snmp can't be installed on EL8 because of dropped net-snmp-perl

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1890417

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-ca1ac5519e has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ca1ac5519e

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

2020-11-17 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2aa68c5f5e   
tor-0.4.3.7-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-317c124dc0   
rpki-client-6.8p1-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c93c61069   
pngcheck-2.4.0-2.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b3000c1eea   
seamonkey-2.53.5-2.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5b5debb24b   
chromium-86.0.4240.198-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

amavis-2.12.1-3.el8
munin-2.0.65-1.el8
perl-Fsdb-2.71-1.el8

Details about builds:



 amavis-2.12.1-3.el8 (FEDORA-EPEL-2020-ca1ac5519e)
 Email filter with virus scanner and spamassassin support

Update Information:

Update to version 2.12.1 and disable snmp subpackage in epel8

ChangeLog:

* Tue Nov 17 2020 Juan Orti Alcaine  - 2.12.1-3
- Change ports in configuration file and add a note about SELinux (#1891003)
* Tue Nov 17 2020 Juan Orti Alcaine  - 2.12.1-2
- Disable snmp subpackage in epel8
* Tue Nov 17 2020 Juan Orti Alcaine  - 2.12.1-1
- Version 2.12.1 (#1897574 #1851872)

References:

  [ 1 ] Bug #1851872 - Wrong tag in comment line of DKIM record: 'i=' should be 
's='
https://bugzilla.redhat.com/show_bug.cgi?id=1851872
  [ 2 ] Bug #1890417 - amavisd-new-snmp can't be installed on EL8 because of 
dropped net-snmp-perl
https://bugzilla.redhat.com/show_bug.cgi?id=1890417
  [ 3 ] Bug #1891003 - default configuration example for ORIGINATING related to 
ports is blocked by SELinux
https://bugzilla.redhat.com/show_bug.cgi?id=1891003




 munin-2.0.65-1.el8 (FEDORA-EPEL-2020-3aa0f92497)
 Network-wide resource monitoring tool

Update Information:

Upstream update to 2.0.65. Also fixes log file owners and plugin-state directory
owner.

ChangeLog:

* Tue Nov 17 2020 Kim B. Heino  - 2.0.65-1
- Upgrade to 2.0.65
- Improve plugin-state directory owners
- Don't require tmpwatch
- Change log file owner to root:adm or munin:adm
* Tue Jul 28 2020 Fedora Release Engineering  - 
2.0.63-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 perl-Fsdb-2.71-1.el8 (FEDORA-EPEL-2020-dc56dfce78)
 A set of commands for manipulating flat-text databases from the shell

Update Information:

Some small quality-of-life enhancements and corner-case bugfixes.

ChangeLog:

* Mon Nov 16 2020 John Heidemann  2.71-1
- See http://www.isi.edu/~johnh/SOFTWARE/FSDB/


___
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

[EPEL-devel] Fedora EPEL 7 updates-testing report

2020-11-17 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d69636a383   
tor-0.3.5.12-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0fe15b3c39   
rpki-client-6.8p1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-339db397ad   
pngcheck-2.4.0-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-62ef58ec56   
openssl11-1.1.1g-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-46fc6c7982   
seamonkey-2.53.5-2.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3097b2d5db   
chromium-86.0.4240.198-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

munin-2.0.65-1.el7
perl-Fsdb-2.71-1.el7
prewikka-updatedb-5.2.0-1.el7

Details about builds:



 munin-2.0.65-1.el7 (FEDORA-EPEL-2020-12c32f3949)
 Network-wide resource monitoring tool

Update Information:

Upstream update to 2.0.65. Also fixes log file owners and plugin-state directory
owner.

ChangeLog:

* Tue Nov 17 2020 Kim B. Heino  - 2.0.65-1
- Upgrade to 2.0.65
- Improve plugin-state directory owners
- Don't require tmpwatch
- Change log file owner to root:adm or munin:adm
* Tue Jul 28 2020 Fedora Release Engineering  - 
2.0.63-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 perl-Fsdb-2.71-1.el7 (FEDORA-EPEL-2020-9f2fc742ae)
 A set of commands for manipulating flat-text databases from the shell

Update Information:

Some small quality-of-life enhancements and corner-case bugfixes.

ChangeLog:

* Mon Nov 16 2020 John Heidemann  2.71-1
- See http://www.isi.edu/~johnh/SOFTWARE/FSDB/




 prewikka-updatedb-5.2.0-1.el7 (FEDORA-EPEL-2020-e652281cc9)
 Database update scripts for prewikka

Update Information:

New package to update prewikka versions

ChangeLog:



___
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 1895633] perl-perlfaq-5.20201107 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1895633

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-perlfaq-5.20201107-1.f |perl-perlfaq-5.20201107-1.f
   |c34 |c34
   |perl-perlfaq-5.20201107-1.f |perl-perlfaq-5.20201107-1.f
   |c33 |c33
   |perl-perlfaq-5.20201107-1.f |perl-perlfaq-5.20201107-1.f
   |c32 |c32
   ||perl-perlfaq-5.20201107-1.f
   ||c31



--- Comment #22 from Fedora Update System  ---
FEDORA-2020-5f8dda5fde has been pushed to the Fedora 31 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 1895538] perl-DateTime-TimeZone-2.44 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1895538

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTime-TimeZone-2.44 |perl-DateTime-TimeZone-2.44
   |-1.fc34 |-1.fc34
   |perl-DateTime-TimeZone-2.44 |perl-DateTime-TimeZone-2.44
   |-1.fc32 |-1.fc32
   ||perl-DateTime-TimeZone-2.44
   ||-1.fc31



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-593f249a0b has been pushed to the Fedora 31 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 1895633] perl-perlfaq-5.20201107 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1895633

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-perlfaq-5.20201107-1.f |perl-perlfaq-5.20201107-1.f
   |c34 |c34
   |perl-perlfaq-5.20201107-1.f |perl-perlfaq-5.20201107-1.f
   |c33 |c33
   ||perl-perlfaq-5.20201107-1.f
   ||c32



--- Comment #21 from Fedora Update System  ---
FEDORA-2020-0bce4b6d8d has been pushed to the Fedora 32 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 1895538] perl-DateTime-TimeZone-2.44 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1895538

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DateTime-TimeZone-2.44 |perl-DateTime-TimeZone-2.44
   |-1.fc34 |-1.fc34
   ||perl-DateTime-TimeZone-2.44
   ||-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-11-18 02:36:12



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-88e8dda220 has been pushed to the Fedora 32 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

[Heads up] Rubberband bugfix update

2020-11-17 Thread Michel Alexandre Salim

Dear maintainers,

I've built updates bringing Rubberband to version 1.9.0:
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2020-378d450ffb
F32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3ca9c95c2
EPEL8:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3d4e57454b

It's a bugfix release, most significantly:

Fix incorrect numbering of pitch speed/quality flags in the auxiliary C
wrapper header. The effect of this was that code using the C wrapper
that intended to select the higher-quality pitch-shift mode was
actually choosing the higher-speed mode, and vice versa. (The third
mode - high-consistency, commonly used in real-time applications - was
correct.)

The API and ABI are unchanged and I verified that at least sonic-
visualiser continued to work. You might want to rebuild if the
incorrect numbering bug affects your package though.

$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
rubberband-devel
ardour5-0:5.12.0-19.fc33.src
ardour6-0:6.3.0-1.fc34.src
denemo-0:2.4.0-2.fc33.src
qtractor-0:0.9.10-4.fc33.src
sonic-visualiser-0:4.2-1.fc34.src
sooperlooper-0:1.7.3-15.fc33.src

I've created overrides for the updates, they should be ready to use
momentarily.

Best,

-- 
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 1895729] perl-Devel-PatchPerl-2.02 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1895729

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Devel-PatchPerl-2.02-1 |perl-Devel-PatchPerl-2.02-1
   |.fc34   |.fc34
   ||perl-Devel-PatchPerl-2.02-1
   ||.fc33
 Resolution|--- |ERRATA
Last Closed||2020-11-18 02:19:28



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-0ffe800f07 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 1895672] perl-Test-Dependencies-0.30 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1895672

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Test-Dependencies-0.30 |perl-Test-Dependencies-0.30
   |-1.fc34 |-1.fc34
   ||perl-Test-Dependencies-0.30
   ||-1.fc33
 Resolution|--- |ERRATA
Last Closed||2020-11-18 02:19:23



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-7021e7bc67 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 1895633] perl-perlfaq-5.20201107 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1895633

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-perlfaq-5.20201107-1.f |perl-perlfaq-5.20201107-1.f
   |c34 |c34
   ||perl-perlfaq-5.20201107-1.f
   ||c33
 Resolution|--- |ERRATA
Last Closed||2020-11-18 02:19:19



--- Comment #20 from Fedora Update System  ---
FEDORA-2020-e33a01e36d 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 1890589] EPEL8 Request: perl-Config-GitLike

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1890589
Bug 1890589 depends on bug 1893497, which changed state.

Bug 1893497 Summary: RFE - build a perl-Module-Install-ExtraTests package for 
EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1893497

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1893497] RFE - build a perl-Module-Install-ExtraTests package for EPEL8

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1893497

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Module-Install-ExtraTe
   ||sts-0.008-23.el8
 Resolution|--- |ERRATA
Last Closed||2020-11-18 01:25:39



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-82e06a230d has been pushed to the Fedora EPEL 8 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

Fedora rawhide compose report: 20201117.n.0 changes

2020-11-17 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20201116.n.0
NEW: Fedora-Rawhide-20201117.n.0

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  15
Dropped packages:0
Upgraded packages:   83
Downgraded packages: 0

Size of added packages:  18.36 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.50 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   74.70 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201117.n.0.iso
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20201117.n.0.ppc64le.qcow2
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20201117.n.0.ppc64le.raw.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20201117.n.0.ppc64le.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-d5-tengo-2-2.6.1-1.fc34
Summary: Fast script language for Go
RPMs:golang-github-d5-tengo-2 golang-github-d5-tengo-2-devel
Size:6.04 MiB

Package: golang-github-projectdiscovery-fdmax-0.0.2-2.fc34
Summary: Helper Library to increase automatically the file descriptors
RPMs:golang-github-projectdiscovery-fdmax-devel
Size:10.35 KiB

Package: golang-github-projectdiscovery-mapcidr-0.0.4-1.fc34
Summary: Utility for operations on subnet/CIDR ranges
RPMs:golang-github-projectdiscovery-mapcidr 
golang-github-projectdiscovery-mapcidr-devel
Size:3.46 MiB

Package: golang-github-projectdiscovery-rawhttp-0-0.1.20201116git8a8a0ce.fc34
Summary: Raw HTTP client in Go
RPMs:golang-github-projectdiscovery-rawhttp-devel
Size:27.07 KiB

Package: golang-github-vbauerster-mpb-5-5.3.0-2.fc34
Summary: Multi progress bar for Go CLI applications
RPMs:golang-github-vbauerster-mpb-5-devel
Size:52.73 KiB

Package: golang-github-yl2chen-cidranger-1.0.2-1.fc34
Summary: Fast IP to CIDR lookup in Golang
RPMs:golang-github-yl2chen-cidranger-devel
Size:25.65 KiB

Package: hakrevdns-0-0.1.20201116git9fa2d59.fc34
Summary: Tool for performing reverse DNS lookups
RPMs:golang-github-hakluke-hakrevdns-devel hakrevdns
Size:4.27 MiB

Package: netscanner-0-0.1.20201116git8baab36.fc34
Summary: TCP/UDP scanner to find open or closed ports
RPMs:golang-github-r4ygm-netscanner-devel netscanner
Size:3.90 MiB

Package: python-aioitertools-0.7.0-1.fc34
Summary: Itertools and builtins for AsyncIO and mixed iterables
RPMs:python3-aioitertools
Size:45.86 KiB

Package: python-aiolifx-0.6.8-1.fc34
Summary: Python API for local communication with LIFX devices
RPMs:python3-aiolifx
Size:49.49 KiB

Package: python-aiomodbus-0.3.2-1.fc34
Summary: Lightweight Python Modbus library
RPMs:python3-aiomodbus
Size:26.45 KiB

Package: python-aiosecretsdump-0.0.2-1.fc34
Summary: Secrets dumper
RPMs:python3-aiosecretsdump
Size:28.10 KiB

Package: python-poetry-core-1.0.0-1.fc34
Summary: Poetry PEP 517 Build Backend
RPMs:python3-poetry-core
Size:164.20 KiB

Package: python-policyuniverse-1.3.2.20201012-1.fc34
Summary: Parse and process AWS IAM policies, statements, ARNs and wildcards
RPMs:python3-policyuniverse
Size:224.92 KiB

Package: rust-crypto-mac0.8-0.8.0-1.fc34
Summary: Trait for Message Authentication Code (MAC) algorithms
RPMs:rust-crypto-mac0.8+blobby-devel rust-crypto-mac0.8+default-devel 
rust-crypto-mac0.8+dev-devel rust-crypto-mac0.8+std-devel 
rust-crypto-mac0.8-devel
Size:46.60 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  CGAL-5.1.1-1.fc34
Old package:  CGAL-5.1-1.fc34
Summary:  Computational Geometry Algorithms Library
RPMs: CGAL-demos-source CGAL-devel CGAL-qt5-devel
Size: 117.83 MiB
Size change:  -18.87 KiB
Changelog:
  * Mon Nov 16 2020 Laurent Rineau  - 5.1.1-1
  - New upstream release


Package:  GMT-6.1.1-2.fc34
Old package:  GMT-6.1.1-1.fc34
Summary:  Generic Mapping Tools
RPMs: GMT GMT-common GMT-devel GMT-doc
Size: 65.63 MiB
Size change:  -13.56 KiB
Changelog:
  * Mon Nov 16 2020 Orion Poplawski  - 6.1.1-2
  - Rebuild for gdal 3.2.0


Package:  Lmod-8.4.15-1.fc34
Old package:  Lmod-8.4.11-1.fc34
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.07 MiB
Size change:  2.97 KiB
Changelog:
  * Mon Nov 16 2020 Orion Poplawski  - 8.4.15-1
  - Update to 8.4.15


Package:  alt-ergo-2.2.0-6.fc34
Old package:  alt-ergo-2.2.0-5.fc34
Summary:  Automated theorem prover including linear arithmetic
RPMs: alt-ergo alt-ergo-gui ocaml-alt-ergo ocaml-alt-ergo-devel
Size: 75.13 MiB
Size change:  -138.05 KiB
Changelog:
  * Mon Nov 16 2020 Jerry James  - 2.2.0-6
  - Rebuild for ocaml-zarith 1.11


Package:  amsynth-1.12.1-1.fc34
Old package:  amsynth-1.11.0-1.fc34
Summary:  A classic

Fedora-IoT-33-20201117.0 compose check report

2020-11-17 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 1/16 (x86_64), 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-33-20201114.0):

ID: 723973  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/723973
ID: 723989  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/723989

Passed openQA tests: 14/15 (aarch64), 15/16 (x86_64)

New passes (same test not passed in Fedora-IoT-33-20201114.0):

ID: 723999  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/723999
ID: 724003  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/724003

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.41 to 0.18
Previous test data: https://openqa.fedoraproject.org/tests/722261#downloads
Current test data: https://openqa.fedoraproject.org/tests/723990#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: Unable to disable SysRq

2020-11-17 Thread Matthew Miller

On Tue, Nov 17, 2020 at 04:08:19PM +0100, Vitaly Zaitsev via devel wrote:
> That's why all user-space "OOM killers" must have the following
> lines in their .service files:
> 
> DynamicUser=true
> AmbientCapabilities=CAP_KILL CAP_IPC_LOCK
> ProtectSystem=strict
> ProtectHome=true
> 
> I think FESCo should create a special policy for such preinstalled
> by default daemons. Running them as root is too dangerous.

See https://pagure.io/fesco/issue/1663 and the linked FPC ticket. I'm not
sure if that draft ever made it officially into the guidelines?

-- 
Matthew Miller

Fedora Project Leader
___
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 - Jason Edgecombe

2020-11-17 Thread Matthew Miller

On Sun, Nov 15, 2020 at 07:12:53PM -0500, Jason Edgecombe wrote:
> I'm a Linux admin at a university supporting  around 100+ EL7/8 and Ubuntu
> machines. I've been using Linux as a hobby since around 1994 and
> professionally  since 1999. My first Linux experience was installing
> Slackware from floppies on a computer with a 486DX processor (The
> predecessor to the Pentium chip)

Wow, that's old-school. Awesome!

> In my personal time, I'm learning a little about fedora packaging in order
> to build some Fedora packages on RHEL8/CENTOS8 for my personal use. I'm
> somewhat familiar with RPM spec files and building RPMs.

That's great! What packages are you interested in in particular? Once you
feel comfortable with them, you might consider creating a COPR
https://copr.fedorainfracloud.org/ to share your work, and from there
perhaps getting them to be official packages.


-- 
Matthew Miller

Fedora Project Leader
___
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 1898691] perl-Tk-GraphViz-1.07 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1898691



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Tk-GraphViz-1.07-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=55761353


-- 
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 1898691] New: perl-Tk-GraphViz-1.07 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1898691

Bug ID: 1898691
   Summary: perl-Tk-GraphViz-1.07 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Tk-GraphViz
  Keywords: FutureFeature, Triaged
  Assignee: lkund...@v3.sk
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: fi...@andresovi.net, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org, sce...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.07
Current version/release in rawhide: 1.06-1.fc34
URL: http://search.cpan.org/dist/Tk-GraphViz/

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/3476/


-- 
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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-17 Thread Robbie Harwood

Vitaly Zaitsev via devel  writes:

> On 17.11.2020 18:45, Robbie Harwood wrote:
>> Just because it's easier not to follow expected process doesn't mean
>> they shouldn't.
>
> Patching packages by proven packages is a completely normal workflow.

Something being normal doesn't mean it's good.

>> If waiting too long is a problem, set a timeout - send a PR, if it's
>> not merged in two weeks then provenpackager it in.
>
> Waiting for 2 weeks is too much, IMO.

Consider making less urgent changes, then.  Provenpackager policy says
that you should check with maintainers before applying patches.

Thanks,
--Robbie


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

Schedule for Wednesday's FESCo Meeting (2020-11-18)

2020-11-17 Thread Zbigniew Jędrzejewski-Szmek

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-11-18 15:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2498 F34 Self-Contained Change: AArch64 KDE Plasma Desktop image
https://pagure.io/fesco/issue/2498
APPROVED (+3, 0, 0)

#2497 Nonresponsive maintainer: Pavel Kajaba pkajaba
https://pagure.io/fesco/issue/2497
APPROVED (+3, 0, 0)

= Followups =

#topic #2473 updates policy is out of date 
https://pagure.io/fesco/issue/2473

#topic #2475 proposal: let's develop the idea of a new repo for 
lightly-maintained packages
https://pagure.io/fesco/issue/2475

= New business =

#topic #2501 F34 System-Wide Change: Remove and deprecate nscd in favour of 
sssd and systemd-resolved
https://pagure.io/fesco/issue/2501

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
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: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)

2020-11-17 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Nov 05, 2020 at 02:06:37PM +0100, Michal Schorm wrote:
> On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini  wrote:
> > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton  wrote:
> > > == Contingency Plan ==
> > >
> > > Modules will provide the functional version of MariaDB 10.4, available to 
> > > all users.
> > > * Contingency mechanism: Fedora Modules for 10.4 available
> >
> > This is not a sufficient contingency plan. Leaving broken 10.5
> > non-modular packages in f34 is a non-starter.
> >
> > Is there a realistic path to back out of the 10.5 update in rawhide /
> > F34 if there are problems?
> > It looks like the 10.4 -> 10.5 update requires database upgrades as
> > well, so would MariaDB 10.4 have problems with accessing databases
> > that have been migrated to 10.5?
> 
> In the worst case scenario, I would be forced to revert the change,
> bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4
> instead.
> 
> Database upgrades in general (this is not just about MariaDB or MySQL)
> are very problematic.
> Every sane DB upgrade *ever* should have a data backup prior and I
> don't want, nor have any means to, solve the cases of corrupted DB
> data which haven't got a backup.
> 
> What would be an issue however, if a significant number of users would
> report the upgrade is problematic and they can't use the DB with the
> new version.
> The best thing both they and I can do is to file a BZ ticket (so we
> are informed about it in the first place).
> I will search the upstream JIRA ticket system for workarounds as a
> part of the problem solving.
> If any are found, I'd try to apply them or at least provide them to the users.
> 
> If the issues would be in place but no solution in sight, the revert
> to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to
> go.
> 
> If you will agree to this contingency mechanism, I will add it to the
> Self-Contained Change wiki page.
> Otherwise I'd ask you for a suggestion of what you picture as
> sufficient contingency mechanism.

So, any progress on this?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-17 Thread Richard Shaw

On Tue, Nov 17, 2020 at 12:43 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 17.11.2020 09:46, Felix Schwarz wrote:
> > I think this is the root cause and a real problem (I complained about
> > this myself several few times on this list).
>
> Yes, ofc. I've submitted multiple PRs. Some of them haven't been merged.
> Later I got these packages through the Non-responsive maintainer
> procedure, manually merged the PRs and pushed to updates.
>
> > Instead we should start thinking about ways to actually fix the root
> cause problem (and also how to integrate Fedora packaging much better with
> actual users, hopefully "converting" some users into packagers).
>
> I think it will be very difficult. Many maintainers simply don't have
> enough free time and their packages haven't been updated for ages. They
> also don't check email and never accept pull requests.
>

Radical and likely overkill idea...

Require CLAs be renewed annually. If they don't respond within a certain
amount of time, the non-responsive maintainer process is automatically
initiated (or another process/workflow that doesn't yet exist).

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Stratis 2.2.0 (Self-Contained Change)

2020-11-17 Thread Dennis Keefe

Good feedback.  I'll adjust the document to integrate your suggestions. 
___
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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-17 Thread Vitaly Zaitsev via devel


On 17.11.2020 09:46, Felix Schwarz wrote:
I think this is the root cause and a real problem (I complained about 
this myself several few times on this list).


Yes, ofc. I've submitted multiple PRs. Some of them haven't been merged. 
Later I got these packages through the Non-responsive maintainer 
procedure, manually merged the PRs and pushed to updates.


Instead we should start thinking about ways to actually fix the root cause problem (and also how to integrate Fedora packaging much better with actual users, hopefully "converting" some users into packagers). 


I think it will be very difficult. Many maintainers simply don't have 
enough free time and their packages haven't been updated for ages. They 
also don't check email and never accept pull requests.


--
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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-17 Thread Vitaly Zaitsev via devel


On 17.11.2020 18:45, Robbie Harwood wrote:

Just because it's easier not to follow expected process doesn't mean
they shouldn't.


Patching packages by proven packages is a completely normal workflow.


If waiting too long is a problem, set a timeout - send a PR, if it's not
merged in two weeks then provenpackager it in.


Waiting for 2 weeks is too much, IMO.

--
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: Summary/Minutes from today's FESCo Meeting (2020-11-11)

2020-11-17 Thread Robbie Harwood

Matthew Miller  writes:

> On Fri, Nov 13, 2020 at 10:52:57PM +0100, Kevin Kofler via devel wrote:
>> > I completely agree. This is one of the reasons I switched away from
>> > ubuntu years ago (with its 4 (?) tiers of support + repos for its
>> > packages ...).
>> I agree, Fedora did the Core-Extras Merge back in the day for a reason.
>
> That reason was _mainly_ to erase the inside Red Hat,
> community-around-the-edges distinction. That was a huge success and Fedora
> wouldn't be interesting without that. But I think the _technical_ choice was
> in retrospect a mistake. There's a reason RHEL 8 switched the _other_ way.

Respectfully, I don't agree with that.  From a technical perspective,
the splitting of RHEL into many repos is awful to work with, and there
was no reason to suppose it would be otherwise.

Suppose I depend on a package.  That package could now come from any of
the following repositories (assuming I haven't forgotten any):

- AppStream
- BaseOS
- CRB
- BuildRoot
- EPEL

And that's just for me building things in BaseOS + AppStream, not even
any layered products.  For me internally, these repos are all nearby,
but what if I weren't?  Some come from Red Hat, some from CentOS, EPEL
(and ELN) from Fedora, ...

This is painful to work with; I just need my package to build.  From a
technical perspective, we need to consider the time lost due to trying
to configure machines and testing environments with the right repos,
the impossibility of figuring out what repo a package actually is
shipped in [1] (if it even is), etc..

And that doesn't even get into modularity - where there's another layer
of package non-discoverability.

Also RHEL/EPEL policy currently means that "hidden" packages in RHEL
can't be exposed in EPEL - because that would be repackaging them.

In summary, from a technical perspective, this is an unwieldy mess.
Nothing is gained from the packager's point of view or the end user's
point of view.  The gains [2] are in the lifecycle and support realms -
firmly in business, not technical.

So: no new repo splits please.  The only distinction we should care
about is "Fedora" and "not Fedora", in my view - keep it simple and
approachable.

Thanks,
--Robbie

1: This is an issue with RHEL tools, in my view.
2: I contend that hiding packages doesn't actually reduce support
   burden, just hides it, but that's orthogonal to the conversation.

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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-17 Thread Robbie Harwood

Vitaly Zaitsev via devel  writes:

> On 16.11.2020 13:35, Felix Schwarz wrote:
>> The only point (though important imho) I want to make is that 
>> provenpackagers should not "circumvent" the package maintainer by 
>> default - even though I can imagine it is way faster just to push your 
>> change.
>
> Most of casual packagers simply ignore all pull requests and don't even 
> check their mail. It is much more easier to fix the package manually 
> than waiting 2-3 weeks for a response.

Just because it's easier not to follow expected process doesn't mean
they shouldn't.

If waiting too long is a problem, set a timeout - send a PR, if it's not
merged in two weeks then provenpackager it in.

And if your change requires touching enough packages that this is
untenable, I urge you to seriously rethink whether it's worth doing.
(Spec file cleanups generally aren't, for instance.)

Thanks,
--Robbie

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 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-17 Thread przemek klosowski via devel



On 11/17/20 4:24 AM, Lennart Poettering wrote:

dig @9.9.9.9 +nsid heise.de


FWIW, a neat way to look at differences like that is

    watch -d dig @9.9.9.9 +nsid heise.de

I use it often for looking at hotplugs (watch -d lsusb) etc.

___
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 1851872] Wrong tag in comment line of DKIM record: 'i=' should be 's='

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1851872

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-ca1ac5519e has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ca1ac5519e


-- 
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: AAC-Main patent expiration

2020-11-17 Thread Peter Lemenkov

We do have FDK-AAC-Free imported for a while. Some functionality was
patched out due to various concerns:

*https://src.fedoraproject.org/rpms/fdk-aac-free
* https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=fedora

вт, 17 нояб. 2020 г. в 16:42, Igor Bukanov :
>
> AAC-Main audio encoder/decoder profile was specified as a part of  
> https://www.iso.org/standard/25035.html standard. That was published in 
> December 1999. Does it mean that software implementing it like ffmpeg in its 
> default configuration can be included into Fedora starting from January 2021?
>
> Regards, Igor
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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: AAC-Main patent expiration

2020-11-17 Thread Neal Gompa

On Tue, Nov 17, 2020 at 10:42 AM Igor Bukanov  wrote:
>
> AAC-Main audio encoder/decoder profile was specified as a part of  
> https://www.iso.org/standard/25035.html standard. That was published in 
> December 1999. Does it mean that software implementing it like ffmpeg in its 
> default configuration can be included into Fedora starting from January 2021?
>

This is not a question anyone can answer, especially not on an open
forum. However, there is already an unencumbered subset of AAC
available in Fedora: https://src.fedoraproject.org/rpms/fdk-aac-free


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1898610] New: perl-Convert-Binary-C-0.80 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1898610

Bug ID: 1898610
   Summary: perl-Convert-Binary-C-0.80 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Convert-Binary-C
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@users.sourceforge.net, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.80
Current version/release in rawhide: 0.79-3.fc33
URL: http://search.cpan.org/dist/Convert-Binary-C/

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/7067/


-- 
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

AAC-Main patent expiration

2020-11-17 Thread Igor Bukanov

AAC-Main audio encoder/decoder profile was specified as a part of  
https://www.iso.org/standard/25035.html standard. That was published in 
December 1999. Does it mean that software implementing it like ffmpeg in its 
default configuration can be included into Fedora starting from January 2021?

Regards, Igor 
___
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: NEEDINFO nag 2 days after bug creation?

2020-11-17 Thread Richard Shaw

On Mon, Nov 16, 2020 at 5:10 PM Miro Hrončok  wrote:

> On 11/16/20 11:31 PM, Richard Shaw wrote:
> > The logic behind the NEEDINFO stuff may need to be updated... The
> subject says
> > it all and it's quite annoying.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1897496
> > 
>
> The script runs every 3 weeks, on a Sunday. Sometimes, this happens to be
> right
> after the bug was opened. Sorry about that.
>
> Sure, we *should* adapt that script to check the creation date of the bug.
> The
> script is here if you are interested to take a look:
>

Now that I know that, it's not as big of a deal but yeah, it would be good
to check the BZ creation date, then I would say it should probably run
every week (assuming it's not run more frequently due to resource usage.)


https://pagure.io/releng/blob/master/f/scripts/ftbfs_weekly_reminder.py


I may take a look but $DAYJOB is insane right now and my Python programming
days ended a long time ago :)

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unable to disable SysRq

2020-11-17 Thread Vitaly Zaitsev via devel


On 17.11.2020 13:26, Robert Marcano via devel wrote:
User d9k on IRC found the culprit. It is low-memory-monitor. The latest 
commit [1] for it tries to not mess with the value with 1 is set, but it 
should not mess with it ever.


That's why all user-space "OOM killers" must have the following lines in 
their .service files:


DynamicUser=true
AmbientCapabilities=CAP_KILL CAP_IPC_LOCK
ProtectSystem=strict
ProtectHome=true

I think FESCo should create a special policy for such preinstalled by 
default daemons. Running them as root is too dangerous.


Earlier, in cooperation with the upstream, we fixed the earlyoom daemon. 
It has no root access to the system and can only kill processes using 
ambient capabilities.


--
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

[Bug 1898583] perl-Algorithm-CheckDigits-1.3.4 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1898583



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Algorithm-CheckDigits-1.3.4-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=55749188


-- 
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 1898583] New: perl-Algorithm-CheckDigits-1.3.4 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1898583

Bug ID: 1898583
   Summary: perl-Algorithm-CheckDigits-1.3.4 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Algorithm-CheckDigits
  Keywords: FutureFeature, Triaged
  Assignee: xav...@bachelot.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.3.4
Current version/release in rawhide: 1.3.3-2.fc33
URL: http://search.cpan.org/dist/Algorithm-CheckDigits/

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/2623/


-- 
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 1898583] perl-Algorithm-CheckDigits-1.3.4 is available

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1898583



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1730160
  --> https://bugzilla.redhat.com/attachment.cgi?id=1730160=edit
[patch] Update to 1.3.4 (#1898583)


-- 
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: Looking for sponsorship to be a package maintainer

2020-11-17 Thread Isaac True

Hi Mattia,

The package has now been reviewed and approved:

https://bugzilla.redhat.com/show_bug.cgi?id=1894726

I haven't had any offers for sponsorship on the mailing list so I'll try 
posting an issue on "packager-sponsors."

Cheers,
Isaac

‐‐‐ Original Message ‐‐‐

On Wednesday, November 4th, 2020 at 18:31, Mattia Verga via devel 
 wrote:

> Il 02/11/20 23:19, Isaac True ha scritto:
>
> > Hello all,
> >
> > I'm hoping to become the maintainer of an orphaned package (gr-iio,
> >
> > GNU Radio blocks for Analog Devices platforms) but I need some
> >
> > sponsorship to become a package maintainer. The releng team
> >
> > recommended that I send a message on this list to hopefully find someone.
> >
> > I'm a software engineer and I've built a few .rpm's and .deb's over
> >
> > the years, so I'm already pretty capable at putting together a
> >
> > package. I would love for the opportunity to give back to the Fedora
> >
> > community, and to improve and unorphan a few packages.
> >
> > Regarding the gr-iio package, I already know what needs to be done in
> >
> > order to bring it up to speed and compiling on the new Fedora
> >
> > versions, so it wouldn't be too much effort or take too long to get
> >
> > the new version of the package ready.
> >
> > Regards,
> >
> > Isaac
>
> Hi Isaac,
>
> as gr-iio has been retired more than 8 weeks ago, a new review is
>
> required [1]. You should fill a new package review request, mentioning
>
> that you need a sponsor and that the ticket is about un-retiring a
>
> package. See the wiki at [2] for all the steps to perform.
>
> Regards
>
> Mattia
>
> [1]
>
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
>
> [2] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
> 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: Two questions on updates

2020-11-17 Thread Fabio Valentini

On Tue, Nov 17, 2020 at 1:25 PM Kevin Kofler via devel
 wrote:
>
> Fabio Valentini wrote:
> > Normal updates need at *least* +2 karma so they can be pushed to
> > stable *manually*.
>
> Uh, last I checked, normal updates need only +1 (and that's a good thing,
> many updates don't even get +1 in a reasonable time frame, let alone +2).
> Only critical path packages and (IIRC) EPEL need +2.

You are kinda right, yet you are not.
The minimum for *autokarma* is +1 for normal updates, +2 for critpath updates.
But the message "This update can be pushed to stable if the maintainer
wishes" does not refer to autokarma (update getting pushed
automatically by bodhi after getting the necessary karma), but to
maintainers pushing an update *manually* - which is *always* allowed
for updates that got at least +2 karma, and is independent from
"autokarma".

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

Re: Unable to disable SysRq

2020-11-17 Thread Robert Marcano via devel


On 11/17/20 8:26 AM, Robert Marcano wrote:


User d9k on IRC found the culprit. It is low-memory-monitor. The latest 
commit [1] for it tries to not mess with the value with 1 is set, but it 
should not mess with it ever.


The same documentation on that commit references [2] where it says:

Note that the value of ``/proc/sys/kernel/sysrq`` influences only the 
invocation
via a keyboard. Invocation of any operation via 
``/proc/sysrq-trigger`` is

always allowed (by a user with admin privileges).



[1] 
https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/commit/11560bc102941c95890c0852f2d9b166853b4f6a 

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysrq.rst 



Will submit a bug (if d9k already hasn't done that).



Reported upstream and a tracking bug on bugzilla

https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/issues/11
https://bugzilla.redhat.com/show_bug.cgi?id=1898524
___
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: Unable to disable SysRq

2020-11-17 Thread Chuck Anderson

On Tue, Nov 17, 2020 at 01:10:02PM +0100, Kevin Kofler via devel wrote:
> Robert Marcano via devel wrote:
> > Two times in a week I have killed all processes trying to use Alt+i. Ts
> > is to easy to press the Alt and the PrtScr at the same, starting that
> > way the SysRq i command.
> > 
> > So before staring to write a kernel patch to add an option where the
> > SysRq is only triggered by the Left Alt key. I decided to initially
> > disable sysrq entirely.
> [followed by technical details of why that failed]
> 
> This is funny because SysRq is supposed to be disabled by default in Fedora 
> to begin with, for security reasons.

According to https://fedoraproject.org/wiki/QA/Sysrq

16 - enable sync command

64 - enable signalling of processes (term, kill, oom-kill)

80 = 16+64 and enables both of the above.

Sync seems safe to always leave enabled.  Killing processes probably not.

___
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: Unable to disable SysRq

2020-11-17 Thread Robert Marcano via devel

On 11/16/20 8:25 PM, Robert Marcano wrote:
I am using a ThinkPad with one of these keyboards where the PrtScr key
is between the right Alt and Ctrl, an awful position.

Two times in a week I have killed all processes trying to use Alt+i. Ts
is to easy to press the Alt and the PrtScr at the same, starting that
way the SysRq i command.

So before staring to write a kernel patch to add an option where the
SysRq is only triggered by the Left Alt key. I decided to initially
disable sysrq entirely.

My Fedora 33 kernel.sysrq value is 80, the default at
/usr/lib/sysctl.d/50-default.conf say that it should be 16.

Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot
the value is 64, only after a single user mode boot the value stays at 0.

Some other thing is enabling the 64 bit, Asked on IRC and another user
has 80 on Fedora Workstation and 16 on Server.

I tried disabling all non default services on my installation but to no
effect, the 64 bit is always enabled. Fedora 33 Live CD shows 16 as the
default is configured.

How can I log what process is changing values on the sysctl variables?
or anyone has aon idea of what is happening here?

User d9k on IRC found the culprit. It is low-memory-monitor. The latest
commit [1] for it tries to not mess with the value with 1 is set, but it
should not mess with it ever.

The same documentation on that commit references [2] where it says:

Note that the value of ``/proc/sys/kernel/sysrq`` influences only the invocation
via a keyboard. Invocation of any operation via ``/proc/sysrq-trigger`` is
always allowed (by a user with admin privileges).

[1]
https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/commit/11560bc102941c95890c0852f2d9b166853b4f6a
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysrq.rst

Will submit a bug (if d9k already hasn't done that).
___
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 1890417] amavisd-new-snmp can't be installed on EL8 because of dropped net-snmp-perl

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1890417

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-ca1ac5519e has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ca1ac5519e


-- 
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: Two questions on updates

2020-11-17 Thread Kevin Kofler via devel

Fabio Valentini wrote:
> Normal updates need at *least* +2 karma so they can be pushed to
> stable *manually*.

Uh, last I checked, normal updates need only +1 (and that's a good thing, 
many updates don't even get +1 in a reasonable time frame, let alone +2). 
Only critical path packages and (IIRC) EPEL need +2.

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: Unable to disable SysRq

2020-11-17 Thread Kevin Kofler via devel

Robert Marcano via devel wrote:
> Two times in a week I have killed all processes trying to use Alt+i. Ts
> is to easy to press the Alt and the PrtScr at the same, starting that
> way the SysRq i command.
> 
> So before staring to write a kernel patch to add an option where the
> SysRq is only triggered by the Left Alt key. I decided to initially
> disable sysrq entirely.
[followed by technical details of why that failed]

This is funny because SysRq is supposed to be disabled by default in Fedora 
to begin with, for security reasons.

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: Unable to disable SysRq

2020-11-17 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Nov 16, 2020 at 11:35:41PM -0800, Samuel Sieb wrote:
> On 11/16/20 4:25 PM, Robert Marcano via devel wrote:
> >My Fedora 33 kernel.sysrq value is 80, the default at
> >/usr/lib/sysctl.d/50-default.conf say that it should be 16.
> >
> >Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after
> >boot the value is 64, only after a single user mode boot the value
> >stays at 0.

That should work. I just tested such setup locally, and after running
'sudo systemctl restart systemd-sysctl', 'sysctl kernel.sysrq' reports 0.
So it really seems like something else is setting it.

On another machine, I have '80', even though the config says '16'.

> >Some other thing is enabling the 64 bit, Asked on IRC and another
> >user has 80 on Fedora Workstation and 16 on Server.
> >
> >How can I log what process is changing values on the sysctl
> >variables? or anyone has aon idea of what is happening here?
> 
> This is a very curious issue.  I checked on various computers I have
> around.  All the F32 systems have 16.  My one laptop that was
> installed with the Gnome desktop, but not directly Workstation and
> has now been upgraded to F33 is still 16.  However, two other
> computers that were installed with F32 Workstation switched to 80
> when upgraded to F33.  I have not been able to figure out what is
> causing that, but it does seem to be related to the Workstation
> config somehow.

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

Fedora-Cloud-31-20201117.0 compose check report

2020-11-17 Thread Fedora compose checker

No missing expected images.

Passed openQA tests: 7/7 (x86_64), 7/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1517572] Please add unar dependency/configuration for .rar and comment .lrz support

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1517572

Juan Orti Alcaine  changed:

   What|Removed |Added

  Component|amavisd-new |amavis




-- 
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 1851872] Wrong tag in comment line of DKIM record: 'i=' should be 's='

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1851872

Juan Orti Alcaine  changed:

   What|Removed |Added

 CC||j.orti.alca...@gmail.com
  Component|amavisd-new |amavis




-- 
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 1890417] amavisd-new-snmp can't be installed on EL8 because of dropped net-snmp-perl

2020-11-17 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1890417

Juan Orti Alcaine  changed:

   What|Removed |Added

  Component|amavisd-new |amavis




-- 
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 proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-17 Thread Lennart Poettering

On So, 15.11.20 18:25, Chris Adams (li...@cmadams.net) wrote:

> Once upon a time, Stephen John Smoogen  said:
> > Because a lot of networks use routing tricks to send traffic to particular
> > DNS server IP addresses. They may round robin, traffic route, or other
> > methods to send you to different DNS servers with the same ip address. Even
> > if they are all the same 'model' device, they have different features
> > turned on or are at different revisions.. so whatever you have cached is
> > wrong.
>
> I'm pretty sure that's considered "their problem"... anycast servers are
> expected to behave the same (or similar enough) in terms of features
> supported.  Real DNS recursive servers like Unbound and BIND keep info
> about particular servers by IP.

We do exactly this.

(It is far from perfect though, for example, quad9's DNS servers you
reach via 9.9.9.9 might have a different feature set whenever you
reach them. Try "dig @9.9.9.9 +nsid heise.de" a bunch of times. It
will sometimes advertise an EDNS dgram size of 512 and sometimes of
1232. Which is quite some discrepancy in configuration. — And
sometimes it returns NSID, and sometimes it doesn't, but I am fine to
ignore that.)

Lennart

--
Lennart Poettering, Berlin
___
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-Cloud-32-20201117.0 compose check report

2020-11-17 Thread Fedora compose checker

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-32-20201116.0):

ID: 723519  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/723519
ID: 723526  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/723526

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-17 Thread Lennart Poettering

On So, 15.11.20 15:36, Samuel Sieb (sam...@sieb.net) wrote:

> On 11/15/20 7:31 AM, Lennart Poettering wrote:
> > Implementing this does not come without drawbacks though: right now
> > resolved tries hard to use the same server if at all possible, since
> > we want to use newer DNS features if possible, but many DNS servers
> > (wifi routers, yuck) tend to support them quite badly. This means
> > resolved has an elaborate scheme to learn about the feature set of the
> > DNS servers it contacts. And that can be slow, in particular on
> > servers where we step-by-step have to downgrade to the most minimal of
> > DNS protocols. This learning phase is run only when first contacting
> > some server (and after some grace period). If we'd switch servers all
> > the time, for every single lookup, then we'd start from zero every
> > time, not knowing what the server supports, and thus having to learn
> > about it over and over again. This would hence make all,
> > *every*single* transaction pretty slow. And that sucks.
>
> Wouldn't you just need to do it once for each server and cache that info?
> And why do you need to re-do the learning phase for a server you've already
> checked?

We do remember that. But if you stick to talking to one server for 500
transactions, you will have one slow lookup, the initial one that
needs to probe the feature set, plus 499 speedy ones. If you however
spread your 500 lookups over 250 servers, you will get 250 slow looups
plus 250 speedy ones — all in the worst case. Simply becaue we then
need to probe 250 servers for the first time... (See other mail)

> > DoT becomes efficient when we can reuse the established TCP/TLS connection
> > for multiple lookups. But if we'd switch servers all the time, then of
> > course there's no reuse of TCP/TLS connections possible.
>
> Same thing here.  Would it be a problem to keep a connection open for each
> server?

We keep one connection open for each server, if it let's us. Typically
they don't let us keep it open for long though. if you have actually
have a ton of servers and distribute lookups over all of them, it
decreases the chance of connection reuse, and thus increases the
chance that connections will go idle from perspective of the server
operator, and thus will be disconnected. Given the short idle timeouts
of popular servers such as 8.8.8.8 this actually matters a lot.

Lennart

--
Lennart Poettering, Berlin
___
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 proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-17 Thread Lennart Poettering

On Mo, 16.11.20 21:48, Petr Menšík (pemen...@redhat.com) wrote:

> But it does not have to learn everything about a server, because it
> switched the active one. If it has to, try to find way to store server
> instance features per server IP, not per link.

We do exactly this. But we also have a grace period after which we
forget everything again, and go back to the best server feature level again,
which then takes some time to settle back on the actual server feature
level.

When we always use the same server, then we probe it once, and use it
for the full grace period without any further delays. When we use
numerous servers, and a different one for each lookup, then this means
we have to probe each and every single one of them once and that slows
down things.

It's a very easy calulation: if you use n=1 servers for 500 lookups
within the grace period, you experience 1 slow lookup in the worst
case that required the feature probing, plus 499 speedy lookups
because we already knew the earlier probing results. If otoh you use
n=250 servers for 500 lookups you experience 250 worst case slow
lookups, since we need to learn for each server individually what it
can and can't do, plus 250 speedy lookups. And then, after the grace
period is over, you get another 250 slow lookups...

> > It might be something to add as opt-in, and come with the warning that
> > you better list DNS servers that aren't crap if you want to use that,
> > so that we never have to downgrade protocol level, and thus the
> > learning phase is short.
>
> Sure enough, many router DNS implementations are bad or ugly. If it can
> choose from full featured validated ISP resolver and crappy router
> implementation, prefer the one with better features. Most likely it is
> much better maintained as well.

I am sorry, but that is not a suitable approach for an "edge" DNS
clients. We need to go through the DNS server info we acquired through
DHCP or so, since private domains do exist. We must keep router admin
pages accessible.

Hence, the "server spread" thing where queries are spread over a ton
of DNS servers only really works if configured for the manual opt-in
case. It's not something we could ever deploy by default. By default
we need something that works, doesn't break private domains, and isn't
slow.

Lennart

--
Lennart Poettering, Berlin
___
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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-17 Thread Felix Schwarz



Am 16.11.20 um 14:03 schrieb Vitaly Zaitsev via devel:
Most of casual packagers simply ignore all pull requests and don't even check 
their mail. It is much more easier to fix the package manually than waiting 2-3 
weeks for a response.


I think this is the root cause and a real problem (I complained about this 
myself several few times on this list). However I argue it is wrong starting to 
shortcut existing rules as this causes additional fallout for responsive 
maintainers who might feel disenfranchised.


Instead we should start thinking about ways to actually fix the root cause 
problem (and also how to integrate Fedora packaging much better with actual 
users, hopefully "converting" some users into packagers).


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

63 matches

Mail list logo