Fedora-Cloud-33-20210217.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-87e6bb3010   
chromium-88.0.4324.150-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2561abf859   
snapd-2.49-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-610589457a   
prosody-0.11.8-1.el8


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

libprojectM-3.1.11-1.el8

Details about builds:



 libprojectM-3.1.11-1.el8 (FEDORA-EPEL-2021-c839e1d5a7)
 The libraries for the projectM music visualization plugin

Update Information:

New upstream release

ChangeLog:

* Sun Feb 14 2021 Fedora Release Monitoring 
 - 3.1.11-1
- Update to 3.1.11 (#1928290)
* Tue Jan 26 2021 Fedora Release Engineering  - 
3.1.8-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

References:

  [ 1 ] Bug #1928290 - libprojectM-3.1.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1928290


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1928873] perl-Dumbbench-0.501 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-8ee9c2d578 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-8ee9c2d578`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-8ee9c2d578

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

[Bug 1928873] perl-Dumbbench-0.501 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-396489f740 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-396489f740`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-396489f740

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  61  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599   
openjpeg2-2.3.1-10.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-01679b76db   
chromium-88.0.4324.150-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-692420cee2   
snapd-2.49-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3cc28d5469   
php-horde-Horde-Text-Filter-2.3.7-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bb1731457c   
prosody-0.11.8-1.el7


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

privoxy-3.0.31-1.el7
python-termcolor-1.1.0-24.el7
tldr-1.2.0-4.el7

Details about builds:



 privoxy-3.0.31-1.el7 (FEDORA-EPEL-2021-f93d3d26db)
 Privacy enhancing proxy

Update Information:

3.0.31

ChangeLog:

* Mon Feb  1 2021 Gwyn Ciesla  - 3.0.31-1
- 3.0.31
* Wed Jan 27 2021 Fedora Release Engineering  - 
3.0.29-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
* Mon Nov 30 2020 Gwyn Ciesla  - 3.0.29-1
- 3.0.29
* Tue Jul 28 2020 Fedora Release Engineering  - 
3.0.28-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Thu Jan 30 2020 Fedora Release Engineering  - 
3.0.28-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Fri Jul 26 2019 Fedora Release Engineering  - 
3.0.28-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri Apr 19 2019 josef radinger  - 3.0.28-1
- bump version
* Sat Feb  2 2019 Fedora Release Engineering  - 
3.0.26-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Fri Jan 25 2019 Petr Pisar  - 3.0.26-8
- Rebuild against patched libpcreposix library (bug #1667614)
* Fri Jul 13 2018 Fedora Release Engineering  - 
3.0.26-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Fri Feb  9 2018 Fedora Release Engineering  - 
3.0.26-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Aug  3 2017 Fedora Release Engineering  - 
3.0.26-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Thu Jul 27 2017 Fedora Release Engineering  - 
3.0.26-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Tue Mar 14 2017 Jon Ciesla  - 3.0.26-3
- systemd cleanup
* Sat Feb 11 2017 Fedora Release Engineering  - 
3.0.26-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild

References:

  [ 1 ] Bug #1928727 - CVE-2021-20209 privoxy: memory leak in the show-status 
CGI handler when no action files are configured [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928727
  [ 2 ] Bug #1928732 - CVE-2021-20210 privoxy: memory leak in the show-status 
CGI handler when no filter files are configured [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928732
  [ 3 ] Bug #1928735 - CVE-2021-20211 privoxy: memory leak when client tags are 
active [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928735
  [ 4 ] Bug #1928738 - CVE-2021-20212 privoxy: memory leak if multiple filters 
are executed and the last one is skipped due to a pcre error [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928738
  [ 5 ] Bug #1928741 - CVE-2021-20213 privoxy: dereference of a NULL-pointer 
that could result in a crash if accept-intercepted-requests was enabled 
[epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928741
  [ 6 ] Bug #1928744 - CVE-2021-20214 privoxy: memory leak in the client-tags 
CGI handler when client tags are configured [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928744
  [ 7 ] Bug #1928748 - CVE-2021-20215 privoxy: memory leaks in the show-status 
CGI handler when memory allocations fail [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928748
  [ 8 ] Bug #1928751 - CVE-2020-35502 privoxy: memory leaks when a response is 
buffered [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1928751




 python-termcolor-1.1.0-24.el7 (FEDORA-EPEL-2021-04342c0279)
 ANSI Color formatting for output in terminal

Update Information:

tldr and dependency python-termcolor for epel7

ChangeLog:

[Bug 1922560] perl-Geo-Distance-0.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Geo-Distance-0.25-1.fc |perl-Geo-Distance-0.25-1.fc
   |34  |34
   |perl-Geo-Distance-0.25-1.fc |perl-Geo-Distance-0.25-1.fc
   |33  |33
   |perl-Geo-Distance-0.25-1.fc |perl-Geo-Distance-0.25-1.fc
   |32  |32
   ||perl-Geo-Distance-0.25-1.el
   ||8



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2021-5c62231303 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


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

Re: restic update and src.fedoraproject.org and Self Introduction

[James Cassell]

On Tue, Feb 16, 2021, at 8:06 PM, Kevin Anderson wrote:
[...]
> The issue is that when I attempt to push over HTTPS I get an
> authentication failure. I have tried with an API key as well as with
> my FAS password using my FAS username (kanderson) for both. Is it
> expected that I can't push, even to a fork, if I am not a part of a
> packagers group?

re-clone the repo using `fedpkg clone --anonymous`, then `git remote add fork 
`, then you can follow the prompts when you attempt to push to 
your fork. (it'll get you to open a browser and sign-in there)

V/r,
James Cassell
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-34-20210216.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Failed openQA tests: 28/183 (x86_64), 25/124 (aarch64)

New failures (same test not failed in Fedora-34-20210215.n.0):

ID: 779855  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/779855
ID: 779876  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/779876
ID: 779919  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/779919
ID: 779946  Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/779946
ID: 779947  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/779947
ID: 779966  Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi
URL: https://openqa.fedoraproject.org/tests/779966
ID: 779979  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/779979
ID: 779984  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/779984
ID: 779994  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/779994
ID: 780125  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/780125

Old failures (same test failed in Fedora-34-20210215.n.0):

ID: 779838  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/779838
ID: 779842  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/779842
ID: 779849  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/779849
ID: 779858  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/779858
ID: 779861  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/779861
ID: 779863  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/779863
ID: 779875  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/779875
ID: 779902  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/779902
ID: 779908  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/779908
ID: 779909  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/779909
ID: 779910  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/779910
ID: 779912  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/779912
ID: 779913  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/779913
ID: 779915  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/779915
ID: 779949  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/779949
ID: 779953  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/779953
ID: 779955  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/779955
ID: 779963  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/779963
ID: 779964  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/779964
ID: 779969  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/779969
ID: 779971  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/779971
ID: 779972  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/779972
ID: 779983  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/779983
ID: 779985  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/779985
ID: 780019  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/780019
ID: 780030  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/780030
ID: 780031  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/780031
ID: 780038  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/780038
ID: 780039  Test: x86_64 universal 

restic update and src.fedoraproject.org and Self Introduction

[Kevin Anderson]

Hello everyone,

I have been a Fedora user for years now and during my $dayjob I work
with Linux systems. RPM packaging is not new to me but contributing to
those packages as a part of a distribution is.

I was hoping to see if I could resolve the build failures for restic
to upgrade it to the latest version. I started by checking out the
restic repository on src.fedoraproject.org and updating the spec file
to the latest version and running a local fedpkg mockbuild
successfully. Given I am not currently in a packager group I forked
the repository and was trying to push to a branch under my fork so
that I could open a PR for the maintainer to review and comment on.

The issue is that when I attempt to push over HTTPS I get an
authentication failure. I have tried with an API key as well as with
my FAS password using my FAS username (kanderson) for both. Is it
expected that I can't push, even to a fork, if I am not a part of a
packagers group?

I've also attached the patch that I have so far in case Steve Miller
(copart) follows the mailing list.

- Kevin
From e59cadfe8d77c3849744aa36275c1b142af5ca11 Mon Sep 17 00:00:00 2001
From: Kevin Anderson 
Date: Tue, 16 Feb 2021 19:07:08 -0500
Subject: [PATCH] Update to upstream 0.12.0 release

---
 restic.spec | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/restic.spec b/restic.spec
index c9744ad..d935c87 100644
--- a/restic.spec
+++ b/restic.spec
@@ -1,6 +1,6 @@
 # https://github.com/restic/restic
 %global goipath github.com/restic/restic
-Version:0.10.0
+Version:0.12.0
 
 %gometa
 
@@ -23,15 +23,13 @@ Backup destinations can be:
 
 
 Name:restic
-Release: 4%{?dist}
+Release: 0%{?dist}
 Summary: Fast, secure, efficient backup program
 URL: %{gourl}
 License: BSD
 Source0: %{gosource}
 #Patch0: 0001-Fix-running-tests-on-a-SELinux-enabled-system.patch
 #Patch1: backport-2652.patch
-#Upgrade github.com/cenkalti/backoff module #2934
-Patch0:  0001-Upgrade-github.com-cenkalti-backoff-module.patch
 #Move internal/fs.TestChdir to internal/test.Chdir
 #Patch1:  0001-Move-internal-fs.TestChdir-to-internal-test.Chdir.patch
 
@@ -65,9 +63,10 @@ BuildRequires: golang(golang.org/x/text/encoding/unicode)
 BuildRequires: golang(google.golang.org/api/googleapi)
 BuildRequires: golang(google.golang.org/api/storage/v1)
 BuildRequires: golang(gopkg.in/tomb.v2)
-#Updated for 0.10.0
-BuildRequires: golang(github.com/minio/minio-go/v6)
-BuildRequires: golang(github.com/minio/minio-go/v6/pkg/credentials)
+#Updated for 0.12.0
+BuildRequires: golang(github.com/minio/minio-go/v7)
+BuildRequires: golang(github.com/minio/minio-go/v7/pkg/credentials)
+BuildRequires: golang(cloud.google.com/go/storage)
 #Added for 0.10.0
 BuildRequires: golang(github.com/cespare/xxhash)
 BuildRequires: golang(github.com/dchest/siphash)
@@ -84,10 +83,6 @@ BuildRequires: golang(github.com/google/go-cmp/cmp)
 
 %prep
 %goprep
-%patch0 -p1
-#%%patch1 -p1
-#Broken tar tests, disable
-rm internal/dump/tar_test.go
 
 %build
 %gobuild -o %{gobuilddir}/bin/%{name} %{goipath}/cmd/restic
@@ -114,7 +109,7 @@ export RESTIC_TEST_FUSE=0
 
 %files
 %license LICENSE
-%doc GOVERNANCE.md CONTRIBUTING.md CHANGELOG.md README.rst
+%doc GOVERNANCE.md CONTRIBUTING.md CHANGELOG.md README.md
 %{_bindir}/%{name}
 %dir %{_datadir}/zsh/site-functions
 %{_datadir}/zsh/site-functions/_restic
@@ -125,6 +120,9 @@ export RESTIC_TEST_FUSE=0
 
 
 %changelog
+* Tue Feb 16 2021 Kevin Anderson  - 0.12.0-0
+- Upgrade to upstream 0.12.0
+
 * Wed Jan 27 2021 Fedora Release Engineering  - 0.10.0-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
 
-- 
2.29.2

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 34 compose report: 20210216.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-34-20210215.n.0
NEW: Fedora-34-20210216.n.1

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

Size of added packages:  794.70 KiB
Size of dropped packages:829.81 KiB
Size of upgraded packages:   4.40 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -168.53 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-34-20210216.n.1.x86_64.vagrant-libvirt.box
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-34-20210216.n.1.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-34-20210216.n.1.iso
Image: Xfce_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-armhfp-34-20210216.n.1-sda.raw.xz
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-34-20210216.n.1.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-34-20210216.n.1.x86_64.vagrant-virtualbox.box

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: lz4-java-1.7.1-12.fc34
Summary: LZ4 compression for Java
RPMs:lz4-java lz4-java-javadoc
Size:794.70 KiB


= DROPPED PACKAGES =
Package: auto-destdir-1.11-19.fc34
Summary: Automate DESTDIR support for "make install"
RPMs:auto-destdir
Size:28.19 KiB

Package: clive-2.3.3-26.fc34
Summary: Video extraction tool for user-uploaded video hosts
RPMs:clive
Size:35.42 KiB

Package: man-pages-it-4.08-12.fc34
Summary: Italian man (manual) pages from the Linux Documentation Project
RPMs:man-pages-it
Size:618.25 KiB

Package: perl-Capture-Tiny-0.48-9.module_f34+10120+d96ca0ba
Summary: Capture STDOUT and STDERR from Perl, XS or external programs
RPMs:perl-Capture-Tiny
Size:68.86 KiB

Package: perl-Devel-CheckLib-1.14-5.module_f34+10976+4c8e6827
Summary: Check that a library is available
RPMs:perl-Devel-CheckLib
Size:48.06 KiB

Package: xfwm4-theme-nodoka-0.2-18.fc34
Summary: Nodoka theme for xfwm4
RPMs:xfwm4-theme-nodoka
Size:31.03 KiB


= UPGRADED PACKAGES =
Package:  MagicPoint-1.13a-29.fc34
Old package:  MagicPoint-1.13a-27.fc33
Summary:  X based presentation software
RPMs: MagicPoint
Size: 3.06 MiB
Size change:  6.31 KiB
Changelog:
  * Mon Jan 25 2021 Fedora Release Engineering  - 
1.13a-28
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Mon Feb 15 2021 Hans de Goede  - 1.13a-29
  - Fix FTBFS (rhbz1923401)
  - Drop Imlib support, only works with obsolete Imlib1
  - Fix m17n support
  - Fix libmng support on lib64 using arches


Package:  R-4.0.4-1.fc34
Old package:  R-4.0.3-3.fc34
Summary:  A language for data analysis and graphics
RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath 
libRmath-devel libRmath-static
Size: 347.03 MiB
Size change:  1.30 MiB
Changelog:
  * Mon Feb 15 2021 Tom Callaway  - 4.0.4-1
  - update to 4.0.4


Package:  R-testthat-3.0.2-1.fc34
Old package:  R-testthat-3.0.1-2.fc34
Summary:  Unit Testing for R
RPMs: R-testthat
Size: 7.30 MiB
Size change:  21.20 KiB
Changelog:
  * Mon Feb 15 2021 Tom Callaway  - 3.0.2-1
  - update to 3.0.2


Package:  R-waldo-0.2.4-1.fc34
Old package:  R-waldo-0.2.3-2.fc34
Summary:  Find Differences Between R Objects
RPMs: R-waldo
Size: 81.73 KiB
Size change:  337 B
Changelog:
  * Mon Feb 15 2021 Tom Callaway  - 0.2.4-1
  - update to 0.2.4


Package:  anaconda-34.24.3-1.fc34
Old package:  anaconda-34.24.2-1.fc34
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-widgets anaconda-widgets-devel
Size: 22.42 MiB
Size change:  -14.42 KiB
Changelog:
  * Mon Feb 15 2021 Martin Kolman  - 34.24.3-1
  - Do not hard-require zram-generator-default on RHEL just yet (mkolman)
  - Improve Packit configuration to use fedora-development (jkonecny)
  - Add a kickstart specification for the main process (vponcova)
  - Adapt Packit configuration to a newly branched Fedora (jkonecny)
  - Create swap by default in RHEL-based installations (#1915297) (vponcova)
  - Add missing space to a message (vslavik)
  - Use Linux HOST_NAME_MAX hostname length limit (xiaqirong1)


Package:  asciidoc-9.1.0-1.fc34
Old package:  asciidoc-9.0.4-5.fc34
Summary:  Text based document generation
RPMs: asciidoc asciidoc-doc asciidoc-latex
Size: 384.00 KiB
Size change:  -464 B
Changelog:
  * Tue Feb 16 2021 Josef Ridky  - 9.1.0-1
  - update source url
  - new upstream release 9.1.0


Package:  avahi-0.8-9.fc34
Old package:  avahi-0.8-6.fc34
Summary:  Local network service discovery
RPMs: avahi avahi-aut

Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)

[Chris Murphy]

On Tue, Feb 16, 2021 at 4:10 PM Jeremy Linton  wrote:

> On 2/14/21 2:20 PM, Chris Murphy wrote:

> > This isn't sufficiently qualified. It does work to reduce space
> > consumption and write amplification. It's just that there's a tradeoff
> > that you dislike, which is IO reduction. And it's completely
> > reasonable to have a subjective position on this tradeoff. But no
> > matter what there is a consequence to the choice.
>
> IO reduction in some cases (see below), for additional read latency, and
> and increase in CPU utilization.
>
> For a desktop workload the former is likely a larger problem. But as we
> all know sluggishness is a hard thing to measure on a desktop. QD1
> pointer chasing on disk though is a good approximation, sometimes boot
> times are too.

What is your counter proposal?


> > A larger file might have a mix of compressed and non-compressed
> > extents, based on this "is it worth it" estimate. This is the
> > difference between the compress and compress-force options, where
> > force drops this estimator and depends on the compression algorithm to
> > do that work. I sometimes call that estimator the "early bailout"
> > check.
>
> Compression estimation is its own ugly ball of wax. But ignoring that
> for the moment, consider what happens if you have a bunch of 2G database
> files with a reasonable compression ratio. Lets assume for a moment the
> database attempts to update records in the middle of the files. What
> happens when the compression ratio gets slightly worse? (its likely you
> already have nodatacow).

What percentage of Fedora desktop users do you estimate have a bunch
of 2G database files?

I don't assume datacow or nodatacow for databases, because some
databases and their workloads do OK on COW filesystems and others
don't.

Also, nodatacow disables compression. i.e. files having file attribute
'C' (nodatacow) with mount option compress(-force) remain
uncompressed.

> Although this becomes a case of
> seeing if the "compression estimation" logic is smart enough to detect
> its causing poor IO patterns (while still having a reasonably good
> compression ratio).

The "early bail" heuristic just tries to estimate if the effort of
compression is worth it. If it is, the data extent is submitted for
compression and if it's not worth it, it isn't. The max extent size
for this is 128KiB. There's no IO pattern detection. Once the
compression has happened, the write allocator works the same as
without compression.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/compression.c?h=v5.11#n1314
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/compression.c?h=v5.11#n1609



> In a past life, I spent a non inconsequential part of a decade
> engineering compressed ram+storage systems (similar to what has been
> getting merged to mainline over the past few years). Its really hard to
> make one that is performant across a wide range of workloads. What you
> get are areas where it can help, but if you average those case with the
> ones where it hurts the overwhelming analysis is you shouldn't be
> compressing unless you want the capacity. The worse part is that most
> synthetic file IO benchmarks tend to be on the "it helps" side of the
> equation and the real applications on the other.

This is why I tend to poo poo on benchmarks. They're useful for the
narrow purpose they're intended to measure. Synthetic benchmarks are
good at exposing problems, but won't tell you their significance, so
what they expose is the need for better testing. A databased benchmark
will do a good job showing performance issues with workloads that act
like the database that the benchmark is mimicking. Not all databases
have the same behavior.


> IMHO if fedora wanted to take a hit on the IO perf side, a much better
> place to focus would be flipping encryption on. The perf profile is
> flatter (aes-ni & the arm crypto extensions are common) with fewer evil
> edge cases. Or a more controlled method might to be picking a couple
> fairly atomic directories and enabling compression there (say /usr).

Workstation WG has been tracking these:
https://pagure.io/fedora-workstation/issue/136
https://pagure.io/fedora-workstation/issue/82

A significant impediment to ticket the "Encrypt my data" checkbox by
default in Automatic partitioning is the UI/UX. The current evaluation
centers on using systemd-homed to encrypt user data by default; and
optionally enabling system encryption with the key sealed in the TPM,
or protected on something like a yubikey. There's still some work to
do to get this integrated.

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

Fedora-IoT-35-20210216.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

Old failures (same test failed in Fedora-IoT-35-20210214.1):

ID: 780137  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/780137
ID: 780139  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/780139
ID: 780146  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/780146
ID: 780153  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/780153
ID: 780154  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/780154

Skipped non-gating openQA tests: 26 of 31
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora 34 Branched 20210216.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 34 Branched 20210216.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20210213.n.0: anaconda-34.24.2-1.fc34.src, 20210216.n.1: 
anaconda-34.24.3-1.fc34.src
lorax - 20210213.n.0: lorax-34.8-1.fc34.src, 20210216.n.1: lorax-34.9-1.fc34.src
pungi - 20210213.n.0: pungi-4.2.7-3.fc34.src, 20210216.n.1: 
pungi-4.2.8-1.fc34.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/34

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210216.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210216.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210216.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210216.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210216.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210216.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210216.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20210216.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp
Minimal raw-xz armhfp

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

Failed openQA tests: 29/183 (x86_64), 19/124 (aarch64)

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

ID: 779343  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/779343
ID: 779453  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/779453
ID: 779473  Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/779473
ID: 779519  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/779519
ID: 779562  Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/779562

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

ID: 779322  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/779322
ID: 779323  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/779323
ID: 779369  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/779369
ID: 779371  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/779371
ID: 779376  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/779376
ID: 779377  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/779377
ID: 779379  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/779379
ID: 779380  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/779380
ID: 779382  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/779382
ID: 779402  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/779402
ID: 779430  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/779430
ID: 779431  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/779431
ID: 779433  Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi
URL: https://openqa.fedoraproject.org/tests/779433
ID: 779434  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/779434
ID: 779480  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/779480
ID: 779486  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/779486
ID: 779490  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/779490
ID: 779491  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/779491
ID: 779492  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/779492
ID: 779493  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/779493
ID: 779497  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/779497
ID: 779498  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/779498
ID: 779499  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/779499
ID: 779505  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/779505
ID: 779506  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/779506
ID: 779514  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/779514
ID: 779515  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/779515
ID: 779528  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/779528
ID: 779533  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/779533
ID: 779554  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/779554
ID: 779558  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/779558
ID: 779563  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/779563
ID: 779564  Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/779564
ID: 779565  Test: 

Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)

[Jeremy Linton]

Hi,

On 2/14/21 2:20 PM, Chris Murphy wrote:

On Sat, Feb 13, 2021 at 9:45 PM Jeremy Linton  wrote:


Hi,

On 2/11/21 11:05 PM, Chris Murphy wrote:

On Thu, Feb 11, 2021 at 9:58 AM Jeremy Linton  wrote:


Hi,

On 1/1/21 8:59 PM, Chris Murphy wrote:



Anyway, compress=zstd:1 is a good default. Everyone benefits, and I'm
not even sure someone with a very fast NVMe drive will notice a slow
down because the compression/decompression is threaded.


I disagree that everyone benefits. Any read latency sensitive workload
will be slower due to the application latency being both the drive
latency plus the decompression latency. And as the kernel benchmarks
indicate very few systems are going to get anywhere near the performance
of even baseline NVMe drives when its comes to throughput.


It's possible some workloads on NVMe might have faster reads or writes
without compression.

https://github.com/facebook/zstd

btrfs compress=zstd:1 translates into zstd -1 right now; there are
some ideas to remap btrfs zstd:1 to one of the newer zstd --fast
options, but it's just an idea. And in any case the default for btrfs
and zstd will remain as 3 and -3 respectively, which is what
'compress=zstd' maps to, making it identical to 'compress=zstd:3'.

I have a laptop with NVMe and haven't come across such a workload so
far, but this is obviously not a scientific sample. I think you'd need
a process that's producing read/write rates that the storage can meet,
but that the compression algorithm limits. Btrfs is threaded, as is
the compression.

What's typical, is no change in performance and sometimes a small
small increase in performance. It essentially trades some CPU cycles
in exchange for less IO. That includes less time reading and writing,
but also less latency, meaning the gain on rotational media is
greater.


Worse, if the workload is very parallel, and at max CPU already
the compression overhead will only make that situation worse as well. (I
suspect you could test this just by building some packages that have
good parallelism during the build).


This is compiling the kernel on a 4/8-core CPU (circa 2011) using make
-j8, the kernel running is 5.11-rc7.

no compression

real55m32.769s
user369m32.823s
sys 35m59.948s

--

compress=zstd:1

real53m44.543s
user368m17.614s
sys 36m2.505s

That's a one time test, and it's a ~3% improvement. *shrug* We don't
really care too much these days about 1-3% differences when doing
encryption, so I think this is probably in that ballpark, even if it
turns out another compile is 3% slower. This is not a significantly
read or write centric workload, it's mostly CPU. So this 3% difference
may not even be related to the compression.


Did you drop caches/etc between runs?


Yes. And also did the test with uncompressed source files when
compiling without the compress mount option. And compressed source
files when compiling with the compress mount option. While it's
possible to mix those around (there's four combinations), I kept them
the same since those are the most common.




Because I git cloned mainline,
copied the fedora kernel config from /boot and on a fairly recent laptop
(12 threads) with a software encrypted NVMe. Dropped caches and did a
time make against a compressed directory and an uncompressed one with
both a semi constrained (4G) setup and 32G ram setup (compressed
swapping disabled, because the machine has an encrypted swap for
hibernation and crashdumps).

compressed:
real22m40.129s
user221m9.816s
sys 23m37.038s

uncompressed:
real21m53.366s
user221m56.714s
sys 23m39.988s

uncompressed 4G ram:
real28m48.964s
user288m47.569s
sys 30m43.957s

compressed 4G
real29m54.061s
user281m7.120s
sys 29m50.613s



While the feature page doesn't claim it always increases performance,
it also doesn't say it can reduce performance. In the CPU intensive
workloads, it stands to reason there's going to be some competition.
The above results strongly suggest that's what's going on, even if I
couldn't reproduce it. But performance gain/loss isn't the only factor
for consideration.



and that is not an IO constrained workload its generally cpu
constrained, and since the caches are warm due to the software
encryption the decompress times should be much faster than machines that
aren't cache stashing.


I don't know, so I can't confirm or deny any of that.



The machine above, can actually peg all 6 cores until it hits thermal
limits simply doing cp's with btrfs/zstd compression, all the while
losing about 800MB/sec of IO bandwidth over the raw disk. Turning an IO
bound problem into a CPU bound one isn't ideal.


It's a set of tradeoffs. And there isn't a governor that can assess
when an IO bound bottleneck becomes a CPU bound one.


Compressed disks only work in the situation where the CPUs can
compress/decompress faster than the disk, or the workload is managing to
significantly reduce IO because the working set is 

[Bug 1929447] New: perl-Mojolicious-9.01 is available

[bugzilla]

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

Bug ID: 1929447
   Summary: perl-Mojolicious-9.01 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: 9.01
Current version/release in rawhide: 9.0-1.fc35
URL: https://metacpan.org/release/Mojolicious

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


Based on the information from anitya:
https://release-monitoring.org/project/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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaned libmirage

[Miro Hrončok]

I've orphaned libmirage. It was assigned to an ex-redhatter with an invalid 
bugzilla email address. I've contacted them offlist via their private email and 
got their blessing.


It was updated to 2.0.0 8 years ago and nothing in Fedora depends on it, so I 
guess no harm done if it gets retired.

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Ed Greshko]

On 17/02/2021 04:24, Marius Schwarz wrote:

Am 16.02.21 um 15:03 schrieb Ed Greshko:



Thanks for the help!


FWIW, I suppose I don't know why a BZ is needed since the 
/etc/systemd/resolved.conf has a sample
for the DNS= parameter showing:




I think that "," is received by a dhcp answere from the dhcpd, which knows two dns and 
sets it that way. Maybe a mistake in the dhcp implementation or config line. IMHO systemd should be 
fail-tolerant to this kind of "bug", so a br is a good idea.



The file in question is /etc/systemd/resolved.conf.  This file isn't 
changed/managed by DHCP.

--
People who believe they don't make mistakes have already made one.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Wednesday's FESCo Meeting (2021-02-17)

[David Cantrell]

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

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

or run:
  date -d '2021-02-17 15:00 UTC'


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

= Discussed and Voted in the Ticket =

F35 Change: Add Fedora Kinoite as a variant
https://pagure.io/fesco/issue/2571
APPROVED (+8, 0, -0)

= Followups =

F34 Change: Route all Audio to PipeWire
https://pagure.io/fesco/issue/2508

Fedora 34 incomplete changes
https://pagure.io/fesco/issue/2576

= Open Floor =

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning dianara

[Antonio T. sagitter]

Hi all.

I've orphaned 'dianara' [1]; feel free to adopt it.
[1] https://src.fedoraproject.org/rpms/dianara

Regards.
--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Retiring fido-pi

[Antonio T. sagitter]

Hi all.

'fido-pi' [1] package is no longer supported since it's now integrated 
into 'percolator' [2]. So, i'm retiring it in Fedora 34 and Fedora 35.


[1] https://src.fedoraproject.org/rpms/fido-pi
[2] https://src.fedoraproject.org/rpms/percolator

Regards.
--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Marius Schwarz]

Am 16.02.21 um 15:03 schrieb Ed Greshko:



Thanks for the help!


FWIW, I suppose I don't know why a BZ is needed since the 
/etc/systemd/resolved.conf has a sample

for the DNS= parameter showing:




I think that "," is received by a dhcp answere from the dhcpd, which 
knows two dns and sets it that way. Maybe a mistake in the dhcp 
implementation or config line. IMHO systemd should be fail-tolerant to 
this kind of "bug", so a br is a good idea.


best regards,
Marius Schwarz
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Tue, Feb 16, 2021 at 03:38:35PM +0100, Fabio Valentini wrote:
> On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok  wrote:
> >
> > On 16. 02. 21 14:48, Fabio Valentini wrote:
> > >  if version_at(commit) != last_version:
> > >  return 0
> >
> > Should this be "return 1"?
> 
> No, 0 is correct. If the version does not match, this is the last
> commit *before* a version update.
> The "max(parents) + 1" then sets the Release to 1 for the commit that
> actually changed the version :)
> 
> > To prevent accidental divergence between the git history and the build 
> > system.
> > That's why this information is only used in the koji plugin, locally (ie: 
> > via
> > the rpmautospec CLI) it only relies on the git tags.
> 
> So ... you want to *prevent* divergence by *introducing* divergence? I
> do not follow ...

The build information is used to check if all the builds made in koji exists as
tags. If they don't, then they are added, thus resolving the divergence.
If they do, git tags are used, just like they are used locally.



Pierre
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

wiki table comparing non-x86 choices

[Daniel Pocock]

It could be useful to create a wiki table with some of the key features
of the most common boards other Fedora collaborators are already using

I already created a table showing the things I had in mind choosing
between the Raptor products, it would be fairly easy to copy and paste
it to the Fedora wiki and add columns for some aarch64 options

https://wiki.raptorcs.com/wiki/RCS_Platform_Comparison
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)

[Daniel Pocock]

On 16/02/2021 17:05, Peter Robinson wrote:
>> On 15/02/2021 19:47, Gary Buhrmaster wrote:
>>> On Mon, Feb 15, 2021 at 6:39 PM Dan Horák  wrote:
>>>
 The open question still is whether we should try to keep 64k as default
 as it would allow to find the remaining bugs and offer 4k kernel variant
 (COPR for ppc64le should be coming back soon), similar for the
 installer (a new remix/spin). After BTRFS removes the page size
 dependency, switching the kernels shouldn't cause any issues for users.
>>>
>>> I think it may be instructive to look at the enabling IPv6
>>> had on the entire ecosystem (and going to ipv6-first
>>> networking).  Which definitely broke things (and there
>>> remain, in the greater world, lots of things still broken
>>> when IPv6 is enabled).  However, if we still used ipv4-first
>>> networking even more would almost certainly still be
>>> broken, because no one would experience or report
>>> the issues with IPv6.
>>>
>>> If you agree that fixing the 64K bugs are important
>>> (and I personally think they are), you need to go
>>> 64K first to get the reports, and get the fixes.
>>
>>
>> The problem is that not all ppc64le bugs are related to page size
> 
> Welcome to the world of non x86 architectures.

Welcome or welcome back...
I started on Color Computer 3 with Motorola 6809.

>> I was recently looking at ffmpeg issues[1] that happen on any page size,
>> that is now fixed and it also fixes issues in Blender.
>>
>> Going to 4k page size, we effectively drain the swamp to the half-water
>> mark.  Some bugs will go away, other bugs will still be there.
> 
> It doesn't drain the swap at all, it just changes the water from one to 
> another.

My personal impression is that the combination of Btrfs page size and
GPUs not working were a darker water.  To get around that, I had to not
only compile a kernel but also create a custom installer image with my
kernel.  I'm happy to share those things for other users.

>> The volume of workstation bugs is actually quite intimidating.  Even for
>> somebody with a lot of experience, it takes away a certain amount of
>> energy.  Some users and maybe even some developers will spend so much
>> time on hacks and workarounds that they have no time or energy left to
>> report the bugs, bisect them or even fix them.
> 
> At least you don't have to deal with big endian bugs in there too, and
> a bunch of us that have been working on non x86 architectures for
> years have no doubt solved a number of the problems already. aarch64
> had a mix  of 4K (Fedora) and 64K (RHEL) and we've dealt with 100s of
> these already, of course that doesn't rule out POWER specific ones.

Actually, as an upstream developer, when politics doesn't prevent me
uploading packages to every distribution, I would carefully check unit
test results from all architectures on both Fedora and Debian.  If
builds failed on a specific architecture or big endian I would make the
effort to support it.  But I understand some people spend a far greater
percentage of their time on that than me and I'm glad so many things
just work already on POWER9.

>> But I do agree that we can't avoid 64k indefinitely.  If there is a way
>> to support both page sizes and run unit tests for all packages on both
>> that would be really useful.  In addition to unit tests, it would be
>> useful to have a manual check on Firefox, Thunderbird, LibreOffice, etc
>> before each major release on 64k.
> 
> No easily, apparently having something you can set via a kernel
> command line for this stuff isn't straight forward, I started asking
> for that functionality for pages sizes back in the early days of
> aarch64 and I'm still waiting.

I wasn't really thinking about a runtime option, I was thinking about
two completely parallel environments, each with their own copies of
userland compiled on kernels with the corresponding page size.

Beyond the unit tests, it would also be interesting to use reproducible
builds methods to compare userland binaries and see if they vary
depending on the page size of the host where they were built.  This
could flush out more problems.

>> 64k issues for ppc64le will also get more attention when other
>> architectures go 64k, then we won't have all the pressure on ppc64le
>> users.  IPv6 was for every architecture so the effort was spread a lot
>> more widely.
> 
> aarch64 also has 64K page sizes so it's already a shared problem, and
> I've dealt with and fixed more bug around that I care to remember but
> you're not the only one that's had to deal with it.

Yes and I've seen more reports from people trying that platform too, for
example, the recent blog[1] about the HoneyComb

Are there other ways we can collaborate on this, for example, with a
wiki page about known 64k issues?

Does anybody want to capture anything from this thread in the wiki page
for the change[2] or is there any other place where it would be useful
to have a summary?

Regards,

Daniel

1. 

[rpms/perl-LDAP] PR #1: FMF

[Petr Pisar]

ppisar merged a pull-request against the project: `perl-LDAP` that you are 
following.

Merged pull-request:

``
FMF
``

https://src.fedoraproject.org/rpms/perl-LDAP/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CPE Feedback Survey

[Michal Konecny]

Hi everyone,

we still want your feedback about your experiences with the CPE Team. 
The survey will take only few minutes and there is still some time left 
before the survey will be closed.


Here is the link to survey https://fedoraproject.limequery.com/4?lang=en 



On behalf of CPE,
Michal

On 03. 02. 21 12:48, Ant Carroll wrote:
Hey folks, Apologies for the delay in getting this out to you after 
the start of the year. Hopefully you've noticed the changes to 
communication since the results of the last survey we did in August. 
However, we know this is ever changing, people join or become inactive 
and so want to ensure we continue with making improvements that 
benefit us all. I'm here asking for your help with this again Here 
is a link to a very short survey we've put together to learn how your 
experiences have been with the CPE team since October 2020. If you 
could take the time (5mins max) to complete it for us it would be 
hugely valuable as we work on this continuous improvement - 
https://fedoraproject.limequery.com/4?lang=en 


The survey will remain open until Feb 17th (23:59 UTC).
Cheers, Ant --

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford 

Communications House

Cork Road, Waterford City

ancar...@redhat.com 
M: +353876213163  IM: ancarrol

@redhatjobs  redhatjobs 
 @redhatjobs 





___
infrastructure mailing list -- infrastruct...@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastruct...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)

[Peter Robinson]

> On 15/02/2021 19:47, Gary Buhrmaster wrote:
> > On Mon, Feb 15, 2021 at 6:39 PM Dan Horák  wrote:
> >
> >> The open question still is whether we should try to keep 64k as default
> >> as it would allow to find the remaining bugs and offer 4k kernel variant
> >> (COPR for ppc64le should be coming back soon), similar for the
> >> installer (a new remix/spin). After BTRFS removes the page size
> >> dependency, switching the kernels shouldn't cause any issues for users.
> >
> > I think it may be instructive to look at the enabling IPv6
> > had on the entire ecosystem (and going to ipv6-first
> > networking).  Which definitely broke things (and there
> > remain, in the greater world, lots of things still broken
> > when IPv6 is enabled).  However, if we still used ipv4-first
> > networking even more would almost certainly still be
> > broken, because no one would experience or report
> > the issues with IPv6.
> >
> > If you agree that fixing the 64K bugs are important
> > (and I personally think they are), you need to go
> > 64K first to get the reports, and get the fixes.
>
>
> The problem is that not all ppc64le bugs are related to page size

Welcome to the world of non x86 architectures.

> I was recently looking at ffmpeg issues[1] that happen on any page size,
> that is now fixed and it also fixes issues in Blender.
>
> Going to 4k page size, we effectively drain the swamp to the half-water
> mark.  Some bugs will go away, other bugs will still be there.

It doesn't drain the swap at all, it just changes the water from one to another.

> The volume of workstation bugs is actually quite intimidating.  Even for
> somebody with a lot of experience, it takes away a certain amount of
> energy.  Some users and maybe even some developers will spend so much
> time on hacks and workarounds that they have no time or energy left to
> report the bugs, bisect them or even fix them.

At least you don't have to deal with big endian bugs in there too, and
a bunch of us that have been working on non x86 architectures for
years have no doubt solved a number of the problems already. aarch64
had a mix  of 4K (Fedora) and 64K (RHEL) and we've dealt with 100s of
these already, of course that doesn't rule out POWER specific ones.

> But I do agree that we can't avoid 64k indefinitely.  If there is a way
> to support both page sizes and run unit tests for all packages on both
> that would be really useful.  In addition to unit tests, it would be
> useful to have a manual check on Firefox, Thunderbird, LibreOffice, etc
> before each major release on 64k.

No easily, apparently having something you can set via a kernel
command line for this stuff isn't straight forward, I started asking
for that functionality for pages sizes back in the early days of
aarch64 and I'm still waiting.

> 64k issues for ppc64le will also get more attention when other
> architectures go 64k, then we won't have all the pressure on ppc64le
> users.  IPv6 was for every architecture so the effort was spread a lot
> more widely.

aarch64 also has 64K page sizes so it's already a shared problem, and
I've dealt with and fixed more bug around that I care to remember but
you're not the only one that's had to deal with it.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)

[Jeremy Linton]

Hi,

On 2/13/21 10:41 PM, Tom Seewald wrote:

  > The GPUs also have firmware blobs
Could you provide some links to mailing list posts or bug reports where AMD 
developers confirm that their GPU firmware requires 4k pages? I think having 
some definitive sources will make this situation more clear.

So far the only amdgpu bug report I could find that relates to 64k pages[1] is 
a regression, as the reporter states the driver works with the 5.4 kernel. If 
someone with a power9 machine is willing to bisect the issue I think that would 
greatly increase the odds of this bug being resolved.


I can confirm that amdgpu worked with 64k pages on arm in the past with 
various GPUs. I haven't been testing it regularly though, but we will 
want it for rhel/centos which use 64k pages on aarch64 too.





[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1446
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

REMINDER: Fedora 34 Change complete (100% complete) deadline in one week

[Ben Cotton]

The change complete (100% complete) deadline for Fedora 34 changes is
Tuesday 23 February. At that point, changes should be 100% code
complete, along with supporting documentation where appropriate.
Please indicate this by setting the tracker bug for your change to
ON_QA.

Other upcoming schedule milestones:
* 2021-02-23 — Beta freeze begins
* 2021-03-16 — Beta release early target date
* 2021-03-23 — Beta release target date #1

For more information, see the schedule[1]

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@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-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

REMINDER: Fedora 34 Change complete (100% complete) deadline in one week

[Ben Cotton]

The change complete (100% complete) deadline for Fedora 34 changes is
Tuesday 23 February. At that point, changes should be 100% code
complete, along with supporting documentation where appropriate.
Please indicate this by setting the tracker bug for your change to
ON_QA.

Other upcoming schedule milestones:
* 2021-02-23 — Beta freeze begins
* 2021-03-16 — Beta release early target date
* 2021-03-23 — Beta release target date #1

For more information, see the schedule[1]

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-LDAP] PR #1: FMF

[Petr Pisar]

ppisar opened a new pull-request against the project: `perl-LDAP` that you are 
following:
``
FMF
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-LDAP/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Xfce 4.16 on EPEL-8

[john tatt]

Hi
I can't run the tests but anyway I wanted to thank the developpers for their 
very usefull job.

 

Le Tue Feb 16 2021 01:02:47 GMT+0100 (CET), Mukundan Ragavan 
 a écrit :  
 
 

On 2/15/21 5:50 PM, Orion Poplawski wrote:
> On 2/7/21 8:56 AM, Mukundan Ragavan wrote:
>>
>> Hi all,
>>
>> I have a COPR containing xfce 4.16 packages for EPEL-8 packages [0]. I 
>> would like to get some testing done using this COPR before getting 
>> into EPEL-8.
>>
>> Please email if and when you notice problems and I will try to fix it 
>> as soon as possible.
>>
>> As a reminder - xfce 4.16 will be available in F34.
> 
> Mukundan -
> 
>    Just a note that as mentioned on the CentOS list here:
> https://lists.centos.org/pipermail/centos/2021-February/353317.html
> 
> # dnf group install Xfce
> Last metadata expiration check: 0:02:24 ago on Mon 15 Feb 2021 03:41:53 
> PM MST.
> No match for group package "NetworkManager-gnome"
> No match for group package "thunar-archive-plugin"
> 
> So perhaps the comps file needs to get cleaned up?
> 

Indeed. I just forgot to build thunar-archive-plugin. :(

NetworkManager-gnome just needs to be removed from comps. I will do this.

I need to update a bunch of packages on EPEL-8 anyway.

> 
> And then possibly new with the copr seems to be:
> 
>   Problem: cannot install the best candidate for the job
>    - nothing provides pulseaudio-daemon needed by 
> xfce4-pulseaudio-plugin-0.4.3-5.el8.x86_64
> 
> Thanks for working on Xfce for EPEL, much appreciated.
> 
> 
> 

Ah, this I noticed. Hopefully, this will be fixed on pulseaudio (based 
on Neal's email).

-- 
GPG Key: E5C8BC67

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
  ___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1926922] Upgrade perl-Crypt-CBC to 3.01

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

   Fixed In Version||perl-Crypt-CBC-3.01-1.fc35



--- Comment #2 from Paul Howarth  ---
Built for Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=62088446


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1838000] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS

[bugzilla]

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

errata-xmlrpc  changed:

   What|Removed |Added

Link ID||Red Hat Product Errata
   ||RHSA-2021:0557




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1838000] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS

[bugzilla]

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



--- Comment #21 from errata-xmlrpc  ---
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:0557 https://access.redhat.com/errata/RHSA-2021:0557


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Neal Gompa]

On Tue, Feb 16, 2021 at 9:39 AM Fabio Valentini  wrote:
>
> On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok  wrote:
> >
> > On 16. 02. 21 14:48, Fabio Valentini wrote:
> > >  if version_at(commit) != last_version:
> > >  return 0
> >
> > Should this be "return 1"?
>
> No, 0 is correct. If the version does not match, this is the last
> commit *before* a version update.
> The "max(parents) + 1" then sets the Release to 1 for the commit that
> actually changed the version :)
>
> > To prevent accidental divergence between the git history and the build 
> > system.
> > That's why this information is only used in the koji plugin, locally (ie: 
> > via
> > the rpmautospec CLI) it only relies on the git tags.
>
> So ... you want to *prevent* divergence by *introducing* divergence? I
> do not follow ...
>
> > Using the number of commits can give weird results with merge commits and 
> > even
> > though the upgrade path is not really an issue anymore, we preferred to try
> > preserving it. So rpmautospec should minimize the risk of broken upgrade 
> > path.
>
> That is possible. However, I assume it's possible to determine whether
> a given commit is a merge commit? Then it would be easy to skip over
> those in the computation.
>
> And while I agree that upgrade path should be clean, fixing those
> corner cases by making the whole process brittle and possibly
> inconsistent does not sound like a good idea to me. And with system
> upgrade tools defaulting to `distro-sync` mode now, this corner cases
> are even less of a problem.
>

It's a problem in the normal upgrade case, since people release
post-release updates this way too.



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

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Fabio Valentini]

On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok  wrote:
>
> On 16. 02. 21 14:48, Fabio Valentini wrote:
> >  if version_at(commit) != last_version:
> >  return 0
>
> Should this be "return 1"?

No, 0 is correct. If the version does not match, this is the last
commit *before* a version update.
The "max(parents) + 1" then sets the Release to 1 for the commit that
actually changed the version :)

> To prevent accidental divergence between the git history and the build system.
> That's why this information is only used in the koji plugin, locally (ie: via
> the rpmautospec CLI) it only relies on the git tags.

So ... you want to *prevent* divergence by *introducing* divergence? I
do not follow ...

> Using the number of commits can give weird results with merge commits and even
> though the upgrade path is not really an issue anymore, we preferred to try
> preserving it. So rpmautospec should minimize the risk of broken upgrade path.

That is possible. However, I assume it's possible to determine whether
a given commit is a merge commit? Then it would be easy to skip over
those in the computation.

And while I agree that upgrade path should be clean, fixing those
corner cases by making the whole process brittle and possibly
inconsistent does not sound like a good idea to me. And with system
upgrade tools defaulting to `distro-sync` mode now, this corner cases
are even less of a problem.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Tue, Feb 16, 2021 at 02:48:23PM +0100, Fabio Valentini wrote:
> On Fri, Feb 12, 2021 at 5:20 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/rpmautospec
> >
> > == Summary ==
> > The goal of this change is to deploy in production the
> > [https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec]
> > project.
> >
> > With it, the content of the `Release` and `%changelog` fields in spec
> > files can be auto-generated, either locally or in the builder using
> > the information present in the git repo (in the form of git tags).
> >
> >
> > Note: This proposal is about changing the way the `Release` and
> > `%changelog` sections of the '''spec files''' are filled, not about
> > removing them from the SRPM or binary RPM.
> >
> > == Owner ==
> > * Name: [[User:pingou| Pierre-Yves Chibon]]
> > * Email: pingou - at - pingoured.fr
> > * Name: [[User:nphilipp| Nils Philippsen]]
> > * Email: nphilipp - at - redhat.com
> >
> >
> > == Detailed Description ==
> >
> > rpmautospec offers packagers who want to use it the possibility of
> > replacing the content of the `Release` of their spec file by `Release:
> >%autorel` and/or replace the content of the `%changelog` section of
> > their spec file by:
> >   %changelog
> >   %autochangelog
> >
> > Both `%autorel` and `%autochangelog` are RPM macros that will be
> > expanded or replaced when the SRPM is built on the build system by
> > their corresponding values according to rpmautospec.
> >
> > An overview of how rpmautospec works can be found at:
> > https://docs.pagure.org/fedora-infra.rpmautospec/principle.html.
> > We will describe below how each macro works.
> >
> > === The %autorel macro ===
> >
> > To determine the next release information, rpmautospec relies on the
> > build history of the package.
> > This information is extracted from the buildsystem when running as a
> > koji plugin and from git tags when running outside of the buildsystem.
> >
> > Using the build history of the package (ie a list of NEVRs) as well as
> > the information provided by the packager in the spec file, rpmautospec
> > then computes the next best release number for the package.
> >
> > Once defined, it prepends a suitably defined %autorel macro to the top
> > of the spec file, freezing the computed value of the release number
> > and thus allowing reproducible builds of the SRPM.
> >
> > The [https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html
> > documentation of the autorel macro] describes how packagers can use it
> > to provide extra information.
> 
> I wonder why you're not relying solely on git history for both local
> builds and in koji?

To prevent accidental divergence between the git history and the build system.
That's why this information is only used in the koji plugin, locally (ie: via
the rpmautospec CLI) it only relies on the git tags.

Using the number of commits can give weird results with merge commits and even
though the upgrade path is not really an issue anymore, we preferred to try
preserving it. So rpmautospec should minimize the risk of broken upgrade path.


Pierre
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

License change: pipx (MIT and BSD to just MIT)

[Benjamin Beasley]

The pipx package has changed upstream from MIT and BSD to just MIT.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Łukasz Posadowski]

W dniu pon, 15.02.2021 o godzinie 17∶40 -0500, użytkownik Steve Dickson
napisał:
> Hello,
> 
> I just updated to latest Fedora 33 and 
> I no longer have any DNS name solution. 
> The network is up... but... 
> 
> $ ping www.yahoo.com
> ping: www.yahoo.com: Name or service not known
> 
> I changed nothing! 
> 
> How would be the bet way to debug this???

Thanks. I found that bug too. You can add dns server and search domain
directly into /etc/systemd/redolved.conf .

For me, yahoo.com resolving would work, but I couldn't resolve hosts
from my local domain, configured on a pihole, like:
- fedora.ping.local, 
- rawhide.ping.local,
- etc...

I have Fedora 33 on a VPS in OVH and it's working fine there, without
the need for any configuration in resolved.

-- 
Łukasz Posadowski

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Ed Greshko]

On 16/02/2021 21:37, Steve Dickson wrote:


On 2/15/21 9:16 PM, Dominique Martinet wrote:

Steve Dickson wrote on Mon, Feb 15, 2021 at 09:04:52PM -0500:

I think if no IP was successfully parsed the fallback ought to kick in,
so it's a systemd-resolved bug -- do you want to report this upstream or
shall I now I've had a look?

Fedora bz or an upstream bz? If is the latter where do I report it?

We have systemd devs in fedora so I think either would work out.

upstream is on github: https://github.com/systemd/systemd/issues


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

Thanks for the help!


FWIW, I suppose I don't know why a BZ is needed since the 
/etc/systemd/resolved.conf has a sample
for the DNS= parameter showing:

# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1 1.0.0.1 2606:4700:4700:: 2606:4700:4700::1001
# Google: 8.8.8.8 8.8.4.4 2001:4860:4860:: 2001:4860:4860::884

And the man page for resolved.conf explicitly states:

    DNS=
   A space-separated list of IPv4 and IPv6 addresses to use as system
   DNS servers.

Is the expectation that any character which may be considered a delimiter 
should be acceptable?

Wouldn't the more appropriate course of action be to correct format?

--
People who believe they don't make mistakes have already made one.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Miro Hrončok]

On 16. 02. 21 14:48, Fabio Valentini wrote:

I wonder why you're not relying solely on git history for both local
builds and in koji?


I'd also appreciate if the only source of truth would be git history.

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Troy Curtis Jr]

On Mon, Feb 15, 2021 at 10:02 PM Dominique Martinet 
wrote:

> Michael Catanzaro wrote on Mon, Feb 15, 2021 at 08:46:57PM -0600:
> > We removed the fallbacks due to complaints from users who didn't want DNS
> > ever going to Cloudflare or Google. So the lack of fallback is expected
> and
> > should not be reported as a bug.
>
> setting DNS= (or DNS="") explicitely should not fallback, I agree with
> that. There are people who want no DNS whatsoever and that should be
> configurable.
>
> But if extract_first_word() returned a non-empty string and
> manager_add_dns_server_by_string fails (for all iterations of the loop),
> it should definitely kick some fallback in -- the user obviously wanted
> *something*, it just doesn't work.
>
>
Steve's situation provides the perfect example for why a fallback is likely
undesirable. It sounds like his
configuration never worked. There were explicit DNS values configured that
weren't being used, yet
he never noticed because it fell back to something that seemed to work. It
would take a deeper and
deliberate look before the user realized the desired configuration wasn't
applied. It is better to error
than guess in many cases.


>
> > I think we have larger issues with DNS server assignment on cloud
> servers,
> > which I've reported as https://pagure.io/fedora-server/issue/10. But I
> also
> > notice Steve's case is different, since he really does have some static
> DNS
> > configuration, just using commas where spaces are required. So seems
> like a
> > misconfiguration by the cloud provider?
>
> Not sure where the configuration snippet with comma comes from but yes
> ultimately it's "just" a configuration error.
> Nevertheless, a config that somehow worked until a recent update through
> fallback, I don't think we want more unhappy users :)
>
> --
> Dominique
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Miro Hrončok]

On 16. 02. 21 14:48, Fabio Valentini wrote:

 if version_at(commit) != last_version:
 return 0


Should this be "return 1"?

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Fabio Valentini]

On Fri, Feb 12, 2021 at 5:20 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/rpmautospec
>
> == Summary ==
> The goal of this change is to deploy in production the
> [https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec]
> project.
>
> With it, the content of the `Release` and `%changelog` fields in spec
> files can be auto-generated, either locally or in the builder using
> the information present in the git repo (in the form of git tags).
>
>
> Note: This proposal is about changing the way the `Release` and
> `%changelog` sections of the '''spec files''' are filled, not about
> removing them from the SRPM or binary RPM.
>
> == Owner ==
> * Name: [[User:pingou| Pierre-Yves Chibon]]
> * Email: pingou - at - pingoured.fr
> * Name: [[User:nphilipp| Nils Philippsen]]
> * Email: nphilipp - at - redhat.com
>
>
> == Detailed Description ==
>
> rpmautospec offers packagers who want to use it the possibility of
> replacing the content of the `Release` of their spec file by `Release:
>%autorel` and/or replace the content of the `%changelog` section of
> their spec file by:
>   %changelog
>   %autochangelog
>
> Both `%autorel` and `%autochangelog` are RPM macros that will be
> expanded or replaced when the SRPM is built on the build system by
> their corresponding values according to rpmautospec.
>
> An overview of how rpmautospec works can be found at:
> https://docs.pagure.org/fedora-infra.rpmautospec/principle.html.
> We will describe below how each macro works.
>
> === The %autorel macro ===
>
> To determine the next release information, rpmautospec relies on the
> build history of the package.
> This information is extracted from the buildsystem when running as a
> koji plugin and from git tags when running outside of the buildsystem.
>
> Using the build history of the package (ie a list of NEVRs) as well as
> the information provided by the packager in the spec file, rpmautospec
> then computes the next best release number for the package.
>
> Once defined, it prepends a suitably defined %autorel macro to the top
> of the spec file, freezing the computed value of the release number
> and thus allowing reproducible builds of the SRPM.
>
> The [https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html
> documentation of the autorel macro] describes how packagers can use it
> to provide extra information.

I wonder why you're not relying solely on git history for both local
builds and in koji?

When this stuff was last discussed last year, I tried to implement a
simple algorithm for automatic Release values as well (because why
not), and I even had a working proof-of-concept implementation (in
python + pygit2) for the Release number that even worked for
non-linear git histories, something like (python-esque-pseudocode):

def release_num(commit, last_version) -> int:
if version_at(commit) != last_version:
return 0
else:
return max(release_num(parent, last_version) for parent of commit)) +1

(With "version_at" being a function that returns the value of Version
tag present in the specified commit in the git history.)

With an algorithm like this, you would not need to rely on either
build history or git tags, but use *only* commit history - which
should make this more reliable and produce always the same results
locally *and* in koji (because it uses the same underlying data).

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/16/21 6:05 AM, David Both wrote:
> This situation is due to the change from the old resolver to the new 
> systemd-resolved.
> 
> I have a page on my technical web site that describes the problem and the 
> circumvention.
> 
> http://www.linux-databook.info/?page_id=5951
> 
> This does not, erm, resolve the problem but it does get you back to a working 
> resover.
Right stopping/disabling the systemd-resolved then creating your own 
/etc/resovled.conf
is the work around... 

systemd is in the booting business... However did it get in DNS business... 
And that was a good idea??? ;-)

> 
> I hope this helps.
It did... Thanks you!

steved
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 9:16 PM, Dominique Martinet wrote:
> Steve Dickson wrote on Mon, Feb 15, 2021 at 09:04:52PM -0500:
>>> I think if no IP was successfully parsed the fallback ought to kick in,
>>> so it's a systemd-resolved bug -- do you want to report this upstream or
>>> shall I now I've had a look?
>>
>> Fedora bz or an upstream bz? If is the latter where do I report it?
> 
> We have systemd devs in fedora so I think either would work out.
> 
> upstream is on github: https://github.com/systemd/systemd/issues
> 
https://bugzilla.redhat.com/show_bug.cgi?id=1929212

Thanks for the help!

steved.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-ExtUtils-CBuilder] PR #1: Add tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-ExtUtils-CBuilder` 
that you are following.

Merged pull-request:

``
Add tests
``

https://src.fedoraproject.org/rpms/perl-ExtUtils-CBuilder/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1929205] perl-Business-ISMN-1.202 is available

[bugzilla]

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



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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1929205] perl-Business-ISMN-1.202 is available

[bugzilla]

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



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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1929205] New: perl-Business-ISMN-1.202 is available

[bugzilla]

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

Bug ID: 1929205
   Summary: perl-Business-ISMN-1.202 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Business-ISMN
  Keywords: FutureFeature, Triaged
  Assignee: c...@m.fsf.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: c...@m.fsf.org, mefos...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.202
Current version/release in rawhide: 1.201-8.fc34
URL: http://search.cpan.org/dist/Business-ISMN

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-ExtUtils-CBuilder] PR #1: Add tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: 
`perl-ExtUtils-CBuilder` that you are following:
``
Add tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-ExtUtils-CBuilder/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Martin Kolman]

On Mon, 2021-02-15 at 11:50 +0100, Vít Ondruch wrote:
> Dne 14. 02. 21 v 19:45 Kevin Fenzi napsal(a):
> > So, I am a bit leary of this change for the same reason that I was for
> > the last few changes like this. Namely, we are building out own layer on
> > top of rpm to make our lives easier, when we probibly should try and
> > just improve rpm to do this for everyone.
> > 
> > I realize that rpm is slow to move and this might not be practical, but
> > I sure wish we would try. 
> > 
> > As a strawman, what about this that upstream might take: 
> > 
> > * keep the same macros you propose (don't care what colour the bikeshed
> > is)
> > * src.rpms grow a (optional) releases (or whatever) dir. 
> > * under this (optional) dir we have a subdir for each version. 
> > * under that (optional) dir we have a subdir for each release.
> > * under that (optional) dir we have files for changelogs.
> 
> 
> Just FTR, when I was proposing some macros to include Changelog into RPM, I 
> was told that one of benefits of RPM and
> spec file is that it is all together in one file:
> 
> https://github.com/rpm-software-management/rpm/issues/393#issuecomment-365181602
I rather agree with that - I did some Debian packaging in the past and the 
bunch of random folder trees containing
almost random files that stands in for the spec file in Deb packages was pretty 
scary for me as a packaging beginner.

Having everything in a single file really helps to see what a package is about 
without having to dig through a million
files, not to mention makes comparing package revision easy.

I guess having changelog in one separate file is still bearable in this 
context, but would I hope it does not start a
splitting trend where other parts of the spec file get randomly split out as 
well.


> 
> If you look at the problem from this angle, then I can't see how this would 
> be acceptable to RPM upstream :/
> 
> 
> 
> Vít
> 
> 
> 
> > So, the last few ansible builds would have:
> > 
> > ansible-2.9.17-1.fc34:
> > 
> > ansible/releases/2.9.17/1/update-to-2.9.17
> > ansible/releases/2.9.16/2/conflict-with-ansible-base
> > ansible/releases/2.9.16/2/Adjust-collections-generator
> > ansible/releases/2.9.16/1/update-to-2.9.16
> > ...
> > 
> > When building, rpm would sort the releases dir, then the version subdir,
> > then concat the changelog fragments into a changelog. This way
> > everything is in the src.rpm.
> > 
> > When doing a PR, you would make a new version subdir and 
> > put a changelog fragment in it and commit it with any of
> > your other changes. 
> > 
> > Probibly some problems with that, but I thought I would throw it out
> > there from my sleep deprived mind. :) 
> > 
> > Anyhow, I just am a bit leary of us building up more and more around
> > rpm, and not just fixing rpm.
> > 
> > kevin
> > 
> > 
> > ___
> > 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
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> 
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[GSoC 2021] Calling for Mentors and Projects

[Sumantro Mukherjee]

Hey Folks!

Google Summer of Code (GSoC) is a global program focused on
introducing students to open source software development. Students
work on a 10-week programming project with an open-source organization
during their break from a post-secondary academic program. Fedora has
had great participation[0] and we would like to continue to be a
mentoring org this year too.

We are currently looking for mentors and projects!

If you are one who is interested, there are more details in [1] about
how to apply as a mentor and how to pitch project ideas.

If you have questions, please reach out to me or Vipul Siddharth on
emails or IRC.

[0] https://docs.fedoraproject.org/en-US/mentored-projects/gsoc/2021/
[1] 
https://communityblog.fedoraproject.org/call-for-projects-and-mentors-gsoc-2021/

--
//sumantro
Fedora GSoC Org Admin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1928873] perl-Dumbbench-0.501 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-8ee9c2d578 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-8ee9c2d578


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1928873] perl-Dumbbench-0.501 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-396489f740 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-396489f740


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1928873] perl-Dumbbench-0.501 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Dumbbench-0.501-1.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-02-16 11:32:42




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[David Both]

This situation is due to the change from the old resolver to the new 
systemd-resolved.


I have a page on my technical web site that describes the problem and the 
circumvention.


http://www.linux-databook.info/?page_id=5951

This does not, erm, resolve the problem but it does get you back to a working 
resover.


I hope this helps.


--


*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.

— Linus Torvalds
*

On Mon, 15 Feb 2021, Steve Dickson wrote:


Date: Mon, 15 Feb 2021 17:40:10
From: Steve Dickson 
Reply-To: Development discussions related to Fedora

To: devel@lists.fedoraproject.org
Subject: Don't update to the latest f33!

Hello,

I just updated to latest Fedora 33 and
I no longer have any DNS name solution.
The network is up... but...

$ ping www.yahoo.com
ping: www.yahoo.com: Name or service not known

I changed nothing!

How would be the bet way to debug this???

steved.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-32-20210216.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

[Bug 1929046] perl-Business-ISBN-Data-20210112.006 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Business-ISBN-Data-202
   ||10112.006-1.fc35
   ||perl-Business-ISBN-Data-202
   ||10112.006-1.fc34
 Resolution|--- |NEXTRELEASE
Last Closed||2021-02-16 09:26:14




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

perl-Dumbbench-0.501-1.fc35 license change

[Petr Pisar]

perl-Dumbbench-0.501-1.fc35 changed license from
((GPL+ or Artistic) and (Artistic 2.0)) to
(GPL+ or Artistic).

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Dumbbench] PR #1: test

[Petr Pisar]

ppisar merged a pull-request against the project: `perl-Dumbbench` that you are 
following.

Merged pull-request:

``
test
``

https://src.fedoraproject.org/rpms/perl-Dumbbench/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Dumbbench] PR #1: test

[Petr Pisar]

ppisar opened a new pull-request against the project: `perl-Dumbbench` that you 
are following:
``
test
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Dumbbench/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure