[Bug 1814114] perl-Gtk3-0.037 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1814114



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

-- 
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 1814114] New: perl-Gtk3-0.037 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1814114

Bug ID: 1814114
   Summary: perl-Gtk3-0.037 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Gtk3
  Keywords: FutureFeature, Triaged
  Assignee: berra...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, dd...@cpan.org,
perl-devel@lists.fedoraproject.org, ser...@serjux.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.037
Current version/release in rawhide: 0.036-2.fc32
URL: http://search.cpan.org/dist/Gtk3/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2947/

-- 
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 1814114] perl-Gtk3-0.037 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1814114



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

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


[389-devel] 389 DS nightly 2020-03-17 - 96% PASS

2020-03-16 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/17/report-389-ds-base-1.4.3.4-20200317gitb32c745.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


[Bug 1814107] New: Please make it available on EPEL8

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1814107

Bug ID: 1814107
   Summary: Please make it available on EPEL8
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Text-Iconv
  Assignee: andr...@bawue.net
  Reporter: d...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: andr...@bawue.net, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
It is not available on EPEL8 and is needed for needrestart (indirectly).


Additional info:
It rebuilds fine without any change.

-- 
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-32-20200316.n.0 compose check report

2020-03-16 Thread Fedora compose checker
No missing expected images.

Failed openQA tests: 6/171 (x86_64), 1/2 (arm)

Old failures (same test failed in Fedora-32-20200315.n.0):

ID: 547006  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/547006
ID: 547015  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/547015
ID: 547027  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/547027
ID: 547094  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/547094
ID: 547101  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/547101
ID: 547107  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/547107
ID: 547108  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/547108

Soft failed openQA tests: 15/171 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-32-20200315.n.0):

ID: 546936  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/546936
ID: 546937  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/546937
ID: 546939  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/546939
ID: 546941  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/546941
ID: 546944  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/546944
ID: 546945  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/546945
ID: 546965  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/546965
ID: 546982  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/546982
ID: 546984  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/546984
ID: 547028  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/547028
ID: 547055  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/547055
ID: 547090  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/547090
ID: 547093  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/547093
ID: 547100  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/547100
ID: 547112  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/547112

Passed openQA tests: 149/171 (x86_64)

New passes (same test not passed in Fedora-32-20200315.n.0):

ID: 546958  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/546958
ID: 547002  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/547002
ID: 547003  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/547003
ID: 547013  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/547013
ID: 547066  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/547066

Skipped non-gating openQA tests: 1 of 173

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.02 to 0.15
Previous test data: https://openqa.fedoraproject.org/tests/546079#downloads
Current test data: https://openqa.fedoraproject.org/tests/546979#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 0.86 to 1.00
Average CPU usage changed from 15.35714286 to 26.09047619
Previous test data: https://openqa.fedoraproject.org/tests/546082#downloads
Current test data: https://openqa.fedoraproject.org/tests/546980#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.66 to 0.91
Average CPU usage changed from 4.58571429 to 17.92380952
Previous test data: https://openqa.fedoraproject.org/tests/546081#downloads
Current test data: https://openqa.fedoraproject.org/tests/546981#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Mount /run/user/0 disappeared since previous compose
Used mem changed from 732 MiB to 895 MiB
System load changed from 1.25 to 1.67
Average CPU usage changed from 2.2 to 37.88571429
Previous test data: https://openqa.fedoraproject.org/tests/546100#downloads
Current test data: 

[Bug 1004354] perl-Alien-ROOT not available on ARM because root is not there

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1004354

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #13 from Fedora Update System  ---
perl-Alien-ROOT-5.34.36.1-19.fc32 has been pushed to the Fedora 32 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-847f485965

-- 
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 1813720] perl-Pod-Usage-1.70 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813720



--- Comment #6 from Fedora Update System  ---
perl-Pod-Usage-1.70-1.fc32 has been pushed to the Fedora 32 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d708f52a27

-- 
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-03-16 Thread updates
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8ce58993d7   
mbedtls-2.16.5-1.el8
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4   
ansible-2.9.6-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1402a55654   
nethack-3.6.6-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d92c8360fe   
chromium-80.0.3987.132-1.el8


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

log4cplus-1.2.0-11.el8
perl-JSON-Parse-0.56-1.el8

Details about builds:



 log4cplus-1.2.0-11.el8 (FEDORA-EPEL-2020-5e4c973748)
 Logging Framework for C++

Update Information:

Add log4cplus to EPEL8

ChangeLog:

* Wed Jan 29 2020 Fedora Release Engineering  - 
1.2.0-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Thu Jul 25 2019 Fedora Release Engineering  - 
1.2.0-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri Feb  1 2019 Fedora Release Engineering  - 
1.2.0-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Fri Jul 13 2018 Fedora Release Engineering  - 
1.2.0-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Thu Apr 26 2018 Tomas Hozza  - 1.2.0-7
- Added gcc-c++ as an explicit BuildRequires
* Thu Feb  8 2018 Fedora Release Engineering  - 
1.2.0-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Aug  3 2017 Fedora Release Engineering  - 
1.2.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Wed Jul 26 2017 Fedora Release Engineering  - 
1.2.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Fri Feb 10 2017 Fedora Release Engineering  - 
1.2.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Wed Mar 23 2016 Zdenek Dohnal zdoh...@redhat.com - 1.2.0-2
- Replacing hard names with macros, returning and commenting macro prever in
  specfile
* Fri Mar 18 2016 zdohnal  - 1.2.0-1
- Update to 1.2.0
* Thu Feb  4 2016 Fedora Release Engineering  - 
1.1.3-0.5.rc3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
* Thu Jan 14 2016 Tomas Hozza  - 1.1.3-0.4.rc3
- Fixed typo so that log4cplus is compiled with C++11 support (#1297906)
* Wed Jun 17 2015 Fedora Release Engineering  
- 1.1.3-0.3.rc3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
* Sat May  2 2015 Kalev Lember  - 1.1.3-0.2.rc3
- Rebuilt for GCC 5 C++11 ABI change
* Tue Dec 16 2014 Tomas Hozza  - 1.1.3-0.1.rc3
- update to 1.1.3rc3
- build the library with c++11 support
* Sun Aug 17 2014 Fedora Release Engineering  
- 1.1.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
* Sat Jun  7 2014 Fedora Release Engineering  
- 1.1.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
* Thu Oct 24 2013 Tomas Hozza  - 1.1.2-1
- update to 1.1.2
* Sat Aug  3 2013 Fedora Release Engineering  
- 1.1.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
* Thu May 23 2013 Tomas Hozza  1.1.1-1
- update to 1.1.1
* Mon Feb 18 2013 Adam Tkac  - 1.1.0-1
- update to 1.1.0
* Thu Feb 14 2013 Fedora Release Engineering  
- 1.1.0-0.3.rc10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
* Fri Sep 21 2012 Adam Tkac  - 1.1.0-0.2.rc10
- some fixes related to pkg review
* Thu Sep 20 2012 Adam Tkac  - 1.1.0-0.1.rc10
- initial package

References:

  [ 1 ] Bug #1767162 - log4cplus is available on EPEL 7 but not on EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1767162




 perl-JSON-Parse-0.56-1.el8 (FEDORA-EPEL-2020-a0bbfb3dea)
 Read JSON into a Perl variable

Update Information:

This package contains JSON::Parse, a Perl module for parsing JSON. (JSON means
"JavaScript Object Notation" and it is specified in "RFC 7159".)

ChangeLog:

* Thu Feb 20 2020 Emmanuel Seyman  - 0.56-1
- Update to 0.56
- Use /usr/bin/perl instead of %/usr/bin/perl
- Pass NO_PERLLOCAL=1 to Makefile.PL
- Use %{make_install} instead of "make pure_install"
- Use %{make_build} instead of make
* Thu Jan 30 2020 Fedora Release Engineering  - 0.55-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Fri Jul 26 2019 Fedora Release Engineering  - 0.55-7
- Rebuilt for 

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

2020-03-16 Thread updates
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 580  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 322  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
 319  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  29  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6   
python-waitress-1.4.3-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-471d8a7abd   
sympa-6.2.54-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b3684de763   
mbedtls-2.7.14-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4fdca9429c   
seamonkey-2.53.1-2.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fbd804208a   
monit-5.26.0-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b8f44a854a   
weechat-2.7.1-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b467e9784b   
php-horde-Horde-Form-2.0.20-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7e106e25f9   
timeshift-20.03-1.el7


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

sourcextractor++-0.10-1.el7

Details about builds:



 sourcextractor++-0.10-1.el7 (FEDORA-EPEL-2020-58450ed489)
 A program that extracts a catalog of sources from astronomical images, and the 
successor of SExtractor

Update Information:

New RPM

ChangeLog:

* Fri Mar 13 2020 Alejandro Alvarez Ayllon  0.10-1
- Update for upstream release 0.10
* Fri Jan 31 2020 Alejandro Alvarez Ayllon  0.8-1
- New RPM


___
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


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

2020-03-16 Thread Fedora compose checker
No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 15/171 (x86_64), 1/2 (arm)

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

ID: 546622  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/546622
ID: 546641  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/546641
ID: 546736  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/546736

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

ID: 546607  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/546607
ID: 546615  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/546615
ID: 546621  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/546621
ID: 546626  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/546626
ID: 546628  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/546628
ID: 546631  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/546631
ID: 546632  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/546632
ID: 546672  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/546672
ID: 546684  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/546684
ID: 546751  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/546751
ID: 546758  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/546758
ID: 546764  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/546764
ID: 546765  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/546765

Soft failed openQA tests: 15/171 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 546619  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/546619

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

ID: 546593  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/546593
ID: 546594  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/546594
ID: 546596  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/546596
ID: 546598  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/546598
ID: 546601  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/546601
ID: 546602  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/546602
ID: 546651  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/546651
ID: 546653  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/546653
ID: 546685  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/546685
ID: 546694  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/546694
ID: 546712  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/546712
ID: 546747  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/546747
ID: 546750  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/546750
ID: 546757  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/546757

Passed openQA tests: 141/171 (x86_64)

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

ID: 546634  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/546634
ID: 546668  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/546668
ID: 546669  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/546669
ID: 546701  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/546701

Skipped non-gating openQA tests: 1 of 173

Installed system changes in test x86_64 

[Bug 1813720] perl-Pod-Usage-1.70 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813720



--- Comment #5 from Fedora Update System  ---
perl-Pod-Usage-1.70-1.fc31 has been pushed to the Fedora 31 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0acf97c1e1

-- 
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 1813720] perl-Pod-Usage-1.70 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813720

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Pod-Usage-1.70-1.fc30 has been pushed to the Fedora 30 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9360ad9872

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


[389-devel] Re: Please have a look at rewriters design

2020-03-16 Thread William Brown


> On 17 Mar 2020, at 02:49, thierry bordaz  wrote:
> 
> Hi,
> 
> As a follow up of the PR https://pagure.io/389-ds-base/pull-request/50939,
> I wrote down a small design about  rewriters (filter/computed_attr) plugin: 
> http://www.port389.org/docs/389ds/design/search_rewriters.html
> 
> Comments are welcome

Probably the most dangerous thing to say in all of history?

Like, your design is very smart, but that cleverness and flexibility carries 
many risks. The problem at hand is rewriting ad attributes - not to make a 
framework. I still say focus on that problem alone rather than trying to solve 
a generic class of problems.

Anyway, I still don't think this is the right avenue. There are two major 
reasons for this:

First, is the attempt to make a "generic framework" to solve a "specific 
problem". We should not have a generic rewrite framework, when all we need is a 
specific, focused, module just for doing known and well tested attribute 
transformations. 

Code like COS or MEP may be generic, and it solves many cases but the surface 
area is huge, it's hard to test, and it's hard to reason about. 

We do not have a need for allowing generic, and arbitrary rewriters to exist, 
especially not when you have to "compile in" the rewriters anyway!

This should be simply, an "ad rewrite" plugin, where all it does is that one 
thing - rewrite the attributes as required for AD emulation for IPA. This is 
far easier to deploy, test and reason about. Ideally, the configuration is 
simply "the plugin is enabled or disabled".


Second, is the idea of this being a "search rewriter". I don't think this is a 
good idea. The search path should be simple, it's our hot path. We have many 
things that have to interact like indexes etc. Look at virtual attribute 
indexing and such and the work needed for COS to have these used? 

This plugin should be on the write path, transforming when a change occurs. 
This means the code is much simpler, easier to test, and we need no 
modifications to our read paths. Things like MEP and replication will "just 
work" as will indexing and much more.


For me to approve this plugin, I really want to see it being a write-path 
transformation of values into other values, and it should be focused, targeted, 
and simple. 

I do want to make one thing clear though - I think it's much better that this 
plugin exist in 389-ds rather than in freeipa. The 389-ds project has better 
tooling (like ASAN/LSAN), faster testing capability and a group of subject 
matter experts for code review. I think that if you were to move this to 
freeipa, you would not have the same level of testing or review quality as 
here, so I'd prefer to see you put it here. Sure, I might be difficult on this 
topic, but I do it because I believe there is a better, more robust manner to 
approach this problem space than currently you are considering. :) 


Thanks,


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

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


Release fedpkg-1.38

2020-03-16 Thread Ondrej Nosek
Hi all,

a new version fedpkg-1.38 is released.
Currently, Fedora 30, 31, 32 and Rawhide packages are in the stable
repository, feel free to try other waiting distributions (el6, epel7) in
Bodhi.

Release description:
Feature documentation, changelog and fixes description can be seen here:
https://docs.pagure.org/fedpkg/releases/1.38.html
Couple features include a demo video. Some items were released earlier the
regular release as patches.

Updates:
https://bodhi.fedoraproject.org/updates/?builds=fedpkg-1.38-2.el6=fedpkg-1.38-2.el7=fedpkg-1.38-2.fc30=fedpkg-1.38-2.fc31=fedpkg-1.38-2.fc32=fedpkg-1.38-2.fc33

Alternative link:
https://bodhi.fedoraproject.org/updates/?packages=fedpkg=1

Thanks to all contributors.

Regards
___
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: Release rpkg-1.58 fedpkg-1.37

2020-03-16 Thread Ondrej Nosek
Hi all,

a new version fedpkg-1.38 is released.
Currently, Fedora 30, 31, 32 and Rawhide packages are in the stable
repository, feel free to try other waiting distributions (el6, epel7) in
Bodhi.

Release description:
Feature documentation, changelog and fixes description can be seen here:
https://docs.pagure.org/fedpkg/releases/1.38.html
Couple features include a demo video. Some items were released earlier the
regular release as patches.

Updates:
https://bodhi.fedoraproject.org/updates/?builds=fedpkg-1.38-2.el6=fedpkg-1.38-2.el7=fedpkg-1.38-2.fc30=fedpkg-1.38-2.fc31=fedpkg-1.38-2.fc32=fedpkg-1.38-2.fc33

Alternative link:
https://bodhi.fedoraproject.org/updates/?packages=fedpkg=1

Thanks to all contributors.

Regards

>
___
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: What to do when packagers "forget" bodhi updates for branched (f32)?

2020-03-16 Thread Peter Hutterer
On Mon, Mar 16, 2020 at 09:30:51PM +0100, Fabio Valentini wrote:
> Hi everybody,
> 
> It's that time of the semi-year again, and I again found multiple
> instances of packages that have updates for rawhide and f31/f30, but
> no bodhi update for fedora 32.
> 
> In most cases, the updated package was built on fedora 32 (a koji
> build was successful), but no bodhi update was created. In some cases,
> f32 was "forgotten" entirely.
> 
> So, assuming the best, those packagers simply forgot that bodhi
> updates are necessary for branched releases after the beta freeze.
> 
> What is the best couse of action for such forgotten updates? Some are
> bugfixes, others are new versions, and some could be security fixes,
> that are then missing from f32 entirely.

I pushed a few updates after branching where I did try to submit updates and
bodhi rejected them (too early) and then I simply missed the point where
they became necessary.

so for me - an email to fedora-{devel|announce} with "bodhi updates for f32
are required now" would be good. the more obvious the subject line the
better. if that email was indeed sent and I missed it - oops and my
apologies :)

Failing all that, screaming at the maintainer in the most appreciative and
respectful way is always a good way to get things fixed too :)
 
> I *could* file bodhi updates for everything that's missing from f32,
> but I do not want to interfere with others' work here.
> 
> Filing bodhi comments on the updates that break the upgrade path
> (f31/f30, in this case) is not productive either, since those comments
> are often ignored in my experience.
> 
> A few examples that popped up on my systems (I'm sure there are more):
> 
> 1) dnsmasq-2.80-12.fc31 is going to f31 stable:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab29ac03c
> The corresponding f32 build (dnsmasq-2.80-13.fc32) succeeded in koji,
> but then an internal koji error broke it. It wasn't resubmitted, and
> there's no bodhi update for it:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42386221
> 
> 2) libinput-1.15.3-2.fc31 is going to f31 stable:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d66ed9f32e
> The corresponding f32 build in koji was successful, but no bodhi
> update is associated with it:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1475404

fixed now, apologies for the mess.

Cheers,
   Peter

> 
> 3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161
> The update to 3.1.3 has been built for f33 and f31, but not for f32.
> The 3.1.3 changes aren't even merged from master into the f32 branch
> in dist-git.
> 
> Any suggestions what we could do to make sure f32 updates aren't
> forgotten after the beta freeze?
> 
> 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
___
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


Orphaned packages looking for new maintainers

2020-03-16 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-03-16.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

aalto-xml java-sig, orphan 2 weeks ago
apache-commons-jexl   mizdebsk, orphan 4 weeks ago
appframework  orphan   4 weeks ago
bean-validation-api   orphan   4 weeks ago
bindexorphan   4 weeks ago
clang7.0  orphan, sergesanspaille, 5 weeks ago
  tstellar
clang8.0  orphan, sergesanspaille, 4 weeks ago
  tstellar
compress-lzf  orphan   2 weeks ago
cpptasks  orphan   1 weeks ago
cuneiform orphan   4 weeks ago
disruptor-thrift-server   orphan   2 weeks ago
dspam gnat, orphan 3 weeks ago
dump  jridky, orphan, vdolezal 4 weeks ago
erlang-fs orphan   3 weeks ago
felix-scr-maven-pluginjerboaa, jkang, orphan   5 weeks ago
fluxcapacitor orphan, suve 3 weeks ago
freemarkerorphan   4 weeks ago
geronimo-jta  mizdebsk, orphan 4 weeks ago
glade3dridi, nonamedotc, orphan,   2 weeks ago
  rakesh
gnome-shell-extension-orphan   4 weeks ago
taskwarrior
hexter-dssi   orphan   1 weeks ago
hibernate lef, odubaj, orphan  6 weeks ago
ini4j orphan   6 weeks ago
insectfnux, orphan 0 weeks ago
jacocojvanek, kdaniel, lef, orphan 3 weeks ago
javapoet  orphan   2 weeks ago
jboss-marshalling mizdebsk, orphan 2 weeks ago
jetty-alpn-apimizdebsk, orphan 2 weeks ago
jetty-build-support   mizdebsk, orphan 1 weeks ago
jmol  jussilehtola, orphan 4 weeks ago
js-jquery-jstree  orphan   3 weeks ago
js-jquery-notyorphan   3 weeks ago
jspecview jussilehtola, orphan 4 weeks ago
jsr-311   mizdebsk, orphan 4 weeks ago
laszipdevrim, orphan   1 weeks ago
libdivecomputer-subsurfaceorphan, rdieter  3 weeks ago
liblasdevrim, orphan   1 weeks ago
llvm7.0   jistone, orphan, 5 weeks ago
  sergesanspaille, tstellar
llvm8.0   orphan, sergesanspaille, 4 weeks ago
  tstellar
lv2-ll-pluginsorphan   1 weeks ago
lz4-java  orphan   2 weeks ago
lzma-java orphan   2 weeks ago
maven-injection-pluginmizdebsk, orphan 1 weeks ago
maven-mapping mizdebsk, orphan 1 weeks ago
mongo-java-driver jerboaa, lef, mskalick, orphan   3 weeks ago
mvel  orphan   1 weeks ago
naga  jussilehtola, orphan 4 weeks ago
nekobee-dssi  

Orphaned packages looking for new maintainers

2020-03-16 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-03-16.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

aalto-xml java-sig, orphan 2 weeks ago
apache-commons-jexl   mizdebsk, orphan 4 weeks ago
appframework  orphan   4 weeks ago
bean-validation-api   orphan   4 weeks ago
bindexorphan   4 weeks ago
clang7.0  orphan, sergesanspaille, 5 weeks ago
  tstellar
clang8.0  orphan, sergesanspaille, 4 weeks ago
  tstellar
compress-lzf  orphan   2 weeks ago
cpptasks  orphan   1 weeks ago
cuneiform orphan   4 weeks ago
disruptor-thrift-server   orphan   2 weeks ago
dspam gnat, orphan 3 weeks ago
dump  jridky, orphan, vdolezal 4 weeks ago
erlang-fs orphan   3 weeks ago
felix-scr-maven-pluginjerboaa, jkang, orphan   5 weeks ago
fluxcapacitor orphan, suve 3 weeks ago
freemarkerorphan   4 weeks ago
geronimo-jta  mizdebsk, orphan 4 weeks ago
glade3dridi, nonamedotc, orphan,   2 weeks ago
  rakesh
gnome-shell-extension-orphan   4 weeks ago
taskwarrior
hexter-dssi   orphan   1 weeks ago
hibernate lef, odubaj, orphan  6 weeks ago
ini4j orphan   6 weeks ago
insectfnux, orphan 0 weeks ago
jacocojvanek, kdaniel, lef, orphan 3 weeks ago
javapoet  orphan   2 weeks ago
jboss-marshalling mizdebsk, orphan 2 weeks ago
jetty-alpn-apimizdebsk, orphan 2 weeks ago
jetty-build-support   mizdebsk, orphan 1 weeks ago
jmol  jussilehtola, orphan 4 weeks ago
js-jquery-jstree  orphan   3 weeks ago
js-jquery-notyorphan   3 weeks ago
jspecview jussilehtola, orphan 4 weeks ago
jsr-311   mizdebsk, orphan 4 weeks ago
laszipdevrim, orphan   1 weeks ago
libdivecomputer-subsurfaceorphan, rdieter  3 weeks ago
liblasdevrim, orphan   1 weeks ago
llvm7.0   jistone, orphan, 5 weeks ago
  sergesanspaille, tstellar
llvm8.0   orphan, sergesanspaille, 4 weeks ago
  tstellar
lv2-ll-pluginsorphan   1 weeks ago
lz4-java  orphan   2 weeks ago
lzma-java orphan   2 weeks ago
maven-injection-pluginmizdebsk, orphan 1 weeks ago
maven-mapping mizdebsk, orphan 1 weeks ago
mongo-java-driver jerboaa, lef, mskalick, orphan   3 weeks ago
mvel  orphan   1 weeks ago
naga  jussilehtola, orphan 4 weeks ago
nekobee-dssi  

[Bug 1814068] New: perl-HTTP-BrowserDetect-3.26 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1814068

Bug ID: 1814068
   Summary: perl-HTTP-BrowserDetect-3.26 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-BrowserDetect
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.26
Current version/release in rawhide: 3.25-2.fc32
URL: http://search.cpan.org/dist/HTTP-BrowserDetect/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/5936/

-- 
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: Using %triggerpostun with %systemd_post on upgrades

2020-03-16 Thread Chris Murphy
Another idea, since util-linux 2.35 is only on Fedora 32+, how about

- %triggerpostun -- fedora-release < 32
+ %triggerpostun -- util-linux < 2.35
  %systemd_post fstrim.timer



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


Re: What to do when packagers "forget" bodhi updates for branched (f32)?

2020-03-16 Thread Miro Hrončok

On 16. 03. 20 21:30, Fabio Valentini wrote:

3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161
The update to 3.1.3 has been built for f33 and f31, but not for f32.
The 3.1.3 changes aren't even merged from master into the f32 branch
in dist-git.


See https://src.fedoraproject.org/rpms/python-matplotlib/pull-request/24

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1812567] perl-Devel-PatchPerl-1.90 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1812567

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:38:41



--- Comment #3 from Fedora Update System  ---
perl-Devel-PatchPerl-1.90-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1812257] perl-Devel-PatchPerl-1.88 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1812257

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Devel-PatchPerl-1.88-1 |perl-Devel-PatchPerl-1.88-1
   |.fc33   |.fc33
   |perl-Devel-PatchPerl-1.88-1 |perl-Devel-PatchPerl-1.88-1
   |.fc32   |.fc32
   ||perl-Devel-PatchPerl-1.90-1
   ||.fc32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:38:43



--- Comment #3 from Fedora Update System  ---
perl-Devel-PatchPerl-1.90-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1812177] perl-MooX-StrictConstructor-0.011 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1812177

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:38:23



--- Comment #3 from Fedora Update System  ---
perl-MooX-StrictConstructor-0.011-1.fc32 has been pushed to the Fedora 32
stable repository. If problems still persist, please make note of it in this
bug report.

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


[Bug 1812362] perl-XML-LibXML-2.0203 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1812362

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-XML-LibXML-2.0203-1.fc |perl-XML-LibXML-2.0203-1.fc
   |33  |33
   ||perl-XML-LibXML-2.0203-1.fc
   ||32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:38:20



--- Comment #3 from Fedora Update System  ---
perl-XML-LibXML-2.0203-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1811831] perl-Devel-PPPort-3.58 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1811831

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Devel-PPPort-3.58-1.fc |perl-Devel-PPPort-3.58-1.fc
   |33  |33
   ||perl-Devel-PPPort-3.58-1.fc
   ||32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:37:44



--- Comment #3 from Fedora Update System  ---
perl-Devel-PPPort-3.58-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1811986] perl-Sys-Virt-6.1.0 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1811986

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:37:57



--- Comment #2 from Fedora Update System  ---
perl-Sys-Virt-6.1.0-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1811507] perl-Test-Simple-1.302172 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1811507

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Test-Simple-1.302172-1 |perl-Test-Simple-1.302172-1
   |.fc33   |.fc33
   ||perl-Test-Simple-1.302172-1
   ||.fc32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:36:24



--- Comment #3 from Fedora Update System  ---
perl-Test-Simple-1.302172-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1004354] perl-Alien-ROOT not available on ARM because root is not there

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1004354



--- Comment #12 from Fedora Update System  ---
perl-Alien-ROOT-5.34.36.1-18.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1811541] rt-4.4.4-4.fc33 FTBFS: No matching package to install: '/usr/share/fonts/google-droid/DroidSans.ttf'

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1811541

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||rt-4.4.4-5.fc32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:36:41



--- Comment #3 from Fedora Update System  ---
rt-4.4.4-5.fc32 has been pushed to the Fedora 32 stable repository. If problems
still persist, please make note of it in this bug report.

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


[Bug 1810624] perl-Redis-1.996 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1810624

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:34:41



--- Comment #5 from Fedora Update System  ---
perl-Redis-1.996-1.fc32 has been pushed to the Fedora 32 stable repository. If
problems still persist, please make note of it in this bug report.

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


[Bug 1810919] perl-Net-GitHub-0.96 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1810919



--- Comment #4 from Fedora Update System  ---
perl-Net-GitHub-0.96-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1809718] perl-Locale-Codes-3.63 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809718



--- Comment #8 from Fedora Update System  ---
perl-Locale-Codes-3.63-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1810308] perl-TimeDate-2.32 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1810308

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:33:59



--- Comment #3 from Fedora Update System  ---
perl-TimeDate-2.32-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1809881] perl-Log-ger-0.031 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809881



--- Comment #3 from Fedora Update System  ---
perl-Log-ger-0.031-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1808744] perl-CPAN-Perl-Releases-5.20200229 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808744



--- Comment #9 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200229-1.fc32 has been pushed to the Fedora 32
stable repository. If problems still persist, please make note of it in this
bug report.

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


[Bug 1809214] perl-Test-Deep-1.130 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809214



--- Comment #4 from Fedora Update System  ---
perl-Test-Deep-1.130-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


What to do when packagers "forget" bodhi updates for branched (f32)?

2020-03-16 Thread Fabio Valentini
Hi everybody,

It's that time of the semi-year again, and I again found multiple
instances of packages that have updates for rawhide and f31/f30, but
no bodhi update for fedora 32.

In most cases, the updated package was built on fedora 32 (a koji
build was successful), but no bodhi update was created. In some cases,
f32 was "forgotten" entirely.

So, assuming the best, those packagers simply forgot that bodhi
updates are necessary for branched releases after the beta freeze.

What is the best couse of action for such forgotten updates? Some are
bugfixes, others are new versions, and some could be security fixes,
that are then missing from f32 entirely.

I *could* file bodhi updates for everything that's missing from f32,
but I do not want to interfere with others' work here.

Filing bodhi comments on the updates that break the upgrade path
(f31/f30, in this case) is not productive either, since those comments
are often ignored in my experience.

A few examples that popped up on my systems (I'm sure there are more):

1) dnsmasq-2.80-12.fc31 is going to f31 stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab29ac03c
The corresponding f32 build (dnsmasq-2.80-13.fc32) succeeded in koji,
but then an internal koji error broke it. It wasn't resubmitted, and
there's no bodhi update for it:
https://koji.fedoraproject.org/koji/taskinfo?taskID=42386221

2) libinput-1.15.3-2.fc31 is going to f31 stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d66ed9f32e
The corresponding f32 build in koji was successful, but no bodhi
update is associated with it:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1475404

3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161
The update to 3.1.3 has been built for f33 and f31, but not for f32.
The 3.1.3 changes aren't even merged from master into the f32 branch
in dist-git.

Any suggestions what we could do to make sure f32 updates aren't
forgotten after the beta freeze?

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


[Bug 1808774] perl-List-AllUtils-0.16 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808774



--- Comment #11 from Fedora Update System  ---
perl-List-AllUtils-0.16-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1808816] perl-String-Print-0.94 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808816



--- Comment #9 from Fedora Update System  ---
perl-String-Print-0.94-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1808799] perl-Dist-Zilla-6.014 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808799



--- Comment #4 from Fedora Update System  ---
perl-Dist-Zilla-6.014-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1808731] perl-DateTime-Format-Strptime-1.77 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808731



--- Comment #3 from Fedora Update System  ---
perl-DateTime-Format-Strptime-1.77-1.fc32 has been pushed to the Fedora 32
stable repository. If problems still persist, please make note of it in this
bug report.

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


[Bug 1809202] perl-Date-Manip-6.80 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809202



--- Comment #6 from Fedora Update System  ---
perl-Date-Manip-6.80-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1808730] perl-DateTime-1.52 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808730



--- Comment #5 from Fedora Update System  ---
perl-DateTime-1.52-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1807263] perl-Getopt-Long-Descriptive-0.105 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1807263



--- Comment #5 from Fedora Update System  ---
perl-Getopt-Long-Descriptive-0.105-1.fc32 has been pushed to the Fedora 32
stable repository. If problems still persist, please make note of it in this
bug report.

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


[Bug 1809718] perl-Locale-Codes-3.63 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809718

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Locale-Codes-3.63-1.fc |perl-Locale-Codes-3.63-1.fc
   |33  |33
   |perl-Locale-Codes-3.63-1.fc |perl-Locale-Codes-3.63-1.fc
   |31  |31
   |perl-Locale-Codes-3.63-1.fc |perl-Locale-Codes-3.63-1.fc
   |30  |30
   ||perl-Locale-Codes-3.63-1.fc
   ||32



--- Comment #7 from Fedora Update System  ---
perl-Locale-Codes-3.63-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1809881] perl-Log-ger-0.031 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809881

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Log-ger-0.031-1.fc33   |perl-Log-ger-0.031-1.fc33
   ||perl-Log-ger-0.031-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:21:40



--- Comment #2 from Fedora Update System  ---
perl-Log-ger-0.031-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1809202] perl-Date-Manip-6.80 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809202

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Date-Manip-6.80-1.fc31 |perl-Date-Manip-6.80-1.fc31
   ||perl-Date-Manip-6.80-1.fc32



--- Comment #5 from Fedora Update System  ---
perl-Date-Manip-6.80-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1808799] perl-Dist-Zilla-6.014 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808799

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Dist-Zilla-6.014-1.fc3 |perl-Dist-Zilla-6.014-1.fc3
   |3   |3
   ||perl-Dist-Zilla-6.014-1.fc3
   ||2
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:20:19



--- Comment #3 from Fedora Update System  ---
perl-Dist-Zilla-6.014-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1808774] perl-List-AllUtils-0.16 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808774

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-List-AllUtils-0.16-1.f |perl-List-AllUtils-0.16-1.f
   |c33 |c33
   |perl-List-AllUtils-0.16-1.f |perl-List-AllUtils-0.16-1.f
   |c30 |c30
   |perl-List-AllUtils-0.16-1.f |perl-List-AllUtils-0.16-1.f
   |c31 |c31
   ||perl-List-AllUtils-0.16-1.f
   ||c32



--- Comment #10 from Fedora Update System  ---
perl-List-AllUtils-0.16-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1808730] perl-DateTime-1.52 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808730

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DateTime-1.52-1.fc33   |perl-DateTime-1.52-1.fc33
   ||perl-DateTime-1.52-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:19:46



--- Comment #4 from Fedora Update System  ---
perl-DateTime-1.52-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1808744] perl-CPAN-Perl-Releases-5.20200229 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808744

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200229-1.fc33  |0200229-1.fc33
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200229-1.fc30  |0200229-1.fc30
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200229-1.fc31  |0200229-1.fc31
   ||perl-CPAN-Perl-Releases-5.2
   ||0200229-1.fc32



--- Comment #8 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200229-1.fc32 has been pushed to the Fedora 32
stable repository. If problems still persist, please make note of it in this
bug report.

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


[Bug 1809214] perl-Test-Deep-1.130 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1809214

Fedora Update System  changed:

   What|Removed |Added

 Resolution|RAWHIDE |ERRATA



--- Comment #3 from Fedora Update System  ---
perl-Test-Deep-1.130-1.fc32 has been pushed to the Fedora 32 stable repository.
If problems still persist, please make note of it in this bug report.

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


[Bug 1808731] perl-DateTime-Format-Strptime-1.77 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808731

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DateTime-Format-Strpti |perl-DateTime-Format-Strpti
   |me-1.77-1.fc33  |me-1.77-1.fc33
   ||perl-DateTime-Format-Strpti
   ||me-1.77-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:19:48



--- Comment #2 from Fedora Update System  ---
perl-DateTime-Format-Strptime-1.77-1.fc32 has been pushed to the Fedora 32
stable repository. If problems still persist, please make note of it in this
bug report.

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


[Bug 1808816] perl-String-Print-0.94 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1808816

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-String-Print-0.94-1.fc |perl-String-Print-0.94-1.fc
   |33  |33
   |perl-String-Print-0.94-1.fc |perl-String-Print-0.94-1.fc
   |30  |30
   |perl-String-Print-0.94-1.fc |perl-String-Print-0.94-1.fc
   |31  |31
   ||perl-String-Print-0.94-1.fc
   ||32



--- Comment #8 from Fedora Update System  ---
perl-String-Print-0.94-1.fc32 has been pushed to the Fedora 32 stable
repository. If problems still persist, please make note of it in this bug
report.

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


[Bug 1807263] perl-Getopt-Long-Descriptive-0.105 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1807263

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Getopt-Long-Descriptiv |perl-Getopt-Long-Descriptiv
   |e-0.105-1.fc33  |e-0.105-1.fc33
   ||perl-Getopt-Long-Descriptiv
   ||e-0.105-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-03-16 20:14:54



--- Comment #4 from Fedora Update System  ---
perl-Getopt-Long-Descriptive-0.105-1.fc32 has been pushed to the Fedora 32
stable repository. If problems still persist, please make note of it in this
bug report.

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


Re: Intent to request a FESCo exception for python2 for ardour5

2020-03-16 Thread Guido Aulisi
Il giorno dom, 15/03/2020 alle 14.44 +0100, Fabio Valentini ha scritto:
> On Sun, Mar 15, 2020 at 2:37 PM Alexander Bokovoy <
> aboko...@redhat.com> wrote:
> > On su, 15 maalis 2020, Guido Aulisi wrote:
> > > Hi,
> > > 
> > > I’m going to ask a FESCo exception for python2 for package
> > > ardour5.
> > > Python2 is only needed to build the package using the WAF build
> > > system.
> > > 
> > > Ardour has been undergoing a complete rewriting for 2 years, no
> > > stable versions have been released in the last 2 years,
> > > so we are stuck with ardour 5.12, which still uses python2 to
> > > build.
> > > 
> > > What do you think about that?
> 
> (snip)
> 
> > Just package git master in Rawhide. It has been migrated to waf
> > 2.0.19
> > two months ago and builds just fine in Fedora 32 environments with
> > Python 3 only.
It's not considered ready for production by the developers, yet.

> I think FESCo would agree to temporarily continue building it with
> python2, given that upstream has already worked on supporting
> building
> with python3 eventually. At least, I would approve such an exception
> request (and other, similar requests for firefox, chromium, etc. have
> already been approved).
Thank you, I will make the request ASAP.

> But, if you think a current git snapshot would be an appropriate
> target for packaging, that solves the problem as well (I don't know
> how stable their development branch is).
AFAIK it's currently in alpha stage, I would wait for the next GIT tag.

Ciao
Guido
FAS: tartina


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Beware: java-1.8.0-openjdk SIGSEGVs / SIGABRTs in rawhide

2020-03-16 Thread Guido Aulisi
Il giorno dom, 15/03/2020 alle 15.02 +0100, Fabio Valentini ha scritto:
> Hi everybody,
> 
> The latest java-1.8.0-openjdk update for rawhide (the first build
> with
> GCC 10) seems to have introduced some serious problems - including
> crashes and segmentation faults during package builds for Java
> packages.
I had some problems with sord package with GCC 10, I had to lower
optimization to -O1.
It only happened on power64le and arm arches, not x86.
The problem is in a for loop, the exit condition (with calls a function
whcih modifies its argument) is never(?) evaluated (optimized out?).
The problem is present in F32 as well.
I could not find the root cause, because I do not know power assembler
that well.

Ciao
Guido
FAS: tartina


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 1814011] New: perl-Mojolicious-8.34 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1814011

Bug ID: 1814011
   Summary: perl-Mojolicious-8.34 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 8.34
Current version/release in rawhide: 8.33-2.fc33
URL: https://metacpan.org/release/Mojolicious

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/5966/

-- 
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: RFC: entering luks password on grub level for devices without keyboards

2020-03-16 Thread Stephen John Smoogen
On Mon, 16 Mar 2020 at 13:56, Robbie Harwood  wrote:

> Tomasz Torcz  writes:
>
> > On Sun, Mar 15, 2020 at 11:12:43PM +0100, Marius Schwarz wrote:
> >> Am 15.03.20 um 13:32 schrieb Vitaly Zaitsev via devel:
> >> > On 14.03.2020 13:05, Marius Schwarz wrote:
> >> >> If you encrypt  the fedora ( or any ) installation with luks, as
> >> >> security of a mobile device indicates, you end up without the
> >> >> possibility to enter the password, when you do not have an
> in/external
> >> >> keyboard at hand.
> >> > You should use TPM 2.0 LUKS unlock instead of using passwords.
> >> >
> >> I  knew someone would bring this up:  TMP does not protect your drive,
> >> as you could boot with "init=/bin/bash 1" .
> >
> >How do you do that WITHOUT KEYBOARD?  This thread is about very
> >  specific situation, please do not forget that when generalising.
>
> I believe nothing stops someone from simply plugging one in.
>
>
And the counter point is that if you can't plug one in, it is not something
that is supported. This is not general purpose hardware but a set of
hardware that is primarily built to run Microsoft Windows by the vendor.
There are going to be limits to what is going to be possible to get done
with it.


-- 
Stephen J Smoogen.
___
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: confused by rpminspect automated test

2020-03-16 Thread David Cantrell

On Mon, Mar 09, 2020 at 05:45:34PM +, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Mar 09, 2020 at 10:35:03AM -0700, Adam Williamson wrote:

On Mon, 2020-03-09 at 11:49 -0400, David Cantrell wrote:
>
> > > /etc/rpminspect/rpminspect.conf
> >
> > So that is a global config file...
> > RFE: move it under /usr, and only look for overrides in /etc.
> > 99% of users should not modify that, and it shouldn't be in /etc.
>
> I disagree.  Users are allowed to edit configuration files in /etc.

True, but Zbigniew isn't wrong either. I think the more modern config
pattern he refers to clearly *is* superior; it's much better for the
standard configuration to be in a 'not-meant-to-be-edited' file in
/usr/share but for the config loading mechanism to look for override
snippets in /etc/rpminspect/conf.d or whatever.


Yes, very much so. The important part is to be able to drop-in
overrides without caring about the rest of the configuration, and to
have the rest of the configuration update itself on package upgrades
without me having to do anything.


It means the upstream configuration can be updated without local
customizations being lost, and it's much nicer for the sysadmin as
well, for two reasons:

1) If you want to have two different local customizations for different
purposes, you can put them in 01-this.conf and 02-that.conf , with the
names being descriptive. This is *far* easier to understand when you
come back to it in three years than a single monolithic config file
which you *maybe* wrote some comments in.

2) You don't have to read or care about the entire config, your snippet
only needs to have as much in it as you actually want to change.

> As for the location, I could put it with the rest of the vendor-specific data
> in /usr/share/rpminspect and allow for the location in /etc to override it as
> you suggest.  So it would become:
>
>  /usr/share/rpminspect/rpminspect.conf (if it exists)
>  /etc/rpminspect/rpminspect.conf (if it exists)
>
> As stated above, I have a pending patch set that will add .rpminspectrc as the
> last one in this list.  That would be read from the directory you invoke
> rpminspect in.  The intent here is to allow package maintainers to add it to
> dist-git for further control of how rpminspect runs in gating.
>
> Then if you specify a profile, it would search dirs in this order:
>
>  /usr/share/rpminspect/profiles
>  /etc/rpminspect/profiles
>
> The vendor data package would stop providing the /etc files.  I'm not opposed
> to this layout.  Is this along the lines of what you're thinking?

Yeah, except with the snippet thing too. Accept partial config
snippets, not just an entire file.


They main way I imagine myself using rpminspect is to have a bunch of
overrides per package, and some "global" Fedora overrides, and to
call rpminspect either during review or for koji builds or when
modifying dist-git. In general I expect the per-package config to live
in dist-git. ".rpminspect" is OK, but a non-hidden file would be even
better. (*)


This makes sense.  My reply to adamw mentioned an ordering I was thinking of:

/usr/share/rpminspect
/etc/rpminspect
.

Where . is the dist-git project.  I was going to go with .rpminspectrc, but I
can name it anything.  Do you have any preferences?


(*) Does rpminspect have access to dist-git contents when run in gating?


Right now it does not, but that is planned pending the config file
restructuring I'm talking about.

Thanks,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: confused by rpminspect automated test

2020-03-16 Thread David Cantrell

On Mon, Mar 09, 2020 at 10:35:03AM -0700, Adam Williamson wrote:

On Mon, 2020-03-09 at 11:49 -0400, David Cantrell wrote:


> > /etc/rpminspect/rpminspect.conf
>
> So that is a global config file...
> RFE: move it under /usr, and only look for overrides in /etc.
> 99% of users should not modify that, and it shouldn't be in /etc.

I disagree.  Users are allowed to edit configuration files in /etc.


True, but Zbigniew isn't wrong either. I think the more modern config
pattern he refers to clearly *is* superior; it's much better for the
standard configuration to be in a 'not-meant-to-be-edited' file in
/usr/share but for the config loading mechanism to look for override
snippets in /etc/rpminspect/conf.d or whatever.

It means the upstream configuration can be updated without local
customizations being lost, and it's much nicer for the sysadmin as
well, for two reasons:

1) If you want to have two different local customizations for different
purposes, you can put them in 01-this.conf and 02-that.conf , with the
names being descriptive. This is *far* easier to understand when you
come back to it in three years than a single monolithic config file
which you *maybe* wrote some comments in.

2) You don't have to read or care about the entire config, your snippet
only needs to have as much in it as you actually want to change.


Sorry, let me clarify.  I like the ".d" layout for letting a group of files
form a valid configuration for a program as well as the override path.  i.e.,
read the system wide default, then local host settings, then per user
settings.  This is a nice way to structure configuration data.

What I was wanting to say is that users and developers should still regard
these files as config files and should be ok editing them to at least figure
out what they should be set to in order to work.  I say this because I don't
want "config file settings should be changed" to be reported as a bug in the
program when it could be a pull request to update the configuration file.  If
we're regarding config files as immutable, then there's no reason to have
them.

So, change the config file around, see what makes it work, then send a pull
request to update it in whatever package delivered it.


As for the location, I could put it with the rest of the vendor-specific data
in /usr/share/rpminspect and allow for the location in /etc to override it as
you suggest.  So it would become:

 /usr/share/rpminspect/rpminspect.conf (if it exists)
 /etc/rpminspect/rpminspect.conf (if it exists)

As stated above, I have a pending patch set that will add .rpminspectrc as the
last one in this list.  That would be read from the directory you invoke
rpminspect in.  The intent here is to allow package maintainers to add it to
dist-git for further control of how rpminspect runs in gating.

Then if you specify a profile, it would search dirs in this order:

 /usr/share/rpminspect/profiles
 /etc/rpminspect/profiles

The vendor data package would stop providing the /etc files.  I'm not opposed
to this layout.  Is this along the lines of what you're thinking?


Yeah, except with the snippet thing too. Accept partial config
snippets, not just an entire file.


Entirely reasonable.  I can restructure things to work this way and allow host
and user overrides.  However, for the latter I think per-project might be more
useful than host overrides since this is the sort of program that doesn't get
value from per-user settings.  It's really per project settings.  So I would
say:

/usr/share/rpminspect
/etc/rpminspect
.

Where . is the dist-git repo you're working on.

I have /etc/rpminspect/rpminspect.conf now.  Suggestions on how I should split
that out and name directories?

Thanks,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: RFC: entering luks password on grub level for devices without keyboards

2020-03-16 Thread Robbie Harwood
Tomasz Torcz  writes:

> On Sun, Mar 15, 2020 at 11:12:43PM +0100, Marius Schwarz wrote:
>> Am 15.03.20 um 13:32 schrieb Vitaly Zaitsev via devel:
>> > On 14.03.2020 13:05, Marius Schwarz wrote:
>> >> If you encrypt  the fedora ( or any ) installation with luks, as
>> >> security of a mobile device indicates, you end up without the
>> >> possibility to enter the password, when you do not have an in/external
>> >> keyboard at hand.
>> > You should use TPM 2.0 LUKS unlock instead of using passwords.
>> >
>> I  knew someone would bring this up:  TMP does not protect your drive,
>> as you could boot with "init=/bin/bash 1" . 
>
>How do you do that WITHOUT KEYBOARD?  This thread is about very
>  specific situation, please do not forget that when generalising.

I believe nothing stops someone from simply plugging one in.

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 33 System-Wide Change proposal: MinGW environment and toolchain update

2020-03-16 Thread Jonathan Wakely

On 16/03/20 11:23 -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/F33MingwEnvToolchainUpdate

== Summary ==
Update the MinGW base environment and toolchain to the latest upstream
stable releases.

== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisan...@gmail.com


== Detailed Description ==

The following packages will be updated

* mingw-gcc to version 10.0.0


That's not a GCC release. Does this mean a 10.0.1 pre-release version
from GCC Git, or the 10.1.0 release that is expected in a few weeks?

___
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: How to fix a dependency to the version at build time?

2020-03-16 Thread Kevin Fenzi
On Mon, Mar 16, 2020 at 10:38:07AM +, Paul Howarth wrote:
> On Mon, 16 Mar 2020 11:22:40 +0100
> Vít Ondruch  wrote:
> > I always thought that one should not call `rpm` during rpmbuild.
> > Nevertheless I am not sure what was the reason? Probably locking of
> > RPM db? Can somebody elaborate?
> 
> It couldn't be guaranteed to work in the case that the buildroot was
> populated using a different version of rpm that used a different
> version of libdb. That's not an issue that crops up much these days as
> libdb hasn't been version-updated for years (due to licensing issues

Except that now we are going to move to sqlite... :) 
(See rpm 4.16 change posted today)

> IIRC) and mock with bootstrap mode enabled would populate the buildroot
> using the target's version of rpm anyway these days.

and koji does not use bootstrap mode. 

kevin


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


Re: s390x build problem again (_rpm.error: error reading package header)

2020-03-16 Thread Kevin Fenzi
On Sat, Mar 14, 2020 at 03:57:09PM -0600, Jerry James wrote:
> On Sat, Mar 14, 2020 at 3:46 PM Dominik 'Rathann' Mierzejewski
>  wrote:
> > My scratch builds are failing on s390x:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=42450592
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=42450600
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=42450608
> > with:
> >
> > _rpm.error: error reading package header
> >
> > Anyone else seeing this?
> 
> That very issue prevented some packages from being built during the
> mass rebuild.  As far as I can tell, builds still have not been done
> for the affected packages:
> 
> https://pagure.io/releng/issue/9220

Yes, I resubmitted all the ones that failed 
(actually, I just did a full second pass and resubmitted everything
that failed in the initial rebuild),

Unfortunately, our messaging plugin/koji does not emit a failed for
these builds (since they failed in src.rpm and never "started"). 

So, we need to figure out some way to identify them before we can
resubmit them. I guess the hope was that maintainers would notice and
just resbumit them, but thats not happened. ;( 

I'll update the ticket and we can try and figure something out. 

kevin


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


[389-devel] Please have a look at rewriters design

2020-03-16 Thread thierry bordaz

Hi,

As a follow up of the PR https://pagure.io/389-ds-base/pull-request/50939,
I wrote down a small design about  rewriters (filter/computed_attr) 
plugin: http://www.port389.org/docs/389ds/design/search_rewriters.html


Comments are welcome

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


Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

2020-03-16 Thread Neal Gompa
On Mon, Mar 16, 2020 at 11:24 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
>
> == Summary ==
> Change format of the RPM database from Berkeley DB to a new Sqlite format.
>
> == Owner ==
> * Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]]
> * Email: pmati...@redhat.com ffe...@redhat.com
>
> == Detailed Description ==
>
> The current rpm database implementation is based on Berkeley DB 5.x, a
> version which is unmaintained upstream for several years now. Berkeley
> DB 6.x is license incompatible so moving to that is not an option. In
> addition, the existing rpmdb implementation is notoriously unreliable
> as it's not transactional and has no other means to detect
> inconsistencies either.
>
> Changing to a more sustainable database implementation is long
> overdue. We propose to change the default rpmdb format to the new
> sqlite based implementation. Support for current BDB format will be
> retained in Fedora 33, and phased out to read-only support in Fedora
> 34.
>
> == Benefit to Fedora ==
>
> * A far more robust rpm database implementation
> * Getting rid of Berkeley DB dependency in one of the core components
>
> == Scope ==
> * Proposal owners:
> ** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial
> shakedown, change the default rpmdb configuration to sqlite
> ** Address any bugs and issues in the database backend found by wider
> testing base
> ** Help other developers to address Berkeley DB dependencies
>
> * Other developers:
> ** Test for hidden Berkeley DB dependencies in other software, address
> them as found and needed
>
> * Release engineering: [https://pagure.io/releng/issue/9308 #9308]
>
> * Policies and guidelines: Policies and guidelines are not affected
>
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
>
> === Upgrading ===
> * Ability to upgrade is not affected
> * After upgrade completes, manual action (rpmdb --rebuilddb) will
> probably be needed to convert to sqlite. Alternatively user can change
> configuration to stay on BDB.
>
> === Compatibility ===
> * Container/chroot use-cases will be affected: older rpm versions will
> be unable to query/manipulate the rpmdb from outside the chroot
> * Koji/COPR may need to override the database format (back to) BDB for
> the time being
>
> == How To Test ==
> * Rpmdb gets thoroughly exercised as a matter of normal system
> operation, performing installs, updates, package builds etc
> * Of specific interest here is torture testing: forcibly killing rpm
> in various stages of execution - database should stay consistent and
> operational (other system state is out of scope)
> * Test database conversions from one backend to another (rpmdb
> --rebuilddb --define "_db_backend ")
>
> == User Experience ==
> * In normal operation, users should see little or no change
> * Behavior in error situations is much more robust: forcibly killed
> transaction no longer causes database inconsistency or corruption
>
> == Dependencies ==
> * This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for
> sqlite rpmdb is not present in older versions
> * RPM will grow a new dependency on sqlite-libs
> * Technically the rpmdb format is an internal implementation detail of
> RPM and the data is only accessible through the librpm API, but some
> software is making assumptions both about the format and/or in
> particular, file naming. These are being tracked at
> https://bugzilla.redhat.com/show_bug.cgi?id=1766120
> * Upgrade tooling could/should perform rpmdb rebuild at end, this
> would be a good thing to do regardless of this change
>
> == Contingency Plan ==
>
> * Contingency mechanism:
> ** Revert the default database back to Berkeley DB backend in the
> package. Running 'rpmdb --rebuilddb' on hosts is currently required to
> actually convert the database, but means to automate conversion in
> specific conditions is being discussed upstream.
> ** The rpm-team does not expect problems with the database backend
> itself, but we are aware that postponing may be needed due to
> infrastructure or other tooling not being ready, primarily due to
> inability to access the database from older releases.
>
> * Contingency deadline: Beta freeze
> * Blocks release? Yes
>
> == Documentation ==
> * [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes]
>
> == Release Notes ==
>
> * After upgrading from an older release, rpm operations will issue
> warnings about database backend configuration not matching what's on
> disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or
> change configuration to stay on Berkeley DB backend (eg 'echo
> %_db_backend bdb > /etc/rpm/macros.db')
> * The details are subject to change, the database rebuild may be done
> by upgrade tooling
>

I'm glad to *finally* see this happen, so congratulations to the RPM
team for finally making this a reality! I look forward to trying this
out in Rawhide as soon as 

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

2020-03-16 Thread updates
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9d364c6070   
cacti-1.2.10-1.el8 cacti-spine-1.2.10-1.el8
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8ce58993d7   
mbedtls-2.16.5-1.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4   
ansible-2.9.6-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1402a55654   
nethack-3.6.6-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d92c8360fe   
chromium-80.0.3987.132-1.el8


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

inxi-3.0.38-1.el8
libslz-1.2.0-2.el8
tweeny-3.1.0-1.el8

Details about builds:



 inxi-3.0.38-1.el8 (FEDORA-EPEL-2020-f13a0de2dd)
 A full featured system information script

Update Information:

Update to 3.0.38.

ChangeLog:

* Mon Mar 16 2020 Vasiliy N. Glazov  - 3.0.38-1
- Update to 3.0.38
* Wed Jan 29 2020 Fedora Release Engineering  - 
3.0.37-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild




 libslz-1.2.0-2.el8 (FEDORA-EPEL-2020-b501595a2a)
 StateLess Zip

Update Information:

Fix the file permissions of the library

ChangeLog:

* Mon Mar 16 2020 Dridi Boukelmoune  - 1.2.0-2
- Fix the file permissions of the library

References:

  [ 1 ] Bug #1785508 - Please build libslz for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=1785508




 tweeny-3.1.0-1.el8 (FEDORA-EPEL-2020-2ebe812f0d)
 Modern C++ tweening library

Update Information:

Updated to version 3.1.0.

ChangeLog:

* Sun Mar 15 2020 Vitaly Zaitsev  - 3.1.0-1
- Updated to version 3.1.0.
* Fri Jan 31 2020 Fedora Release Engineering  - 3-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_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


Summary/Minutes from today's FESCo Meeting (2020-03-16)

2020-03-16 Thread Zbigniew Jędrzejewski-Szmek

Meeting started by zbyszek at 15:00:56 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-03-16/fesco.2020-03-16-15.00.log.html
.

Meeting summary
---
* init process  (zbyszek, 15:00:59)

* #2356 Fedora 31: Reset eclipse stream for all (once) or leave the
  bugzilla unfixed?  (zbyszek, 15:05:56)
  * AGREED: Reset is approved (with details to be written up) (+5, 0, 0)
(zbyszek, 15:21:12)
The wiki page should be linked from a message emitted by the scriptlet,
and the reset should be announced to fedora-devel a few days before
the package with the resetting scriptlet is pushed out.

  * ACTION: sgallagh to submit PR for fedora-release to implement the
reset.  (sgallagh, 15:21:43)
  * ACTION: zbyszek to write up available options in the wiki  (zbyszek,
15:23:24)

* #2354 32-bit ARM installer release-blocking status unclear
  * AGREED: Option 1 is approved (+7, 0, 0)  (zbyszek, 15:32:00)
  * ACTION: bcotton to update the wiki or reassign to the next
"volunteer"  (zbyszek, 15:35:04)

* Next week's chair  (zbyszek, 15:35:19)
  * ACTION: zbyszek will chair the next meeting  (zbyszek, 15:35:33)

* Open Floor  (zbyszek, 15:35:41)
  * ACTION: bookwar to write up #2284  (zbyszek, 15:39:34)

Meeting ended at 15:52:36 UTC.


Action Items

* sgallagh to submit PR for fedora-release to implement the reset (for #2356)
* zbyszek to write up available options in the wiki (for #2356)
* bcotton to update the wiki or reassign to the next "volunteer"  (for #2354)
* zbyszek will chair the next meeting
* bookwar to write up #2284
___
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: HEADS UP: repoquery --whatrequires yields incomplete results when run from Fedora 32+

2020-03-16 Thread Fabio Valentini
On Wed, Mar 11, 2020 at 5:26 PM Miro Hrončok  wrote:
>
> I have upgraded to Fedora 32 today and after a while I have noticed that
> `repoquery --whatrequires` yields incomplete results.
>
>  From Fedora 31:
>
> $ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires 
> python3-flaky
> pipenv-0:2018.11.26-13.fc32.src
> python-ipykernel-0:5.1.4-1.fc33.src
>
>
>  From Fedora 32/33:
>
> $ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires 
> python3-flaky
> python-ipykernel-0:5.1.4-1.fc33.src
>
>
> I have reported this here: https://bugzilla.redhat.com/show_bug.cgi?id=1812596
>
>
> Be extra careful when taking decisions based on `repoquery --whatrequires` 
> (such
> as: I can safely retire this or upgrade that, nothing else requires it).

Can confirm this issue on fedora 32.
It's now one of the reasons why I haven't upgraded my main machine to f32 yet :/
Looks like "--alldeps" no longer works correctly (neither implicitly
or explicitly).

Fabio

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[389-devel] please review: PR 50958 - buldnum.py - fix date formatting issue

2020-03-16 Thread Mark Reynolds

https://pagure.io/389-ds-base/pull-request/50958

--

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


Fedora 33 System-Wide Change proposal: MinGW environment and toolchain update

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/F33MingwEnvToolchainUpdate

== Summary ==
Update the MinGW base environment and toolchain to the latest upstream
stable releases.

== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisan...@gmail.com


== Detailed Description ==

The following packages will be updated

* mingw-gcc to version 10.0.0
* mingw-w64-tools to version 7.0.0
* mingw-winpthreads to version 7.0.0
* mingw-crt to version 7.0.0
* mingw-headers to version 7.0.0
* mingw-binutils to version 2.34
* mingw-gdb to version 9.1

== Benefit to Fedora ==

Ship the latest available MinGW environment and GNU toolchain.

== Scope ==
* Proposal owners:
The above mentioned packages will be updated. Build failures following
the mass rebuild will be inspected.

* Other developers:
Help with build failures may be requested.

* Release engineering: Impact check [https://pagure.io/releng/issue/9253]
* Release engineering: Mass rebuild requested
* Policies and guidelines: No policies need to be changed

== Upgrade/compatibility impact ==
No impact

== How To Test ==
Update the system once the updated packages land, look out for new
build failures etc.

== User Experience ==
The features of the newest MinGW environment and GNU Toolchain will be
available to the users.

== Dependencies ==
None

== Contingency Plan ==
* Contingency mechanism: Revert to older versions of environment /
toolchain, mass rebuild mingw packages again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

== Release Notes ==
Fedora 33 comes with the mingw-w64-7.0.0 environment, mingw-gcc-10,
mingw-gdb-9.1 and mingw-binutils 2.34.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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-announce@lists.fedoraproject.org


Fedora 33 System-Wide Change proposal: GNU Make version 4.3

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/MAKE43

== Summary ==

Rebase GNU make in Fedora 33 from make version 4.2 to make version 4.3.

== Owner ==

* Name: [[User:djdelorie| DJ Delorie]]
* Email: d...@redhat.com

== Detailed Description ==
Make 4.3 was released on January 19th 2020.  It includes many bug
fixes and new features.  Fedora has been carrying many patches to the
4.2 release which are included in 4.3, reducing the workload for
Fedora builders.

Note that Fedora is also carrying some patches to retain compatibility
with make version 3.8, as an aid to packages which needed time to
adapt to make version 4.  These compatibility patches will be removed
in this rebase, making Fedora's make the same as other distros.  Some
packages may FTBFS and need help tweaking their Makefiles.

== Benefit to Fedora ==

Stay up to date with upstream GNU make, make sure we have the latest
bug fixes et al, be compatible with stock GNU make.

== Scope ==
* Proposal owners: Update to GNU make 4.3

* Other developers: Package owners relying on makefile features
specific to older versions of GNU make (including compatibility
patches for 3.8 we're dropping) may FTBFS and need to tweak their
Makefiles.

* Release engineering:  (a check of an impact with Release Engineering
is pending)

* Policies and guidelines: The policies and guidelines do not need to
be updated.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

Users who have local projects using GNU make, which rely on features
only available in older versions of GNU make, may need to tweak their
Makefiles before rebuilding.  Packages which were built previous to
this upgrade will not be affected.

Specific backwards incompatibilities as called out in the NEWS file
for make 4.3:


* WARNING: Backward-incompatibility!
  Number signs (#) appearing inside a macro reference or function invocation
  no longer introduce comments and should not be escaped with backslashes:
  thus a call such as:
foo := $(shell echo '#')
  is legal.  Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
  Now this latter will resolve to "\#".  If you want to write makefiles
  portable to both versions, assign the number sign to a variable:
H := \#
foo := $(shell echo '$H')
  This was claimed to be fixed in 3.81, but wasn't, for some reason.
  To detect this change search for 'nocomment' in the .FEATURES variable.

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.


== How To Test ==

GNU make has its own testsuite and does not require specific hardware
or testing outside of building the RPM.

== User Experience ==

Users will get all bugfixes included in make 4.3 as well as any new
features therein.  The make 4.3 NEWS update will include more details.

== Dependencies ==

No dependencies.

== Contingency Plan ==

* Contingency mechanism: Revert to make 4.2.1
* Contingency deadline: Beta freeze.  If there is a mass rebuild,
preferably before then.
* Blocks release? No

== Documentation ==

GNU Make includes its own documentation.  No additional documentation
work is required.

== Release Notes ==

Full release notes can be found in make's NEWS file:
http://git.savannah.gnu.org/cgit/make.git/tree/NEWS

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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-announce@lists.fedoraproject.org


Fedora 33 System-Wide Change proposal: RPM 4.16

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/RPM-4.16

== Summary ==
Update RPM to the 4.16.0 release.

== Owner ==
* Name: User:pmatilai, User:ffesti

* Email: pmati...@redhat.com,ffe...@redhat.com

== Detailed Description ==

RPM 4.16 contains numerous improvements over previous versions
* New database backends and related developments to enable moving away
from Berkeley DB
** experimental sqlite backend
** experimental readonly-bdb backend to support conversion from BDB
without the library
** ndb backend promoted out of experimental
* Much improved expression parser (specs and macros)
* Powerful new macro features (expressions, ternary operator, literal
macros, access to macro body, eliminate unexpected double-expansion
etc)
* Support for macro-only dependency generators (very fast as fork+exec
is entirely avoided)
* Support for meta dependencies (which do not affect ordering)
* Transparent verification support for alternative (ie uncompressed)
payload digest (so deltarpm doesn't need to recompress)
* Automatic SSD detection and optimization

Rawhide rpm will be updated to 4.16 alpha once feature is approved and
updated through
beta and rc cycles, 4.16.0 final release is expected before to F33 beta freeze.

== Benefit to Fedora ==

See above for overall benefits, but most importantly this is the first
major step towards moving away from Berkeley DB based rpmdb. The
database format will not change in this release, but this release
enables wider testing of the new backend(s) and related features such
as switching from one backend to another. In particular it enables
testing of *other software* for compatibility and interoperability
with non-BDB databases. The change of database format is not a part of
this change.

== Scope ==
* Proposal owners:
** Rebase RPM

* Other developers:
** Test new release, report issues and bugs
** Test compatibility of other software with different rpmdb format
(containers, build-systems and such in particular)

* Release engineering: [https://pagure.io/releng/issue/9286 #9286]
* Policies and guidelines: As always, utilizing new rpm features is
subject to packaging guidelines, but the time for this is after the
new version has properly landed. Guideline updates should not be
necessary.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* Similar to compiler updates, some previously working specs might
fail to build due to stricter error checking and the like. In
particular, barewords (ie non-quoted strings) in expressions are no
longer supported.

== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.

The prime testing target should revolve around database functionality,
robustness and compatibility with other software. There's a
[https://bugzilla.redhat.com/show_bug.cgi?id=1766120 tracking bug] for
Berkeley DB format dependencies.

Details on database testing to be supplied later.

== User Experience ==
There are no significant user experience changes by default, but a
significant increase in overall robustness is expected with non-BDB
databases.

== Dependencies ==
* A soname bump is involved so all API-dependent packages will need a rebuild
* Rpm will grow an additional dependency on sqlite

== Contingency Plan ==

* Contingency mechanism: Roll back to rpm 4.15, but the chance of
having to do should be negligible
* Contingency deadline: Beta freeze.
* Blocks release? No


== Documentation ==
Draft release notes are available at https://rpm.org/wiki/Releases/4.16.0

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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-announce@lists.fedoraproject.org


Fedora 33 System-Wide Change proposal: Sqlite RpmDB

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb

== Summary ==
Change format of the RPM database from Berkeley DB to a new Sqlite format.

== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]]
* Email: pmati...@redhat.com ffe...@redhat.com

== Detailed Description ==

The current rpm database implementation is based on Berkeley DB 5.x, a
version which is unmaintained upstream for several years now. Berkeley
DB 6.x is license incompatible so moving to that is not an option. In
addition, the existing rpmdb implementation is notoriously unreliable
as it's not transactional and has no other means to detect
inconsistencies either.

Changing to a more sustainable database implementation is long
overdue. We propose to change the default rpmdb format to the new
sqlite based implementation. Support for current BDB format will be
retained in Fedora 33, and phased out to read-only support in Fedora
34.

== Benefit to Fedora ==

* A far more robust rpm database implementation
* Getting rid of Berkeley DB dependency in one of the core components

== Scope ==
* Proposal owners:
** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial
shakedown, change the default rpmdb configuration to sqlite
** Address any bugs and issues in the database backend found by wider
testing base
** Help other developers to address Berkeley DB dependencies

* Other developers:
** Test for hidden Berkeley DB dependencies in other software, address
them as found and needed

* Release engineering: [https://pagure.io/releng/issue/9308 #9308]

* Policies and guidelines: Policies and guidelines are not affected

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

=== Upgrading ===
* Ability to upgrade is not affected
* After upgrade completes, manual action (rpmdb --rebuilddb) will
probably be needed to convert to sqlite. Alternatively user can change
configuration to stay on BDB.

=== Compatibility ===
* Container/chroot use-cases will be affected: older rpm versions will
be unable to query/manipulate the rpmdb from outside the chroot
* Koji/COPR may need to override the database format (back to) BDB for
the time being

== How To Test ==
* Rpmdb gets thoroughly exercised as a matter of normal system
operation, performing installs, updates, package builds etc
* Of specific interest here is torture testing: forcibly killing rpm
in various stages of execution - database should stay consistent and
operational (other system state is out of scope)
* Test database conversions from one backend to another (rpmdb
--rebuilddb --define "_db_backend ")

== User Experience ==
* In normal operation, users should see little or no change
* Behavior in error situations is much more robust: forcibly killed
transaction no longer causes database inconsistency or corruption

== Dependencies ==
* This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for
sqlite rpmdb is not present in older versions
* RPM will grow a new dependency on sqlite-libs
* Technically the rpmdb format is an internal implementation detail of
RPM and the data is only accessible through the librpm API, but some
software is making assumptions both about the format and/or in
particular, file naming. These are being tracked at
https://bugzilla.redhat.com/show_bug.cgi?id=1766120
* Upgrade tooling could/should perform rpmdb rebuild at end, this
would be a good thing to do regardless of this change

== Contingency Plan ==

* Contingency mechanism:
** Revert the default database back to Berkeley DB backend in the
package. Running 'rpmdb --rebuilddb' on hosts is currently required to
actually convert the database, but means to automate conversion in
specific conditions is being discussed upstream.
** The rpm-team does not expect problems with the database backend
itself, but we are aware that postponing may be needed due to
infrastructure or other tooling not being ready, primarily due to
inability to access the database from older releases.

* Contingency deadline: Beta freeze
* Blocks release? Yes

== Documentation ==
* [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes]

== Release Notes ==

* After upgrading from an older release, rpm operations will issue
warnings about database backend configuration not matching what's on
disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or
change configuration to stay on Berkeley DB backend (eg 'echo
%_db_backend bdb > /etc/rpm/macros.db')
* The details are subject to change, the database rebuild may be done
by upgrade tooling


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

Fedora 33 System-Wide Change proposal: Strong crypto settings: phase 2

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

== Summary ==
We update the current system-wide crypto policy to further disable
legacy cryptographic protocols (TLS 1.0 and TLS 1.1), weak
Diffie-Hellman key exchange sizes (1024 bit), and use of the SHA-1
hash in signatures.

== Owner ==
* Name: [[User:tmraz|Tomáš Mráz]]
* Email: 


== Detailed Description ==

Fedora includes several cryptographic components who's security
doesn't remain constant over time. Algorithms such as (cryptographic)
hashing and encryption typically have a lifetime after which they are
considered either too risky to use or plain insecure. That would mean
we need to phase out such algorithms from the default settings, or
completely disable if they could cause irreparable issue.

While in the past we did not disable algorithms in a consistent way
(different applications utilized different policies), today we have a
system-wide policy followed by a large part of Fedora components. That
allows us to move consistently and deprecate algorithms system-wide.
For rationale see RFC 7457 for a more complete list of attacks taking
advantage of legacy crypto algorithms.

The changes for default policy are:
 * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols
and move the TLS 1.x, x<=1 to legacy level.
 * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and
more in the default settings
 * Disable SHA1 support for use in signatures (X.509 certificates,
TLS, IPSEC handshakes)


That is a policy of:
 LEGACY
  MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
  Curves: all prime >= 255 bits (including bernstein curves)
  Signature algorithms: SHA-1 hash or better (not RIPEMD)
  Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES)
  key exchange: ECDHE, RSA, DHE
  DH params size: >=1023
  RSA params size: >=1023
  TLS protocols: TLS >= 1.0

 DEFAULT
  MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
  Curves: all prime >= 255 bits (including bernstein curves)
  Signature algorithms: with SHA-256 hash or better (not DSA)
  Ciphers: >= 128-bit key, >= 128-bit block (aes, chacha20, including aes-cbc)
  key exchange: ECDHE, RSA, DHE
  DH params size: >= 2048
  RSA params size: >= 2048
  TLS protocols: TLS >= 1.2

 FUTURE
  MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
  Curves: all prime >= 255 bits (including bernstein curves)
  Signature algorithms: SHA-256 hash or better (not DSA)
  Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated
Encryption (AE) ciphers
  key exchange: ECDHE, DHE
  DH params size: >= 3072
  RSA params size: >= 3072
  TLS protocols: TLS >= 1.2


== Benefit to Fedora ==

With this change we protect users from relying on enabled-by-default
weak cryptography, as well as reduce our maintenance cost for future
attacks that rely on weak crypto for exploitation.

Also please note that Firefox is also moving to similar default crypto
settings with the current releases (Firefox 74)
[https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/].

== Scope ==
* Proposal owners:
The policies include in crypto-policies package need to be updated.

* Other developers:
 * Crypto policies are updated to the settings above

* Release engineering: Copied from F28 change - no impact
[https://pagure.io/releng/issue/7235 #7235] (a check of an impact with
Release Engineering is needed)

 * Crypto policies are updated to the settings above
 * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora
Crypto Policies follow the new crypto settings.

* Policies and guidelines:
No changes to packaging or other guidelines is needed.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
It may be that the new settings break software that connects to
servers which utilize weak algorithms. Compatibility can be obtained
by switching the system to legacy policy level as follows.

 update-crypto-policies --set LEGACY


== How To Test ==

Applications which follow the system-wide policy (e.g., curl,wget)
should be tested:
 * whether they can connect to legacy (TLS1.0, TLS1.1) servers when
system is in legacy mode
 * whether the previous connection breaks when system is in default mode
 * whether the system can connect to TLS 1.2 servers when in default,
legacy or future mode.


== User Experience ==
Given the existing deployment of TLS 1.2 on the internet, there should
not be significant user experience degradation, although that's a
speculation.

== Dependencies ==
 * nss
 * gnutls
 * openssl
 * crypto-policies


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?)
If we notice significant user experience degradation, e.g., due to
many custom servers utilizing legacy protocols, we should consider
postponing or reducing the number of updates in that change. The
change owner will take care of this.
* Contingency deadline: beta freeze

* Blocks 

Fedora 33 System-Wide Change proposal: MinGW environment and toolchain update

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/F33MingwEnvToolchainUpdate

== Summary ==
Update the MinGW base environment and toolchain to the latest upstream
stable releases.

== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisan...@gmail.com


== Detailed Description ==

The following packages will be updated

* mingw-gcc to version 10.0.0
* mingw-w64-tools to version 7.0.0
* mingw-winpthreads to version 7.0.0
* mingw-crt to version 7.0.0
* mingw-headers to version 7.0.0
* mingw-binutils to version 2.34
* mingw-gdb to version 9.1

== Benefit to Fedora ==

Ship the latest available MinGW environment and GNU toolchain.

== Scope ==
* Proposal owners:
The above mentioned packages will be updated. Build failures following
the mass rebuild will be inspected.

* Other developers:
Help with build failures may be requested.

* Release engineering: Impact check [https://pagure.io/releng/issue/9253]
* Release engineering: Mass rebuild requested
* Policies and guidelines: No policies need to be changed

== Upgrade/compatibility impact ==
No impact

== How To Test ==
Update the system once the updated packages land, look out for new
build failures etc.

== User Experience ==
The features of the newest MinGW environment and GNU Toolchain will be
available to the users.

== Dependencies ==
None

== Contingency Plan ==
* Contingency mechanism: Revert to older versions of environment /
toolchain, mass rebuild mingw packages again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

== Release Notes ==
Fedora 33 comes with the mingw-w64-7.0.0 environment, mingw-gcc-10,
mingw-gdb-9.1 and mingw-binutils 2.34.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Fedora 33 System-Wide Change proposal: GNU Make version 4.3

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/MAKE43

== Summary ==

Rebase GNU make in Fedora 33 from make version 4.2 to make version 4.3.

== Owner ==

* Name: [[User:djdelorie| DJ Delorie]]
* Email: d...@redhat.com

== Detailed Description ==
Make 4.3 was released on January 19th 2020.  It includes many bug
fixes and new features.  Fedora has been carrying many patches to the
4.2 release which are included in 4.3, reducing the workload for
Fedora builders.

Note that Fedora is also carrying some patches to retain compatibility
with make version 3.8, as an aid to packages which needed time to
adapt to make version 4.  These compatibility patches will be removed
in this rebase, making Fedora's make the same as other distros.  Some
packages may FTBFS and need help tweaking their Makefiles.

== Benefit to Fedora ==

Stay up to date with upstream GNU make, make sure we have the latest
bug fixes et al, be compatible with stock GNU make.

== Scope ==
* Proposal owners: Update to GNU make 4.3

* Other developers: Package owners relying on makefile features
specific to older versions of GNU make (including compatibility
patches for 3.8 we're dropping) may FTBFS and need to tweak their
Makefiles.

* Release engineering:  (a check of an impact with Release Engineering
is pending)

* Policies and guidelines: The policies and guidelines do not need to
be updated.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

Users who have local projects using GNU make, which rely on features
only available in older versions of GNU make, may need to tweak their
Makefiles before rebuilding.  Packages which were built previous to
this upgrade will not be affected.

Specific backwards incompatibilities as called out in the NEWS file
for make 4.3:


* WARNING: Backward-incompatibility!
  Number signs (#) appearing inside a macro reference or function invocation
  no longer introduce comments and should not be escaped with backslashes:
  thus a call such as:
foo := $(shell echo '#')
  is legal.  Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
  Now this latter will resolve to "\#".  If you want to write makefiles
  portable to both versions, assign the number sign to a variable:
H := \#
foo := $(shell echo '$H')
  This was claimed to be fixed in 3.81, but wasn't, for some reason.
  To detect this change search for 'nocomment' in the .FEATURES variable.

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.


== How To Test ==

GNU make has its own testsuite and does not require specific hardware
or testing outside of building the RPM.

== User Experience ==

Users will get all bugfixes included in make 4.3 as well as any new
features therein.  The make 4.3 NEWS update will include more details.

== Dependencies ==

No dependencies.

== Contingency Plan ==

* Contingency mechanism: Revert to make 4.2.1
* Contingency deadline: Beta freeze.  If there is a mass rebuild,
preferably before then.
* Blocks release? No

== Documentation ==

GNU Make includes its own documentation.  No additional documentation
work is required.

== Release Notes ==

Full release notes can be found in make's NEWS file:
http://git.savannah.gnu.org/cgit/make.git/tree/NEWS

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Fedora 33 System-Wide Change proposal: RPM 4.16

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/RPM-4.16

== Summary ==
Update RPM to the 4.16.0 release.

== Owner ==
* Name: User:pmatilai, User:ffesti

* Email: pmati...@redhat.com,ffe...@redhat.com

== Detailed Description ==

RPM 4.16 contains numerous improvements over previous versions
* New database backends and related developments to enable moving away
from Berkeley DB
** experimental sqlite backend
** experimental readonly-bdb backend to support conversion from BDB
without the library
** ndb backend promoted out of experimental
* Much improved expression parser (specs and macros)
* Powerful new macro features (expressions, ternary operator, literal
macros, access to macro body, eliminate unexpected double-expansion
etc)
* Support for macro-only dependency generators (very fast as fork+exec
is entirely avoided)
* Support for meta dependencies (which do not affect ordering)
* Transparent verification support for alternative (ie uncompressed)
payload digest (so deltarpm doesn't need to recompress)
* Automatic SSD detection and optimization

Rawhide rpm will be updated to 4.16 alpha once feature is approved and
updated through
beta and rc cycles, 4.16.0 final release is expected before to F33 beta freeze.

== Benefit to Fedora ==

See above for overall benefits, but most importantly this is the first
major step towards moving away from Berkeley DB based rpmdb. The
database format will not change in this release, but this release
enables wider testing of the new backend(s) and related features such
as switching from one backend to another. In particular it enables
testing of *other software* for compatibility and interoperability
with non-BDB databases. The change of database format is not a part of
this change.

== Scope ==
* Proposal owners:
** Rebase RPM

* Other developers:
** Test new release, report issues and bugs
** Test compatibility of other software with different rpmdb format
(containers, build-systems and such in particular)

* Release engineering: [https://pagure.io/releng/issue/9286 #9286]
* Policies and guidelines: As always, utilizing new rpm features is
subject to packaging guidelines, but the time for this is after the
new version has properly landed. Guideline updates should not be
necessary.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* Similar to compiler updates, some previously working specs might
fail to build due to stricter error checking and the like. In
particular, barewords (ie non-quoted strings) in expressions are no
longer supported.

== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.

The prime testing target should revolve around database functionality,
robustness and compatibility with other software. There's a
[https://bugzilla.redhat.com/show_bug.cgi?id=1766120 tracking bug] for
Berkeley DB format dependencies.

Details on database testing to be supplied later.

== User Experience ==
There are no significant user experience changes by default, but a
significant increase in overall robustness is expected with non-BDB
databases.

== Dependencies ==
* A soname bump is involved so all API-dependent packages will need a rebuild
* Rpm will grow an additional dependency on sqlite

== Contingency Plan ==

* Contingency mechanism: Roll back to rpm 4.15, but the chance of
having to do should be negligible
* Contingency deadline: Beta freeze.
* Blocks release? No


== Documentation ==
Draft release notes are available at https://rpm.org/wiki/Releases/4.16.0

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Fedora 33 System-Wide Change proposal: Sqlite RpmDB

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb

== Summary ==
Change format of the RPM database from Berkeley DB to a new Sqlite format.

== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]]
* Email: pmati...@redhat.com ffe...@redhat.com

== Detailed Description ==

The current rpm database implementation is based on Berkeley DB 5.x, a
version which is unmaintained upstream for several years now. Berkeley
DB 6.x is license incompatible so moving to that is not an option. In
addition, the existing rpmdb implementation is notoriously unreliable
as it's not transactional and has no other means to detect
inconsistencies either.

Changing to a more sustainable database implementation is long
overdue. We propose to change the default rpmdb format to the new
sqlite based implementation. Support for current BDB format will be
retained in Fedora 33, and phased out to read-only support in Fedora
34.

== Benefit to Fedora ==

* A far more robust rpm database implementation
* Getting rid of Berkeley DB dependency in one of the core components

== Scope ==
* Proposal owners:
** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial
shakedown, change the default rpmdb configuration to sqlite
** Address any bugs and issues in the database backend found by wider
testing base
** Help other developers to address Berkeley DB dependencies

* Other developers:
** Test for hidden Berkeley DB dependencies in other software, address
them as found and needed

* Release engineering: [https://pagure.io/releng/issue/9308 #9308]

* Policies and guidelines: Policies and guidelines are not affected

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

=== Upgrading ===
* Ability to upgrade is not affected
* After upgrade completes, manual action (rpmdb --rebuilddb) will
probably be needed to convert to sqlite. Alternatively user can change
configuration to stay on BDB.

=== Compatibility ===
* Container/chroot use-cases will be affected: older rpm versions will
be unable to query/manipulate the rpmdb from outside the chroot
* Koji/COPR may need to override the database format (back to) BDB for
the time being

== How To Test ==
* Rpmdb gets thoroughly exercised as a matter of normal system
operation, performing installs, updates, package builds etc
* Of specific interest here is torture testing: forcibly killing rpm
in various stages of execution - database should stay consistent and
operational (other system state is out of scope)
* Test database conversions from one backend to another (rpmdb
--rebuilddb --define "_db_backend ")

== User Experience ==
* In normal operation, users should see little or no change
* Behavior in error situations is much more robust: forcibly killed
transaction no longer causes database inconsistency or corruption

== Dependencies ==
* This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for
sqlite rpmdb is not present in older versions
* RPM will grow a new dependency on sqlite-libs
* Technically the rpmdb format is an internal implementation detail of
RPM and the data is only accessible through the librpm API, but some
software is making assumptions both about the format and/or in
particular, file naming. These are being tracked at
https://bugzilla.redhat.com/show_bug.cgi?id=1766120
* Upgrade tooling could/should perform rpmdb rebuild at end, this
would be a good thing to do regardless of this change

== Contingency Plan ==

* Contingency mechanism:
** Revert the default database back to Berkeley DB backend in the
package. Running 'rpmdb --rebuilddb' on hosts is currently required to
actually convert the database, but means to automate conversion in
specific conditions is being discussed upstream.
** The rpm-team does not expect problems with the database backend
itself, but we are aware that postponing may be needed due to
infrastructure or other tooling not being ready, primarily due to
inability to access the database from older releases.

* Contingency deadline: Beta freeze
* Blocks release? Yes

== Documentation ==
* [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes]

== Release Notes ==

* After upgrading from an older release, rpm operations will issue
warnings about database backend configuration not matching what's on
disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or
change configuration to stay on Berkeley DB backend (eg 'echo
%_db_backend bdb > /etc/rpm/macros.db')
* The details are subject to change, the database rebuild may be done
by upgrade tooling


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

Fedora 33 System-Wide Change proposal: Strong crypto settings: phase 2

2020-03-16 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

== Summary ==
We update the current system-wide crypto policy to further disable
legacy cryptographic protocols (TLS 1.0 and TLS 1.1), weak
Diffie-Hellman key exchange sizes (1024 bit), and use of the SHA-1
hash in signatures.

== Owner ==
* Name: [[User:tmraz|Tomáš Mráz]]
* Email: 


== Detailed Description ==

Fedora includes several cryptographic components who's security
doesn't remain constant over time. Algorithms such as (cryptographic)
hashing and encryption typically have a lifetime after which they are
considered either too risky to use or plain insecure. That would mean
we need to phase out such algorithms from the default settings, or
completely disable if they could cause irreparable issue.

While in the past we did not disable algorithms in a consistent way
(different applications utilized different policies), today we have a
system-wide policy followed by a large part of Fedora components. That
allows us to move consistently and deprecate algorithms system-wide.
For rationale see RFC 7457 for a more complete list of attacks taking
advantage of legacy crypto algorithms.

The changes for default policy are:
 * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols
and move the TLS 1.x, x<=1 to legacy level.
 * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and
more in the default settings
 * Disable SHA1 support for use in signatures (X.509 certificates,
TLS, IPSEC handshakes)


That is a policy of:
 LEGACY
  MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
  Curves: all prime >= 255 bits (including bernstein curves)
  Signature algorithms: SHA-1 hash or better (not RIPEMD)
  Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES)
  key exchange: ECDHE, RSA, DHE
  DH params size: >=1023
  RSA params size: >=1023
  TLS protocols: TLS >= 1.0

 DEFAULT
  MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
  Curves: all prime >= 255 bits (including bernstein curves)
  Signature algorithms: with SHA-256 hash or better (not DSA)
  Ciphers: >= 128-bit key, >= 128-bit block (aes, chacha20, including aes-cbc)
  key exchange: ECDHE, RSA, DHE
  DH params size: >= 2048
  RSA params size: >= 2048
  TLS protocols: TLS >= 1.2

 FUTURE
  MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
  Curves: all prime >= 255 bits (including bernstein curves)
  Signature algorithms: SHA-256 hash or better (not DSA)
  Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated
Encryption (AE) ciphers
  key exchange: ECDHE, DHE
  DH params size: >= 3072
  RSA params size: >= 3072
  TLS protocols: TLS >= 1.2


== Benefit to Fedora ==

With this change we protect users from relying on enabled-by-default
weak cryptography, as well as reduce our maintenance cost for future
attacks that rely on weak crypto for exploitation.

Also please note that Firefox is also moving to similar default crypto
settings with the current releases (Firefox 74)
[https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/].

== Scope ==
* Proposal owners:
The policies include in crypto-policies package need to be updated.

* Other developers:
 * Crypto policies are updated to the settings above

* Release engineering: Copied from F28 change - no impact
[https://pagure.io/releng/issue/7235 #7235] (a check of an impact with
Release Engineering is needed)

 * Crypto policies are updated to the settings above
 * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora
Crypto Policies follow the new crypto settings.

* Policies and guidelines:
No changes to packaging or other guidelines is needed.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
It may be that the new settings break software that connects to
servers which utilize weak algorithms. Compatibility can be obtained
by switching the system to legacy policy level as follows.

 update-crypto-policies --set LEGACY


== How To Test ==

Applications which follow the system-wide policy (e.g., curl,wget)
should be tested:
 * whether they can connect to legacy (TLS1.0, TLS1.1) servers when
system is in legacy mode
 * whether the previous connection breaks when system is in default mode
 * whether the system can connect to TLS 1.2 servers when in default,
legacy or future mode.


== User Experience ==
Given the existing deployment of TLS 1.2 on the internet, there should
not be significant user experience degradation, although that's a
speculation.

== Dependencies ==
 * nss
 * gnutls
 * openssl
 * crypto-policies


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?)
If we notice significant user experience degradation, e.g., due to
many custom servers utilizing legacy protocols, we should consider
postponing or reducing the number of updates in that change. The
change owner will take care of this.
* Contingency deadline: beta freeze

* Blocks 

[Bug 1813603] perl-Module-CoreList-5.20200314 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813603



--- Comment #5 from Fedora Update System  ---
perl-Module-CoreList-5.20200314-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-419e3082ee

-- 
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 1813602] perl-CPAN-Perl-Releases-5.20200314 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813602



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200314-1.fc30 has been pushed to the Fedora 30
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0b03b12929

-- 
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 1813603] perl-Module-CoreList-5.20200314 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813603



--- Comment #4 from Fedora Update System  ---
perl-Module-CoreList-5.20200314-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-47f1b57e23

-- 
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 1813602] perl-CPAN-Perl-Releases-5.20200314 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813602



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200314-1.fc31 has been pushed to the Fedora 31
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf95f89bd2

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


Embedded font support for PDFs is lacking; response to: Fonts packaging guidelines change status

2020-03-16 Thread R P Herrold

Subject: Fonts packaging guidelines change status

On Sat, 7 Mar 2020, Nicolas Mailhot wrote:

> WHAT IS IT ALL ABOUT
> 
> On 2020-02-13, FPC approved a rewrite of our fonts packaging
> guidelines.

and again that was published on the 14th removing some top 
matter through the Section mark: NEW PACKAGES STILL PENDING 
REVIEW, and advancing PR status on a couple of fonts

But this question in the fonts-list was not addressed (see 
the bottom of this resend to include the devel list):

Is a formal 'bug' needed to track this ?


Background:

That re-write draft as included does not address PDF 
portability

The Fedora most recent prior approach on fonts neglected 
explicitly supporting the need of Latex chain created 
documents for type 1 fonts to be embedded in PDFs.  

From raising this issue previously, it is my understanding 
that Type 1 fonts are felt to not screen render as well as 
some later alternatives, but when it comes to generating a 
Portable Document to reliably render 'the same', one HAS to 
carry and prefer embedded fonts when present


Detection of the issue, and Problem summarized:

When one is missing fonts, and runs something like:

dvips -t letter -Ppdf -G0 -j0 mypaper.dvi \
-o mypaper.ps

one will get a 'missfont.log' as to an inability to embed a 
required font, 'required' for completeness for portability 
purposes 


See the discussion at:
https://helpx.adobe.com/acrobat/using/pdf-fonts.html

and its practical implication is discussed at:
https://blogs.adobe.com/acrolaw/2007/11/pdf_creation_and_font_embedding/


The TL;DR takeaway is:

The USPTO requires that PDF must be:

Acrobat 4 (PDF 1.3) or higher
(See note at end of article)
No larger than 8.5? by 11? or A4 page size
Have all fonts embedded and subset


It is not JUST preparation of documents for filing there, but 
also for submitting 'camera ready PDF copy' to Lulu print on 
demand.  Lulu is a child of Robert Young [a serial 
entrepreneur who is best known for founding Red Hat Inc]

https://connect.lulu.com/en/discussion/33148


https://connect.lulu.com/en/discussion/33681/pdf-creation-settings-how-can-i-be-sure-my-pdf-will-print-correctly

pull requirement: All fonts should be converted 
to outlines and embedded 


Way forward:

There is a collection of 13 fonts provided under a freely 
reproducible license from Adobe, known as the Base 13 fonts

- Courier, Courier-Bold, Courier-Oblique & Courier-BoldOblique
- Times-Roman , Times-Bold , Times-Italic & Times-BoldItalic
- Helvetica, Helvetica-Bold, Helvetica-Oblique & 
Helvetica-BoldOblique
- Symbol

[ but not: - ZapfDingbats ]


I understand that they were removed from Fedora, as the Base 
13 are Type 1 fonts  but dang it, at least for purposes of 
completeness to be able to generate legal documents, and to 
permit me to continue to use FOSS tools to publish for 
fulfillment at Lulu, can we get these Type 1 fonts back, 
regardless of slight risk of aesthetic discontent ?


Is a formal 'bug' needed to track this ?

Thank you

-- Russ herrold
___
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 32 compose report: 20200316.n.0 changes

2020-03-16 Thread Fedora Branched Report
OLD: Fedora-32-20200315.n.0
NEW: Fedora-32-20200316.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-32-20200316.n.0.ppc64le.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
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 1813720] perl-Pod-Usage-1.70 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813720



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-0acf97c1e1 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0acf97c1e1

-- 
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 1813720] perl-Pod-Usage-1.70 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813720



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

-- 
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 1813602] perl-CPAN-Perl-Releases-5.20200314 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813602

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200314-1.fc32 has been pushed to the Fedora 32
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf6dc15b96

-- 
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 1813603] perl-Module-CoreList-5.20200314 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813603

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Module-CoreList-5.20200314-1.fc32 has been pushed to the Fedora 32 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe90fd7233

-- 
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 1813720] perl-Pod-Usage-1.70 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813720

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC|ppi...@redhat.com   |
   Fixed In Version||perl-Pod-Usage-1.70-1.fc33
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

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


tipcutils license change

2020-03-16 Thread Peter Hanecak
Hello,

I'm working on update of tipcutils from 2.2.0 to 3.0.4. This will bring
a license change: GPLv2 was dropped upstream, BDS license remains.

Sincerely

Peter

-- 
Peter Hanecak 
  http://hany.sk/~hany/
  GnuPG: http://hany.sk/~hany/gpg/475DFC4C.txt



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


Re: LWT 5.1.2? (was: Re: OCaml 4.10.0 build in Fedora 32 and 33)

2020-03-16 Thread Richard W.M. Jones
On Tue, Feb 25, 2020 at 12:22:10PM -0800, Michel Alexandre Salim wrote:
> > On February 25, 2020 3:38 AM Richard W.M. Jones  wrote:
> > 
> >  
> > In the previous mass build LWT FTBFS because the tests failed on POWER
> > and s/390 (https://bugzilla.redhat.com/1792780).  There is also a new
> > version of LWT (https://bugzilla.redhat.com/1755859).  The new version
> > is noted as an API break, although I don't know how that will affect
> > other packages.
> > 
> > Anyway I did manage to update LWT to 5.1.2, fix a few things, and do a
> > scratch build.  The tests even pass on all arches:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41885170
> > 
> Sounds great. I'd say push this for Rawhide and FC32, and maybe update FC31 
> later if necessary?

I have a feeling that I may have pushed this change by accident when I
was doing the OCaml 4.10.0 final build.  Anyway, hopefully everything
is now fine!  If you find any problems related to this then let me
know and I'll try and fix it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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 1813676] perl-Prima-1.58 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813676

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Prima-1.58-1.fc33
 Resolution|--- |RAWHIDE
Last Closed||2020-03-16 13:27:39



--- Comment #1 from Petr Pisar  ---
Many new features. Safer for Rawhide only.

-- 
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 1004354] perl-Alien-ROOT not available on ARM because root is not there

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1004354

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Alien-ROOT-5.34.36.1-1
   ||9.fc33



--- Comment #11 from Petr Pisar  ---
Thank you for the notification.

-- 
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 1813653] perl-TeX-Encode-2.008 is available

2020-03-16 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813653

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-03-16 12:58:58



--- Comment #3 from Tom "spot" Callaway  ---
In rawhide.

-- 
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-IoT-33-20200316.0 compose check report

2020-03-16 Thread Fedora compose checker
Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 2/8 (x86_64)

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

ID: 546772  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/546772
ID: 546773  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/546773

Skipped non-gating openQA tests: 6 of 8
-- 
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


  1   2   >