date:20210615

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




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

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

No missing expected images.

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

Failed openQA tests: 24/198 (x86_64), 26/134 (aarch64)

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

ID: 908889  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/908889
ID: 908890  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/908890
ID: 908901  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/908901
ID: 908903  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/908903
ID: 908907  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/908907
ID: 908910  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/908910
ID: 908911  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/908911
ID: 908912  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/908912
ID: 908920  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/908920
ID: 908924  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/908924
ID: 908927  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/908927
ID: 909016  Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/909016
ID: 909026  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/909026
ID: 909035  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/909035
ID: 909036  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/909036
ID: 909037  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/909037
ID: 909038  Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/909038
ID: 909047  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/909047
ID: 909048  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/909048
ID: 909049  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/909049
ID: 909050  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/909050

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

ID: 908972  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/908972
ID: 908986  Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/908986
ID: 908987  Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/908987
ID: 908988  Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/908988
ID: 908989  Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start
URL: https://openqa.fedoraproject.org/tests/908989
ID: 908990  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux
URL: https://openqa.fedoraproject.org/tests/908990
ID: 908991  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/908991
ID: 908992  Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging
URL: https://openqa.fedoraproject.org/tests/908992
ID: 908993  Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli
URL: https://openqa.fedoraproject.org/tests/908993
ID: 909060  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/909060
ID: 909075  Test: aarch64 Cloud_Base-qcow2-qcow2 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/909075
ID: 909076  Test: aarch64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/909076
ID: 909077  Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/909077
ID: 909078  Test: aarch64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/909078
ID: 909079  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/909079

Introduction: Trevor McKay

2021-06-15 Thread Trevor McKay

Hello everyone,

My name is Trevor and I was hoping to contribute to the Fedora project
in the form of packaging. I was told the first step would be to
introduce myself here. I have a few years of Linux experience as well as
Rust, Python and C/C++ development. I am, however, completely new to
packaging and contributing to open-source, so any advice is very much
welcome.

I am interested in packing `bottom`, a package for system monitoring
that I find fairly useful. I'd also be cool with picking up an abandoned
package, if anything is desperately needed. Come to think of it, I would
also like to do some development work, but I figured packaging was a
good start. Anyway, just looking to contribute where I can.

Cheers,
Trevor McKay
___
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

Introduction: Trevor McKay

2021-06-15 Thread Trevor McKay

Hello everyone,

My name is Trevor and I was hoping to contribute to the Fedora project
in the form of packaging. I was told the first step would be to
introduce myself here. I have a few years of Linux experience as well as
Rust, Python and C/C++ development. I am, however, completely new to
packaging and contributing to open-source, so any advice is very much
welcome.

I am interested in packing `bottom`, a package for system monitoring
that I find fairly useful. I'd also be cool with picking up an abandoned
package, if anything is desperately needed. Come to think of it, I would
also like to do some development work, but I figured packaging was a
good start. Anyway, just looking to contribute where I can.

Cheers,
Trevor mcKay
___
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 compose report: 20210615.n.1 changes

2021-06-15 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20210613.n.0
NEW: Fedora-Rawhide-20210615.n.1

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  18
Dropped packages:43
Upgraded packages:   264
Downgraded packages: 0

Size of added packages:  6.81 MiB
Size of dropped packages:17.14 MiB
Size of upgraded packages:   6.42 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: i3 live x86_64
Path: Spins/x86_64/iso/Fedora-i3-Live-x86_64-Rawhide-20210615.n.1.iso

= DROPPED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20210613.n.0.iso

= ADDED PACKAGES =
Package: ansible-collection-microsoft-sql-0.0.1-1.fc35
Summary: The Ansible collection for Microsoft SQL Server management
RPMs:ansible-collection-microsoft-sql
Size:36.04 KiB

Package: fkill-cli-6.1.0-1.fc35
Summary: Fabulously kill processes
RPMs:fkill-cli
Size:2.24 MiB

Package: ghc-regex-applicative-0.3.4-31.fc35
Summary: Regex-based parsing with applicative interface
RPMs:ghc-regex-applicative ghc-regex-applicative-devel 
ghc-regex-applicative-doc ghc-regex-applicative-prof
Size:1.68 MiB

Package: golang-github-bits-and-blooms-bitset-1.2.0-1.fc35
Summary: Go package implementing bitsets
RPMs:golang-github-bits-and-blooms-bitset-devel
Size:25.88 KiB

Package: mingw-sdl12-compat-0.0.1~git.20210612.44f299f-1.fc35
Summary: MinGW Windows port of SDL 1.2 runtime compatibility library using SDL 
2.0
RPMs:mingw32-sdl12-compat mingw64-sdl12-compat
Size:263.53 KiB

Package: rubygem-xmlrpc-0.3.2-1.fc35
Summary: XMLRPC is a lightweight protocol that enables remote procedure calls 
over HTTP
RPMs:rubygem-xmlrpc rubygem-xmlrpc-doc
Size:325.96 KiB

Package: rust-cap-primitives-0.13.10-1.fc35
Summary: Capability-oriented primitives
RPMs:rust-cap-primitives+arbitrary-devel rust-cap-primitives+default-devel 
rust-cap-primitives-devel
Size:100.74 KiB

Package: rust-cap-std-0.13.10-1.fc35
Summary: Capability-oriented version of the Rust standard library
RPMs:rust-cap-std+default-devel rust-cap-std-devel
Size:42.31 KiB

Package: rust-imgui-winit-support-0.7.1-2.fc35
Summary: Winit support code for the imgui crate
RPMs:rust-imgui-winit-support+default-devel 
rust-imgui-winit-support+no-warn-on-multiple-devel 
rust-imgui-winit-support+winit-24-devel rust-imgui-winit-support-devel
Size:44.78 KiB

Package: rust-plotters-backend-0.3.0-1.fc35
Summary: Plotters Backend API
RPMs:rust-plotters-backend+default-devel rust-plotters-backend-devel
Size:28.56 KiB

Package: rust-plotters-bitmap-0.3.1-1.fc35
Summary: Plotters Bitmap Backend
RPMs:rust-plotters-bitmap+default-devel rust-plotters-bitmap+gif-devel 
rust-plotters-bitmap+gif_backend-devel rust-plotters-bitmap+image-devel 
rust-plotters-bitmap+image_encoder-devel rust-plotters-bitmap-devel
Size:55.41 KiB

Package: rust-plotters-svg-0.3.0-1.fc35
Summary: Plotters SVG backend
RPMs:rust-plotters-svg+debug-devel rust-plotters-svg+default-devel 
rust-plotters-svg-devel
Size:29.26 KiB

Package: rust-quad-rand-0.2.1-1.fc35
Summary: Pseudo random implementation with std atomics
RPMs:rust-quad-rand+default-devel rust-quad-rand+rand-devel 
rust-quad-rand-devel
Size:24.92 KiB

Package: rust-svgtypes-0.5.0-1.fc35
Summary: SVG types parser and writer
RPMs:rust-svgtypes+default-devel rust-svgtypes-devel
Size:53.79 KiB

Package: rust-xmlwriter-0.1.0-1.fc35
Summary: Simple, streaming XML writer
RPMs:rust-xmlwriter+default-devel rust-xmlwriter-devel
Size:21.50 KiB

Package: rust-zcomponents-0.1.1-1.fc35
Summary: Stupid component storage
RPMs:rust-zcomponents+default-devel rust-zcomponents-devel
Size:22.42 KiB

Package: tini-0.19.0-1.fc35
Summary: A tiny but valid init for containers
RPMs:tini tini-static
Size:1.70 MiB

Package: x11docker-6.9.0-2.fc35
Summary: Run GUI applications and desktops in Linux containers
RPMs:x11docker
Size:142.27 KiB


= DROPPED PACKAGES =
Package: go-avif-0.1.0-7.fc34
Summary: AVIF (AV1 Still Image File Format) encoder for Go
RPMs:go-avif golang-github-kagami-avif-devel
Size:3.98 MiB

Package: mingw-pkg-config-0.28-16.fc34
Summary: A tool for determining compilation options
RPMs:mingw32-pkg-config mingw64-pkg-config
Size:524.61 KiB

Package: perl-App-cpanminus-1.7044-12.module_f35+11639+07949e10
Summary: Get, unpack, build and install CPAN modules
RPMs:perl-App-cpanminus
Size:87.73 KiB

Package: perl-CGI-4.53-1.module_f35+12154+daf61e9f
Summary: Handle Common Gateway Interface requests and responses
RPMs:perl-CGI
Size:198.02 KiB

Package: perl-CPAN-Meta-Check-0.014-15.module_f35+11372+3c51837c
Summary: Verify requirements in a CPAN::Meta object
RPMs:perl-CPAN-Meta-Check
Size:20.28 KiB

Package: perl-Clone-0.45-4.module_f35+11392+e7490124

[Bug 1932205] perl-IPTables-libiptc-0.52-36.fc35 FTBFS: iptables-detect-version.c:65:2: warning: #warning "This version of xtables is currently not supported by this Perl package

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



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

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 1959040] perl-HTTP-Message-6.30 is available

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



--- Comment #5 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c

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 1940699] perl-Net-HTTP-6.21 is available

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



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c

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 1936221] perl-libwww-perl-6.53 is available

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



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c

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 1930887] perl-HTTP-Message-6.28 is available

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



--- Comment #3 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c

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 1936048] perl-HTTP-Message-6.29 is available

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



--- Comment #6 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c

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 1935417] perl-HTML-Parser-3.76 is available

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



--- Comment #5 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c

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

[Test-Announce] Fedora 35 Rawhide 20210615.n.1 nightly compose nominated for testing

2021-06-15 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora 35 Rawhide 20210615.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 - 20210612.n.1: anaconda-35.16-2.fc35.src, 20210615.n.1: 
anaconda-35.17-1.fc35.src
parted - 20210612.n.1: parted-3.4-3.fc35.src, 20210615.n.1: 
parted-3.4-4.fc35.src

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

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_35_Rawhide_20210615.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210615.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210615.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210615.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210615.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210615.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210615.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

Re: x86_64-v2 in Fedora

2021-06-15 Thread Gary Buhrmaster

On Tue, Jun 15, 2021 at 9:55 PM Neal Gompa  wrote:

> Yeah, I think that proposal was not workable because of AVX2. The
> x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
> current x86_64 baseline. All of these instructions were present in the
> first Intel Macs launched in 2007, as I recall.

I believe the earliest 64-bit capable Intel Macs were using
core 2 processors, and they would not include a couple of
those instructions (which happened with nehalem).
___
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: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

2021-06-15 Thread Tom Stellard


On 5/7/21 10:48 AM, Ben Cotton wrote:

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

== Summary ==
Enable broken RPATH detection
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
buildroot policy] script by default. This will make the RPM build fail
once a broken RPATH was detected within a binary or a shared library
file. An opt-out mechanism will be provided as well.

== Owner ==
* Name: [[User:cstratak| Charalampos Stratakis]]
* Email: cstratak AT redhat.com




Hi,

Was there any testing done to determine how much this script would increase
build times?  I've noticed it takes quite a while on the kernel builds, and
I'm curious what factors influence how long the script takes.  Is it
number of binaries, binary sizes, etc?

-Tom
___
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: x86_64-v2 in Fedora

2021-06-15 Thread Tom Hughes via devel


On 15/06/2021 22:54, Neal Gompa wrote:

On Tue, Jun 15, 2021 at 5:50 PM Fabio Valentini  wrote:


Different question: How is the runtime CPU feature detection /
dispatch support in glibc coming along? Shouldn't this "work" by now?


No idea, good question, though!


If you mean feature level based loading of shared libraries
via hwcaps then it is supposed to be supported in 2.33 which
is in F34.

Tom

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

Re: x86_64-v2 in Fedora

On Tue, Jun 15, 2021 at 5:50 PM Fabio Valentini  wrote:
>
> On Tue, Jun 15, 2021 at 11:35 PM Neal Gompa  wrote:
> >
> > Hey all,
> >
> > Earlier this week, I was helping with processing features for openSUSE
> > Leap 15.4[1] and I discovered that they're planning on introducing
> > x86_64-v2 to openSUSE soon. The reference for this change was that
> > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> > have been considering bumping up to v2 or v3[3][4].
> >
> > Some cursory examination of the new x86_64 sublevels seem to indicate
> > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> > first couple of generations of x86_64 CPUs from Intel and AMD. I
> > personally don't have any computers that don't have support for
> > x86_64-v2 anymore.
> >
> > Does anyone know if anyone is planning to propose this for Fedora
> > anytime soon, either as an addon architecture (like what Arch is
> > doing) or an upgrade of our x86_64 baseline like RHEL is doing?
> >
> > [1]: https://en.opensuse.org/Feature_Planning_15.4
> > [2]: 
> > https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
> > [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html
> > [4]: 
> > https://www.phoronix.com/scan.php?page=news_item=Arch-Linux-x86-64-v3-Port-RFC
>
> Uh ... you mean something like this?
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> Rejected by FESCo two years ago: https://pagure.io/fesco/issue/2198
>
> If I remember correctly, it was shot down pretty quickly on the devil
> list, because Intel still produced CPUs that do not support AVX2.
> Bumping the baseline to x86_64v2 would be different, since AVX is not
> part of that (but only x86_64v3).
>

Yeah, I think that proposal was not workable because of AVX2. The
x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
current x86_64 baseline. All of these instructions were present in the
first Intel Macs launched in 2007, as I recall.

> Different question: How is the runtime CPU feature detection /
> dispatch support in glibc coming along? Shouldn't this "work" by now?
>

No idea, good question, though!




--
真実はいつも一つ！/ 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

[Bug 1972442] New: Please build perl-Math-Round for EPEL8

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

Bug ID: 1972442
   Summary: Please build perl-Math-Round for EPEL8
   Product: Fedora EPEL
   Version: epel8
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Math-Round
  Severity: medium
  Assignee: p...@city-fan.org
  Reporter: or...@nwra.com
QA Contact: extras...@fedoraproject.org
CC: mspa...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:

I'd like to get hsxkpasswd into EPEL8.  This is a missing dependency.  Would
you be willing to build for EPEL8?  Thanks.


-- 
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: x86_64-v2 in Fedora

2021-06-15 Thread Fabio Valentini

On Tue, Jun 15, 2021 at 11:35 PM Neal Gompa  wrote:
>
> Hey all,
>
> Earlier this week, I was helping with processing features for openSUSE
> Leap 15.4[1] and I discovered that they're planning on introducing
> x86_64-v2 to openSUSE soon. The reference for this change was that
> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> have been considering bumping up to v2 or v3[3][4].
>
> Some cursory examination of the new x86_64 sublevels seem to indicate
> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> first couple of generations of x86_64 CPUs from Intel and AMD. I
> personally don't have any computers that don't have support for
> x86_64-v2 anymore.
>
> Does anyone know if anyone is planning to propose this for Fedora
> anytime soon, either as an addon architecture (like what Arch is
> doing) or an upgrade of our x86_64 baseline like RHEL is doing?
>
> [1]: https://en.opensuse.org/Feature_Planning_15.4
> [2]: 
> https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
> [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html
> [4]: 
> https://www.phoronix.com/scan.php?page=news_item=Arch-Linux-x86-64-v3-Port-RFC

Uh ... you mean something like this?
https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
Rejected by FESCo two years ago: https://pagure.io/fesco/issue/2198

If I remember correctly, it was shot down pretty quickly on the devil
list, because Intel still produced CPUs that do not support AVX2.
Bumping the baseline to x86_64v2 would be different, since AVX is not
part of that (but only x86_64v3).

Different question: How is the runtime CPU feature detection /
dispatch support in glibc coming along? Shouldn't this "work" by now?

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

[Bug 1972441] New: Please build perl-Crypt-Random-Source for EPEL8

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

Bug ID: 1972441
   Summary: Please build perl-Crypt-Random-Source for EPEL8
   Product: Fedora
   Version: rawhide
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Crypt-Random-Source
  Severity: medium
  Assignee: emman...@seyman.fr
  Reporter: or...@nwra.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:


I'd like to get hsxkpasswd into EPEL8.  This is required as a dependency of 
perl(Math::Random::Secure).  Would you be willing to build for EPEL8?  If no,
you could add me (orion) as an admin and I could request and build the branch. 
Thanks.


-- 
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: x86_64-v2 in Fedora

2021-06-15 Thread Stephen John Smoogen

On Tue, 15 Jun 2021 at 17:35, Neal Gompa  wrote:

> Hey all,
>
> Earlier this week, I was helping with processing features for openSUSE
> Leap 15.4[1] and I discovered that they're planning on introducing
> x86_64-v2 to openSUSE soon. The reference for this change was that
> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> have been considering bumping up to v2 or v3[3][4].
>
>
Wasn't the last time this was looked at was
https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update?
That spawned the multi hundred thread "Fedora 32 System-Wide Change
proposal: x86-64 micro-architecture update" but I think this was to push
towards level 3. However my review of that thread and some others seemed to
show there was no stomach to move Fedora up without many people dropping
packages etc.

I used this
https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-supports-x86-64-v2
to see what cpu instructions are at each level

```

#!/usr/bin/awk -f

BEGIN {
while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 1
if (level == 1 &&
/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
if (level == 2 &&
/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/)
level = 3
if (level == 3 &&
/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
exit 1
}

```

level 2 is avx and avx2 plus some others.



> Some cursory examination of the new x86_64 sublevels seem to indicate
> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> first couple of generations of x86_64 CPUs from Intel and AMD. I
> personally don't have any computers that don't have support for
> x86_64-v2 anymore.
>
> Does anyone know if anyone is planning to propose this for Fedora
> anytime soon, either as an addon architecture (like what Arch is
> doing) or an upgrade of our x86_64 baseline like RHEL is doing?
>
> [1]: https://en.opensuse.org/Feature_Planning_15.4
> [2]:
> https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
> [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html
> [4]:
> https://www.phoronix.com/scan.php?page=news_item=Arch-Linux-x86-64-v3-Port-RFC
>
> --
> 真実はいつも一つ！/ 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
>


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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

x86_64-v2 in Fedora

Hey all,

Earlier this week, I was helping with processing features for openSUSE
Leap 15.4[1] and I discovered that they're planning on introducing
x86_64-v2 to openSUSE soon. The reference for this change was that
RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
have been considering bumping up to v2 or v3[3][4].

Some cursory examination of the new x86_64 sublevels seem to indicate
that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
first couple of generations of x86_64 CPUs from Intel and AMD. I
personally don't have any computers that don't have support for
x86_64-v2 anymore.

Does anyone know if anyone is planning to propose this for Fedora
anytime soon, either as an addon architecture (like what Arch is
doing) or an upgrade of our x86_64 baseline like RHEL is doing?

[1]: https://en.opensuse.org/Feature_Planning_15.4
[2]: 
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
[3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html
[4]: 
https://www.phoronix.com/scan.php?page=news_item=Arch-Linux-x86-64-v3-Port-RFC

-- 
真実はいつも一つ！/ 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: Can't login with kinit using 2FA

2021-06-15 Thread Michael Catanzaro

On Tue, Jun 15 2021 at 09:18:34 PM +0200, Dan Horák  
wrote:

make sure you have the fedora-packager-kerberos package installed, I
suspect the last update of fedora-packager wasn't right


Whatever is needed for Fedora kerberos to work needs to be a dependency 
of gnome-online-accounts, since Fedora account is a supported account 
type there. You shouldn't need to install anything extra.


FWIW I don't have fedora-packager-kerberos installed, and kerberos is 
still working perfectly fine for me as of today.


___
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: Packages that failed to build with Python 3.10 (and what to do)


On 08. 06. 21 15:58, Tomas Hrnciar wrote:
Chances are, you already got an automated F35FailsToInstall bugzilla from Miro, 
that your package fails to install. It would be really helpful if you could 
find the missing dependency and mark the bugzilla for your package dependingon 
the bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


Hello Pythonistas.

A week has passed and many of the bugzillas received a first automatic 
reminder. I realize that one week might have been too soon for many of them.


If you got a needinfo from me today and thought "What the hell, Miro, I cannot 
do anything, this is waiting for another package to build first", I feel you 
and I am sorry for the spam. Just set the bugzilla to ASSIGNED to acknowledge 
you know about the situation and no more automated reminders like this will 
bother you. I recommend having a look at the dependency that blocks you and 
offering help to move things forward.


OTOH If you are blocked on another package not building, the reminder might get 
things moving: Some of the "Fails to build from source with Python 3.10" 
bugzillas are open with no response for many months and there was no policy to 
escalate them until we merged the side tag.



Anyway,
sorry for the noise and thanks for you help so far!

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that failed to build with Python 3.10 (and what to do)


On 08. 06. 21 15:58, Tomas Hrnciar wrote:
Chances are, you already got an automated F35FailsToInstall bugzilla from Miro, 
that your package fails to install. It would be really helpful if you could 
find the missing dependency and mark the bugzilla for your package dependingon 
the bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


Hello Pythonistas.

A week has passed and many of the bugzillas received a first automatic 
reminder. I realize that one week might have been too soon for many of them.


If you got a needinfo from me today and thought "What the hell, Miro, I cannot 
do anything, this is waiting for another package to build first", I feel you 
and I am sorry for the spam. Just set the bugzilla to ASSIGNED to acknowledge 
you know about the situation and no more automated reminders like this will 
bother you. I recommend having a look at the dependency that blocks you and 
offering help to move things forward.


OTOH If you are blocked on another package not building, the reminder might get 
things moving: Some of the "Fails to build from source with Python 3.10" 
bugzillas are open with no response for many months and there was no policy to 
escalate them until we merged the side tag.



Anyway,
sorry for the noise and thanks for you help so far!

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

[EPEL-devel] Re: Git-annex missing on Fedora EPEL 8

2021-06-15 Thread Troy Dawson

Packages are not automatically branched for each EPEL version. Each package
must be branched by a packager for each particular release, and packagers
may or may not be interested in EPEL-8 while they were interested in
EPEL-7.[1]

The preferred method of asking a maintainer for an EPEL branch is to file a
ticket in bugzilla[2] against the "Fedora EPEL" product.

In short, nobody's asked for it yet.  But you can.

Troy

[1] -
https://fedoraproject.org/wiki/EPEL/FAQ#Why_isn.27t_a_package_in_EPEL-8_when_it_is_in_EPEL-7.3F
[2] - https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL

On Tue, Jun 15, 2021 at 1:40 PM Odilon Junior 
wrote:

> Hi Team,
>
> I was looking for git-annex on EPEL 8 and it looks like the package is not
> present, even though I can see the package on EL7/F34/F35, is there any
> reason for git-annex to not be present for EL8?
>
> I'm a member of the Foreman[1]/Katello team, we are in the process of
> moving  from EL7 to EL8 in our infra, git-annex is heavily used in our
> builds. Should we check another place for this package?
>
> ---
> Regards,
> Odilon Junior
>
> 1 - https://theforeman.org/
> ___
> 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

[EPEL-devel] Re: Git-annex missing on Fedora EPEL 8

On Tue, Jun 15, 2021 at 4:39 PM Odilon Junior  wrote:
>
> Hi Team,
>
> I was looking for git-annex on EPEL 8 and it looks like the package is not 
> present, even though I can see the package on EL7/F34/F35, is there any 
> reason for git-annex to not be present for EL8?
>
> I'm a member of the Foreman[1]/Katello team, we are in the process of moving  
> from EL7 to EL8 in our infra, git-annex is heavily used in our builds. Should 
> we check another place for this package?

Seems like the branch was made but the work wasn't done yet. Do any of
the maintainers know why this hasn't happened yet?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: Azure CLI + SDK, side tags, and metapackages


On 15. 06. 21 22:30, Major Hayden wrote:
but it still feels like obsoleting it might make the most sense and take the 
least amount of effort.


I agree.

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

[EPEL-devel] Git-annex missing on Fedora EPEL 8

2021-06-15 Thread Odilon Junior

Hi Team,

I was looking for git-annex on EPEL 8 and it looks like the package is not
present, even though I can see the package on EL7/F34/F35, is there any
reason for git-annex to not be present for EL8?

I'm a member of the Foreman[1]/Katello team, we are in the process of
moving  from EL7 to EL8 in our infra, git-annex is heavily used in our
builds. Should we check another place for this package?

---
Regards,
Odilon Junior

1 - https://theforeman.org/
___
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

Re: Azure CLI + SDK, side tags, and metapackages

2021-06-15 Thread Major Hayden


On 6/14/21 8:30 AM, Miro Hrončok wrote:

  2) How do I convert the python-azure-sdk package into a no-files
 metapackage that brings in all of the SDK components?


I.   Bump the metadata to a newer version-release (artificial?).
II.  Remove all sources and contents of %prep/%build/%install.
III. Remove all listed %files but keep the %files section.
IV.  Adapt other metdata like description, summary etc.
V.   Add the requirements that brings in all of the SDK components.
VI.  Use `%py_provides python3-azure-sdk` in the python3-azure-sdk 
package, as this is required for Python meta-packages without files.



 (Is this even a good idea?)


That depends. Would the users still want to `dnf install 
python3-azure-sdk`? If no, I would rather retire and obsolete the 
package from the relevant replacements. If you Obsolete a package from N 
other packages, they replace the obsoleted package during upgrade (all 
of them).


I keep thinking about this over and over, and I don't know if I can see 
a reason why someone would want to install python3-azure-sdk instead of 
just installing component or components that they need. The biggest 
consumer of these components is the azure-cli package, and it will 
automatically have all of the python requirements added via Requires -- 
the big python-azure-sdk package won't be needed for that.


I know the original maintainer wanted to keep the python-azure-sdk 
package around, but it still feels like obsoleting it might make the 
most sense and take the least amount of effort.


I'm torn! 

--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


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

FedoraRespin-34-updates-20210615.0 compose check report

No missing expected images.

Failed openQA tests: 2/42 (x86_64)

ID: 908853  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/908853
ID: 908866  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/908866

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

Re: Azure CLI + SDK, side tags, and metapackages

2021-06-15 Thread Major Hayden


On 6/14/21 7:40 AM, Major Hayden wrote:

   3) How should I go about getting these smaller packages reviewed?
  The majority of them are almost identical.


All of the Azure SDK components are up for review[0].

It's a lot to review (about 83 packages), but almost all of them are 
identical except for some differently-formatted READMEs and LICENSE files.


Thanks for any review help that anyone can provide!

[0] 
https://bugzilla.redhat.com/buglist.cgi?list_id=11947658=Python%20Azure%20SDK%20Reviews


--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


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: Can't login with kinit using 2FA

2021-06-15 Thread Dan Horák

On Tue, 15 Jun 2021 10:59:32 -0700
Kevin Fenzi  wrote:

> On Tue, Jun 15, 2021 at 01:51:01PM -, Yaroslav Sidlovsky wrote:
> > Hello there!
> > 
> > I've using this guide: 
> > https://fedoraproject.org/wiki/Infrastructure/Kerberos.
> > When I'm trying to execute command `kinit -n @FEDORAPROJECT.ORG -c 
> > FILE:$HOME/armor.ccache`, I see this error:
> > ```
> > Password for WELLKNOWN/anonym...@fedoraproject.org:
> > ^C
> > ```
> > 
> > A week ago I was able to login without problems using same guide.
> > What's wrong?

make sure you have the fedora-packager-kerberos package installed, I
suspect the last update of fedora-packager wasn't right


Dan

> 
> check your /etc/krb5.conf file and make sure you have:
> 
> forwardable = true
> rdns = false
> 
> Also, make sure you have fedora-packager-kerberos package installed.
> It was recently split off the fedora-packager package.
> 
> Also, note that there is a 'fkinit' command now that does both parts for
> you. :)
> 
> 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

[Bug 1972385] New: perl-POE-Component-IRC-6.93 is available

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

Bug ID: 1972385
   Summary: perl-POE-Component-IRC-6.93 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-POE-Component-IRC
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: andrea.v...@gmail.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.93
Current version/release in rawhide: 6.92-1.fc35
URL: http://search.cpan.org/dist/POE-Component-IRC/

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


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

[389-devel] please review: PR 4807 - Repl Plugin name upgrade did not update global dependency plugin list

2021-06-15 Thread Mark Reynolds


https://github.com/389ds/389-ds-base/pull/4807

--

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

Re: userspace-rcu 0.13.0 soname bump

2021-06-15 Thread Michael Jeanson


On 2021-06-08 14 h 30, Michael Jeanson wrote:
I have started the process to update userspace-rcu to 0.13 in rawhide 
which implies a soname bump to 8.


 From what I understand, the following packages will need to be rebuilt:

device-mapper-multipath
glusterfs
knot
libntirpc
lttng-tools
lttng-ust
netsniff-ng
nfs-ganesha


I have created a side tag 'f35-build-side-42347' and built 
userspace-rcu, lttng-ust and lttng-tools. At this point I'm unsure what 
the rest of the procedure is to get the other packages built in this tag 
and then get them pushed to rawhide once it's done.


Michael


Hi,

The following packages still need to be rebuilt in the tag:

 - device-mapper-multipath
 - knot
 - netsniff-ng

I added the maintainers in CC in case they don't read fedora-devel, 
sorry if that's considered bad form.


At this point what is the recommended amount of time to wait before 
merging back the side tag?


Regards,

Michael
___
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: Can't login with kinit using 2FA

2021-06-15 Thread Kevin Fenzi

On Tue, Jun 15, 2021 at 01:51:01PM -, Yaroslav Sidlovsky wrote:
> Hello there!
> 
> I've using this guide: https://fedoraproject.org/wiki/Infrastructure/Kerberos.
> When I'm trying to execute command `kinit -n @FEDORAPROJECT.ORG -c 
> FILE:$HOME/armor.ccache`, I see this error:
> ```
> Password for WELLKNOWN/anonym...@fedoraproject.org:
> ^C
> ```
> 
> A week ago I was able to login without problems using same guide.
> What's wrong?

check your /etc/krb5.conf file and make sure you have:

forwardable = true
rdns = false

Also, make sure you have fedora-packager-kerberos package installed.
It was recently split off the fedora-packager package.

Also, note that there is a 'fkinit' command now that does both parts for
you. :)

kevin


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

Can't login with kinit using 2FA

2021-06-15 Thread Yaroslav Sidlovsky

Hello there!

I've using this guide: https://fedoraproject.org/wiki/Infrastructure/Kerberos.
When I'm trying to execute command `kinit -n @FEDORAPROJECT.ORG -c 
FILE:$HOME/armor.ccache`, I see this error:
```
Password for WELLKNOWN/anonym...@fedoraproject.org:
^C
```

A week ago I was able to login without problems using same guide.
What's wrong?
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Ewoud Kohl van Wijngaarden


On Tue, Jun 15, 2021 at 12:50:03PM +0200, Petr Viktorin wrote:

On 15. 06. 21 2:11, Neal Gompa wrote:

It's not terribly different from how organizations may have private
Python package indexes that may use whatever names they want for
Python software they build and release.


I agree, in fact, I think Fedora's problems here are a subset of the 
problems the private organizations have: if issues of proprietary 
corps are solved, we can use the solution as well. (However, it'll 
need more work than is necessary for Fedora/FOSS needs, so I don't 
want to drive the effort.)
BUT, if the issues are solved, it'll likely be through namespacing: 
we'd need to prefix our names with `fedora-` or `fedora:`. I still 
think it is better for Fedora to reuse the public PyPI namespace 
rather than start its own.


Registering on PyPI for private packages can be useful to avoid 
dependency confusion attacks[1]. Essentially we're talking about the 
same problem here.


[1]: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
___
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: older than 30 days and empty side tag clean up

2021-06-15 Thread Kevin Fenzi

On Tue, Jun 15, 2021 at 05:56:54PM +0200, Christoph Karl wrote:
> Hi!
> 
> On 04.06.21 at 19:11 Kevin Fenzi wrote:
> > Release engineering has just enabled a cron job to remove koji side tags
> > that are older than 30 days or have no builds tagged into them.
> 
> Is this 30 days after creating or last write access or last read access?

Currently it's 30 days after creating. 

It might be nice to key off last access, but we would need to ask koji
folks for that ehancement ( https://pagure.io/koji )

kevin


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

Re: Improving Fedora sponsors discoverability

2021-06-15 Thread Kevin Fenzi

On Fri, Jun 11, 2021 at 05:03:36PM +0200, Jakub Kadlcik wrote:
> Hello fellow Fedora people,
> 
> Inspired by @msuchy's Flock 2016 presentation, I
> would like to tackle one of the topics discussed there - The
> discoverability of Fedora sponsors for newcomers.

Thanks for taking this on! :) 

> I have a website ready to be deployed. If you are interested in the
> technical details, please see this RFE
> 
> https://pagure.io/packager-sponsors/issue/470
> 
> and also the code
> 
> https://github.com/FrostyX/fedora-sponsors
> 
> The page design is as simple as possible. You can see some screenshots
> here.
> 
> https://pagure.io/packager-sponsors/issue/470#comment-735105

Looks pretty cool. Not sure it would be something for the first cut, or
later, but it might be nice to have a way to list 'preferred' contact
method? This might be something we could add to the account system also
and you could just get it from there? (ie, IRC, Matrix, email, other)
> 
> A very important feature to me is grouping sponsors by their areas of
> interests / expertise, and I would like to ask for your help in this
> matter.
> 
> At this moment, I have manually defined areas such as Python, C/C++,
> Haskell, Ruby, Functional programming, Web development, Modularity,
> etc and manually assigned people to them (the small number, that I
> personally know that do these kinds of things).
> 
> Do you have any idea if there is a way to generate such areas and tie
> people to them based on some already existing information within the
> Fedora infrastructure?

There are packager groups... could perhaps look at them and get sponsors
from them? ie, python-sig, graphics-sig, etc?

kevin


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

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


On 15. 06. 21 19:34, Ewoud Kohl van Wijngaarden wrote:
And for those of us who also maintain packages for EL7/8, what's the 
availability of these macros?


Whenever technically possible, we add our new Python macros to EPEL 7+.
Sometimes, we even backport them to plain RHEL 8+.

This can (and will) be done for the proposed "import test" macro.

However, the pyproject RPM macros use RPM features not yet available in RHEL 8, 
so we won't be adding those.


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

Summary/Minutes from today's FESCo Meeting (2021-06-15)

2021-06-15 Thread Stephen Gallagher

===
#fedora-meeting: FESCO (2021-06-15)
===


Meeting started by sgallagh[m] at 17:00:04 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2021-06-15/fesco.2021-06-15-17.00.log.html
.



Meeting summary
---
* init process  (sgallagh[m], 17:00:04)

* New Meeting Time  (sgallagh[m], 17:03:12)
  * LINK: https://whenisgood.net/fesco2021-again/results/2nddce4
(sgallagh[m], 17:03:12)
  * LINK: https://en.wikipedia.org/wiki/Time_in_Indiana   (dcantrell,
17:10:50)
  * AGREED: FESCo meetings will occur at 1900 UTC beginning June 21st
(sgallagh[m], 17:14:39)

* #2617 F35 Change: Make btrfs the default file system for Fedora Cloud
  (sgallagh[m], 17:15:22)
  * LINK: https://pagure.io/fesco/issue/2617#comment-737963 has the most
recent information and is not long  (mhroncok, 17:17:05)
  * AGREED: FESCo accepts the "Cloud Images on btrfs" Change for F35.
(+8, 1, -0)  (sgallagh[m], 17:20:31)

* Next week's chair  (sgallagh[m], 17:22:52)
  * ACTION: nirik will chair the June 21 meeting  (sgallagh[m],
17:26:16)

* Open Floor  (sgallagh[m], 17:26:49)
  * LINK: https://opensuse.venueless.events/schedule/talks/26
(bcotton, 17:32:16)
  * Fedora is sponsoring an openSUSE conference this weekend. Join us
there!  (sgallagh[m], 17:34:00)
  * LINK:
https://events.opensuse.org/conferences/oSVC21/program/proposals/3501
(defolos, 17:34:03)
  * LINK: https://events.opensuse.org/conferences/oSVC21
(Eighth_Doctor, 17:34:09)
  * LINK: https://opensuse.venueless.events/schedule/talks/26
(sgallagh[m], 17:34:10)
  * LINK:
https://events.opensuse.org/conferences/oSVC21/program/proposals/3501
(sgallagh[m], 17:34:39)

Meeting ended at 17:36:29 UTC.




Action Items

* nirik will chair the June 21 meeting




Action Items, by person
---
* nirik
  * nirik will chair the June 21 meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh[m] (62)
* Eighth_Doctor (41)
* defolos (36)
* zodbot (33)
* mhroncok (29)
* michel (16)
* nirik (15)
* dcantrell (13)
* mboddu (13)
* decathorpe (10)
* zbyszek (8)
* bcotton (5)
* dcavalca (4)
* cmurf (4)
* Conan_Kudo (1)
* adamw (1)
* Sir_Gallantmon (0)
* sgallagh (0)
* King_InuYasha (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Ewoud Kohl van Wijngaarden


On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby packaging 
we've also felt a similar pain. Mostly with C extensions that were built 
in the wrong directory. We also added a %check section to do a basic 
"import" (require) test.


Is there a similar macro for Ruby smoke testing?

And for those of us who also maintain packages for EL7/8, what's the 
availability of these macros?

___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Dan Čermák

Petr Viktorin  writes:

> On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote:
>> On 14.06.2021 15:32, Ben Cotton wrote:
>>> Running upstream tests is mandatory.
>> 
>> What about tests that require network access?
>
>
> Thanks for this and all the other concerns about mandatory tests!
> I updated the proposal to mane them not mandatory, but require a smoke 
> test if they're not there.
> I also removed the mention of Fedora CI: it was meant as an escape hatch 
> for tests that need network, but that's now unnecessary.
>
> Diff: 
> https://pagure.io/fork/pviktori/packaging-committee/c/ec9643873c989e0ff264128891665f6ad78f3e4a?branch=new-py-guidelines
> History including other minor changes: 
> https://pagure.io/fork/pviktori/packaging-committee/commits/new-py-guidelines
>
> New wording:
>
> If a test suite exists upstream,
> it *SHOULD* be run in the `+%check+` section.
> If that is not possible with reasonable effort,
> at least a basic smoke test (such as importing the packaged module)
> *MUST* be run in `+%check+`.
>
> You *MAY* exclude specific failing tests.
> You *MUST NOT* disable the entire testsuite
> or ignore its result to solve a build failure.
>
> As an exception,
> you *MAY* disable tests with an appropriate `+%if+` conditional
> (e.g. http://rpm.org/user_doc/conditional_builds.html[bcond])
> when xref:index.adoc#bootstrapping[bootstrapping].
>
> Most errors in Python happen at run-time,
> so tests are extremely important to root out issues,
> especially when mass rebuilds are required.
>
> Common reasons for skipping tests in `+%check+` include requiring
> network access,
> dependencies not packaged in Fedora,
> and/or specialized hardware or resources.

This is much better, thank you! And thanks Miro for the new macro!


Cheers,

Dan
___
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] [Fedocal] Reminder meeting : EPEL Steering Committee

2021-06-15 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-06-16 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.net

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




Source: https://calendar.fedoraproject.org//meeting/9854/

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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2021-06-15 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-06-16 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.net

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9854/

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

Re: older than 30 days and empty side tag clean up

2021-06-15 Thread Christoph Karl


Hi!

On 04.06.21 at 19:11 Kevin Fenzi wrote:

Release engineering has just enabled a cron job to remove koji side tags
that are older than 30 days or have no builds tagged into them.


Is this 30 days after creating or last write access or last read access?

Thank you

Best Regards
Christoph
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


On 15. 06. 21 13:48, Neal Gompa wrote:

On Tue, Jun 15, 2021 at 6:50 AM Petr Viktorin  wrote:


Hi Neal,
We had this conversation in the past (and you can see it in the change).
I don't think I can convince you, but I'll reiterate since it's new for
devel@.

Unlike the "mandatory tests" issue elsewhere in this thread, using the
PyPI namespace is the main point of the change. I can't take it out.


On 15. 06. 21 2:11, Neal Gompa wrote:

On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer  wrote:


On 6/14/21 1:53 PM, Neal Gompa wrote:

This is completely unreasonable. The dist-info/egg-info data of a
Python module is for generating dependencies, not for forcing people
to deal with PyPI.



I don't think we can reasonably separate the two.

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

(I believe this is the "namespace" issue mentioned in the proposed change.)


You can. When it comes to distribution packages, we can maintain
consistency of the package names referenced within the distribution.
The point of this was to be able to use the names Python packages call
themselves for dependencies. PyPI is merely a distribution center for
such things. Fedora is another distribution center for such things.


You can only separate the namespaces if you sacrifice interoberability,
i.e. allowing pip-installable packages to depend on Fedora packages.
It turns out you can already do that (venv --system-site-packages), and
users expect that dist-info project names use the PyPI namespace. This
is a current problem that we need to solve.

There are other (harder) solutions for the issue than reusing the PyPI
namespace in Fedora, but why should we bother with them? There already
is an ecosystem-wide namespace; why should we add a Fedora-specific one?
(Or a Linux-distro-specific one, if we're interested in cross-distro
collaboration.)

You seem to assume that registering/blocking a name on PyPI is hard.
I say it is not and I am willing to do it for packagers who need it.
(And to mitigate the bus factor, I'll make it a responsibility of Red
Hat's python-maint team.)


It's not terribly different from how organizations may have private
Python package indexes that may use whatever names they want for
Python software they build and release.


I agree, in fact, I think Fedora's problems here are a subset of the
problems the private organizations have: if issues of proprietary corps
are solved, we can use the solution as well. (However, it'll need more
work than is necessary for Fedora/FOSS needs, so I don't want to drive
the effort.)
BUT, if the issues are solved, it'll likely be through namespacing: we'd
need to prefix our names with `fedora-` or `fedora:`. I still think it
is better for Fedora to reuse the public PyPI namespace rather than
start its own.


As long as you don't make packagers deal with it, I'm fine with it.
I'm okay with the PyPI contract as long as you don't make me or any
other Fedora packager specifically deal with it. And I strongly
suspect you're going to want automation in the future, but that choice
is up to you.


When packaging something that isn't on PyPI, you can let me know (on 
python-de...@lists.fedoraproject.org ) and I'll get the name blocked. I 
expect this to be rare enough to not need automation.


If the name *conflicts* with something on PyPI, then also let me know. 
Dealing with that issue might be more difficult, and it might involve 
you more. Still, this situation is confusing for users, so I think it's 
fair to want to solve it.

(And again, I'm not expecting existing packages to do this *right* now.)
___
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: Problem: package python3-qt5-5.15.0-4.fc33.x86_64 requires libQt5Multimedia.so.5()(64bit), but none of the providers can be installed

2021-06-15 Thread Martin Gansser

thanks for your information.
___
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 1932205] perl-IPTables-libiptc-0.52-36.fc35 FTBFS: iptables-detect-version.c:65:2: warning: #warning "This version of xtables is currently not supported by this Perl package

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



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


-- 
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: Problem: package python3-qt5-5.15.0-4.fc33.x86_64 requires libQt5Multimedia.so.5()(64bit), but none of the providers can be installed

2021-06-15 Thread Leigh Scott

It should be fixed 
https://bodhi.fedoraproject.org/updates/FEDORA-2021-f90ebff42e
aom has been untagged from overrides.
___
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: intent to retire python-glusterfs-api

2021-06-15 Thread Kaleb Keithley

On Tue, Jun 15, 2021 at 10:09 AM Miro Hrončok  wrote:

> On 15. 06. 21 16:00, Kaleb Keithley wrote:
> >
> > There have been no updates since 2018.
> >
> > If someone else wants to take it over I'm happy to transfer it to them.
> >
> > Otherwise I will retire it in one week's time.
>
> Hey Kaleb.
>
> Consider orphaning it today instead. The package will be availabe for
> taking
> for 6 weeks and retired eventually if not adapted.
>
>
Okay, fine with me.

--

Kaleb
___
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: intent to retire python-glusterfs-api


On 15. 06. 21 16:00, Kaleb Keithley wrote:


There have been no updates since 2018.

If someone else wants to take it over I'm happy to transfer it to them.

Otherwise I will retire it in one week's time.


Hey Kaleb.

Consider orphaning it today instead. The package will be availabe for taking 
for 6 weeks and retired eventually if not adapted.


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

Problem: package python3-qt5-5.15.0-4.fc33.x86_64 requires libQt5Multimedia.so.5()(64bit), but none of the providers can be installed

2021-06-15 Thread Martin Gansser

Hi,

I tried to build Carla for f33 on koji, but hist fails with this error message 
[1]:

DEBUG util.py:444:  No matches found for the following disable plugin patterns: 
local, spacewalk
DEBUG util.py:446:  Package make-1:4.3-2.fc33.x86_64 is already installed.
DEBUG util.py:444:  Error: 
DEBUG util.py:444:   Problem: package python3-qt5-5.15.0-4.fc33.x86_64 requires 
libQt5Multimedia.so.5()(64bit), but none of the providers can be installed
DEBUG util.py:444:- package python3-qt5-5.15.0-4.fc33.x86_64 requires 
libQt5Multimedia.so.5(Qt_5)(64bit), but none of the providers can be installed
DEBUG util.py:444:- package python3-qt5-5.15.0-4.fc33.x86_64 requires 
libQt5MultimediaWidgets.so.5()(64bit), but none of the providers can be 
installed
DEBUG util.py:444:- package python3-qt5-5.15.0-4.fc33.x86_64 requires 
libQt5MultimediaWidgets.so.5(Qt_5)(64bit), but none of the providers can be 
installed
DEBUG util.py:444:- package python3-qt5-devel-5.15.0-4.fc33.x86_64 requires 
python3-qt5(x86-64) = 5.15.0-4.fc33, but none of the providers can be installed
DEBUG util.py:444:- package qt5-qtmultimedia-5.15.2-2.fc33.x86_64 requires 
libgstphotography-1.0.so.0()(64bit), but none of the providers can be installed
DEBUG util.py:444:- conflicting requests
DEBUG util.py:444:- nothing provides libaom.so.2()(64bit) needed by 
gstreamer1-plugins-bad-free-1.18.2-1.fc33.x86_64
DEBUG util.py:446:  (try to add '--skip-broken' to skip uninstallable packages)


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=70143855
[2] https://src.fedoraproject.org/rpms/Carla/blob/rawhide/f/Carla.spec

how can i solve this problem ?

Regards
Martin
___
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: [Fedocal] Reminder meeting : Prioritized bugs and issues

2021-06-15 Thread Ben Cotton

On Tue, Jun 15, 2021 at 7:00 AM  wrote:
>
> You are kindly invited to the meeting:
>Prioritized bugs and issues on 2021-06-16 from 11:00:00 to 12:00:00 
> America/Indiana/Indianapolis
>At fedora-meetin...@libera.chat
>
> More information available at: 
> https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/
>

The following bugs are nominated for Prioritized Bug status:

* A glibc test hangs upon pthread cancellation when glibc is compiled
with annobin turned on —
https://bugzilla.redhat.com/show_bug.cgi?id=1951492
* Boot fails, or slow and partly broken, with dracut 054+ and
bluetooth keyboard (possibly other scenarios also) —
https://bugzilla.redhat.com/show_bug.cgi?id=1964879

Additionally, one open bug is currently accepted:

* Akonadi does not start due to DB failure —
https://bugzilla.redhat.com/show_bug.cgi?id=1953675

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

intent to retire python-glusterfs-api

2021-06-15 Thread Kaleb Keithley

There have been no updates since 2018.

If someone else wants to take it over I'm happy to transfer it to them.

Otherwise I will retire it in one week's time.

--

Kaleb
___
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 1972092] perl-WebService-Dropbox-2.09 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-WebService-Dropbox-2.0 |perl-WebService-Dropbox-2.0
   |8b is available |9 is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.09
Current version/release in rawhide: 2.07-13.fc35
URL: http://search.cpan.org/dist/WebService-Dropbox/

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


-- 
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 1959040] perl-HTTP-Message-6.30 is available

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



--- Comment #4 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been submitted as an update to Fedora 34
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c


-- 
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 1936221] perl-libwww-perl-6.53 is available

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



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been submitted as an update to Fedora 34
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c


-- 
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 1940699] perl-Net-HTTP-6.21 is available

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



--- Comment #11 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been submitted as an update to Fedora 34
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c


-- 
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 1936048] perl-HTTP-Message-6.29 is available

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



--- Comment #5 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been submitted as an update to Fedora 34
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c


-- 
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 1935417] perl-HTML-Parser-3.76 is available

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



--- Comment #4 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been submitted as an update to Fedora 34
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c


-- 
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 1930887] perl-HTTP-Message-6.28 is available

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



--- Comment #2 from Fedora Update System  ---
FEDORA-MODULAR-2021-05ccc9574c has been submitted as an update to Fedora 34
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-05ccc9574c


-- 
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 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS

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

Michael Kaplan  changed:

   What|Removed |Added

 Depends On||1972191, 1972192




-- 
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 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS

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

Michael Kaplan  changed:

   What|Removed |Added

 Depends On||1972188, 1972189




-- 
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


On 14. 06. 21 21:00, Miro Hrončok wrote:


I tentatively agree with the idea of requiring an “import foo.bar” smoke test 
in cases where the upstream tests cannot be used, especially since 
pyproject-rpm-macros with %pyproject_buildrequires makes it much easier to 
add runtime dependencies as BR’s. (It may not always be practical to 
explicitly import all subpackages/modules in a complicated package, but even 
importing the top-level package is a good start). It would catch a large 
portion of the FTI bugs that appear in practice.


We could very well add a macro helper that imports modules from the 
%{buildroot} and:


  - when given positional arguments, import the given names


Proof of concept:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99

--
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99

--
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Tue, Jun 15, 2021 at 6:50 AM Petr Viktorin  wrote:
>
> Hi Neal,
> We had this conversation in the past (and you can see it in the change).
> I don't think I can convince you, but I'll reiterate since it's new for
> devel@.
>
> Unlike the "mandatory tests" issue elsewhere in this thread, using the
> PyPI namespace is the main point of the change. I can't take it out.
>
>
> On 15. 06. 21 2:11, Neal Gompa wrote:
> > On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer  
> > wrote:
> >>
> >> On 6/14/21 1:53 PM, Neal Gompa wrote:
> >>> This is completely unreasonable. The dist-info/egg-info data of a
> >>> Python module is for generating dependencies, not for forcing people
> >>> to deal with PyPI.
> >>
> >>
> >> I don't think we can reasonably separate the two.
> >>
> >> https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
> >>
> >> (I believe this is the "namespace" issue mentioned in the proposed change.)
> >
> > You can. When it comes to distribution packages, we can maintain
> > consistency of the package names referenced within the distribution.
> > The point of this was to be able to use the names Python packages call
> > themselves for dependencies. PyPI is merely a distribution center for
> > such things. Fedora is another distribution center for such things.
>
> You can only separate the namespaces if you sacrifice interoberability,
> i.e. allowing pip-installable packages to depend on Fedora packages.
> It turns out you can already do that (venv --system-site-packages), and
> users expect that dist-info project names use the PyPI namespace. This
> is a current problem that we need to solve.
>
> There are other (harder) solutions for the issue than reusing the PyPI
> namespace in Fedora, but why should we bother with them? There already
> is an ecosystem-wide namespace; why should we add a Fedora-specific one?
> (Or a Linux-distro-specific one, if we're interested in cross-distro
> collaboration.)
>
> You seem to assume that registering/blocking a name on PyPI is hard.
> I say it is not and I am willing to do it for packagers who need it.
> (And to mitigate the bus factor, I'll make it a responsibility of Red
> Hat's python-maint team.)
>
> > It's not terribly different from how organizations may have private
> > Python package indexes that may use whatever names they want for
> > Python software they build and release.
>
> I agree, in fact, I think Fedora's problems here are a subset of the
> problems the private organizations have: if issues of proprietary corps
> are solved, we can use the solution as well. (However, it'll need more
> work than is necessary for Fedora/FOSS needs, so I don't want to drive
> the effort.)
> BUT, if the issues are solved, it'll likely be through namespacing: we'd
> need to prefix our names with `fedora-` or `fedora:`. I still think it
> is better for Fedora to reuse the public PyPI namespace rather than
> start its own.

As long as you don't make packagers deal with it, I'm fine with it.
I'm okay with the PyPI contract as long as you don't make me or any
other Fedora packager specifically deal with it. And I strongly
suspect you're going to want automation in the future, but that choice
is up to you.




--
真実はいつも一つ！/ 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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Vitaly Zaitsev via devel


On 15.06.2021 13:33, Petr Viktorin wrote:

If a test suite exists upstream,
it *SHOULD* be run in the `+%check+` section.


LGTM now. Many thanks.


If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test

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

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


On 15. 06. 21 13:32, Alexander Bokovoy wrote:

On ti, 15 kesä 2021, Petr Viktorin wrote:

On 14. 06. 21 20:09, Alexander Bokovoy wrote:

On ma, 14 kesä 2021, Ben Cotton wrote:

[...]

 PyPI Parity 

Machine-readable metadata (''distribution'' names in
dist-info directories on disk and the corresponding
python3.Xdist(foo) RPM provides) will match the Python
Package Index (PyPI).

This solves a ''namespace'' issue. Python packaging tools use a flat 
namespace,
and PyPI is ''the'' place where open-source Python packages are 
generally
published, so users and tools assume a package called 
requests

is whatever requests means on PyPI.
While this is not ideal (especially for private packages), it makes 
sense

for Fedora to align with the PyPI namespace.

Note that Fedora package names are not affected – just the Python 
packaging

metadata on disk and virtual RPM Provides generated from it.

The new guidelines cover what to do for packages that cannot be 
registered

on PyPI. The Change owner is prepared to help with PyPI registration.

Note that names found in Fedora but not on PyPI
[https://github.com/pypa/pypi-support/issues/355 have been reserved 
on PyPI]

to avoid being taken by unrelated projects.


samba has extensive Python C bindings but does not use PyPI at all. We
don't want to, we don't need to, it is technically not possible without
building Samba from scratch and it would not make it usable for PIP
install without a stricter coordination of the non-Python dependencies
-- that's what Linux distributions do.

In addition, 'samba' name is taken by an unrelated package on PyPI which
was not updated since 2019. For us this namespacing enforcement would
only be a problem.


Then I'd recommend that the project name in dist-info metadata would 
be, for example "samba-bindings".


Samba Python bindings have no dist-info metadata. Does it need to? The
bindings are consumed by few projects around Samba but none of them has
anything related on PyPI. What exists on PyPI is either an outdated
stuff without upstream sources or a reference to a similar outdated
stuff, none of which is using Samba Python bindings.


It doesn't need to have dist-info metadata, but I believe it would be 
better if it did, so that it's *possible* to encode "requires Samba" in 
Python packaging metadata.
(*Should* the bindings be consumed by more than a few projects around 
Samba? If yes, it dist-info would make it easier.)


There should also be a good way to add dist-info metadata to projects 
*like* Samba, even if Samba packagers decide they don't want it.


This matters in cases like a pip-installable package declaring a 
dependency on Samba bindings: it now can't use `samba` because that 
means something else on PyPI.


There are already unrelated projects with Samba name on PyPI. This
change in Fedora guidelines cannot affect those. It cannot also affect
actual use of Samba Python bindings. It looks like there is no real use
of PyPI for our use case either, so why the fuss for this particular
package?

I suspect at best we'd submit a request for exception, if pressed.


No pressure; this is exactly why the old guidelines aren't going anywhere.


I fully agree about not installing Samba itself via pip.

(Also, this is one of the cases that might take a decade -- I'm not 
putting pressure on you to implement this, but pointing out a 
direction for the future.)


Frankly, I do not see a real use case for what you might see in other
projects. We had a similar issue with FreeIPA and what we provide on
PyPI is a crippled subset of FreeIPA Python modules that mostly does not
use real FreeIPA features. To date, I am not sure it is really bringing
any benefit to us (upstream).

This does not mean the whole effort is useless, not at all. It means, in
my opinion, that proposed guidelines are failing to address real world
use cases present in Fedora. Invalidating these use cases is as bad as
dropping the guidelines' changes in one go. ;)


Don't put Samba or FreeIPA up on PyPI. But provide a name in dist-info, 
so packages on PyPI can depend on Samba/FreeIPA (which need to be 
installed separately). And reserve that name, so  no one else can put it 
on PyPI either.


Again, no pressure, just a direction for the future.

___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote:

On 14.06.2021 15:32, Ben Cotton wrote:

Running upstream tests is mandatory.

What about tests that require network access?

Thanks for this and all the other concerns about mandatory tests!
I updated the proposal to mane them not mandatory, but require a smoke
test if they're not there.
I also removed the mention of Fedora CI: it was meant as an escape hatch
for tests that need network, but that's now unnecessary.

Diff:
https://pagure.io/fork/pviktori/packaging-committee/c/ec9643873c989e0ff264128891665f6ad78f3e4a?branch=new-py-guidelines
History including other minor changes:
https://pagure.io/fork/pviktori/packaging-committee/commits/new-py-guidelines

New wording:

If a test suite exists upstream,
it *SHOULD* be run in the `+%check+` section.
If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.

You *MAY* exclude specific failing tests.
You *MUST NOT* disable the entire testsuite
or ignore its result to solve a build failure.

As an exception,
you *MAY* disable tests with an appropriate `+%if+` conditional
(e.g. http://rpm.org/user_doc/conditional_builds.html[bcond])
when xref:index.adoc#bootstrapping[bootstrapping].

Most errors in Python happen at run-time,
so tests are extremely important to root out issues,
especially when mass rebuilds are required.

Common reasons for skipping tests in `+%check+` include requiring
network access,
dependencies not packaged in Fedora,
and/or specialized hardware or resources.
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Alexander Bokovoy


On ti, 15 kesä 2021, Petr Viktorin wrote:

On 14. 06. 21 20:09, Alexander Bokovoy wrote:

On ma, 14 kesä 2021, Ben Cotton wrote:

[...]

 PyPI Parity 

Machine-readable metadata (''distribution'' names in
dist-info directories on disk and the corresponding
python3.Xdist(foo) RPM provides) will match the Python
Package Index (PyPI).

This solves a ''namespace'' issue. Python packaging tools use a 
flat namespace,

and PyPI is ''the'' place where open-source Python packages are generally
published, so users and tools assume a package called 
requests

is whatever requests means on PyPI.
While this is not ideal (especially for private packages), it makes sense
for Fedora to align with the PyPI namespace.

Note that Fedora package names are not affected – just the Python 
packaging

metadata on disk and virtual RPM Provides generated from it.

The new guidelines cover what to do for packages that cannot be 
registered

on PyPI. The Change owner is prepared to help with PyPI registration.

Note that names found in Fedora but not on PyPI
[https://github.com/pypa/pypi-support/issues/355 have been 
reserved on PyPI]

to avoid being taken by unrelated projects.


samba has extensive Python C bindings but does not use PyPI at all. We
don't want to, we don't need to, it is technically not possible without
building Samba from scratch and it would not make it usable for PIP
install without a stricter coordination of the non-Python dependencies
-- that's what Linux distributions do.

In addition, 'samba' name is taken by an unrelated package on PyPI which
was not updated since 2019. For us this namespacing enforcement would
only be a problem.


Then I'd recommend that the project name in dist-info metadata would 
be, for example "samba-bindings".


Samba Python bindings have no dist-info metadata. Does it need to? The
bindings are consumed by few projects around Samba but none of them has
anything related on PyPI. What exists on PyPI is either an outdated
stuff without upstream sources or a reference to a similar outdated
stuff, none of which is using Samba Python bindings.

This matters in cases like a pip-installable package declaring a 
dependency on Samba bindings: it now can't use `samba` because that 
means something else on PyPI.


There are already unrelated projects with Samba name on PyPI. This
change in Fedora guidelines cannot affect those. It cannot also affect
actual use of Samba Python bindings. It looks like there is no real use
of PyPI for our use case either, so why the fuss for this particular
package?

I suspect at best we'd submit a request for exception, if pressed.


I fully agree about not installing Samba itself via pip.

(Also, this is one of the cases that might take a decade -- I'm not 
putting pressure on you to implement this, but pointing out a 
direction for the future.)


Frankly, I do not see a real use case for what you might see in other
projects. We had a similar issue with FreeIPA and what we provide on
PyPI is a crippled subset of FreeIPA Python modules that mostly does not
use real FreeIPA features. To date, I am not sure it is really bringing
any benefit to us (upstream).

This does not mean the whole effort is useless, not at all. It means, in
my opinion, that proposed guidelines are failing to address real world
use cases present in Fedora. Invalidating these use cases is as bad as
dropping the guidelines' changes in one go. ;)


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Vitaly Zaitsev via devel


On 14.06.2021 22:33, Dan Čermák wrote:

I would then suggest to change the wording from "Running upstream tests
is mandatory." to "Upstream tests SHOULD be run unless there are
compelling reasons. In that case basic smoke tests MUST be added to
%check".


+1 for this.

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

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Vitaly Zaitsev via devel


On 15.06.2021 10:14, Vít Ondruch wrote:
I think that "use your bests judgement" still applies. So whatever is in 
guidelines should be respected, but sometimes there needs to be exceptions.


The word "MUST" should be replaced by "SHOULD" then.

If upstream tests works fine, I always enable them, but if I need to do 
a lot of work by patching/rewriting them, I would rather skip them 
altogether, because I'm not getting paid for this unnecessary work.


Also, some upstream tests are designed for their own CI only. You will 
need to do a lot of patching to reproduce their build/tests environment.


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

Re: Draft of New Python Packaging Guidelines

On Tue, Jun 15, 2021 at 5:35 AM Miro Hrončok  wrote:
>
> On 14. 06. 21 7:31, Zbigniew Jędrzejewski-Szmek wrote:
> >> BuildRequires: %{py3_dist pytest}
> > Does it make sense to recommend py3_dist here? python3dist(pytest) is
> > not more complex but can be fed to 'dnf install' directly, so in the
> > end it's more flexible. I always find the macro more obfuscation than
> > anything for package names which don't require normalization.
>
> Replaced with python3dist(pytest). The %py3_dist remains documented in the
> guidelines but is not longer used in examples like this (this was the only
> instance).
>

The case where we'd use macros would be if we want to extend for
building for multiple Pythons from one spec file again (which is
something that'd be nice to do in the future)...



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

Re: Please upgrade fortune-mod to v3.6.1

2021-06-15 Thread Shlomi Fish

On Wed, 09 Jun 2021 10:41:59 +0100
Sérgio Basto  wrote:

> Hi,
> 
> In resume you are rindolf and don't have access to fedora anymore ? and
> you want that someone update it for you ? 
> I can happily do that, if you give me permissions in fortune-mod , as
> you know my fas name is sergiomb , can you acess to
> https://src.fedoraproject.org/rpms/fortune-mod via web ?
> 

Hi sergio! I've given you access to
https://src.fedoraproject.org/rpms/fortune-mod now.

> Best regards,
> 
> On Wed, 2021-06-09 at 09:03 +, Shlomi Fish wrote:
> > * finalzone (~Thunderbi@fedora/Finalzone) has joined
> >  hi all! Can someone please update fortune-mod to 3.6.1 in
> > fedora?
> > https://github.com/shlomif/fortune-mod/releases/tag/fortune-mod-3.6.1 
> >  anyone?
> > * finalzone has quit (Read error: Connection reset by peer)
> >  rindolf: the maintainer must do it
> >  take a look here, and see if a bug exists. If not, best to
> > file one so that the maintainers are notified:
> > https://src.fedoraproject.org/rpms/fortune-mod
> > * Hazelesque18 (~Hazelesqu@194.107.231.152) has joined
> > * Hazelesque18 has quit (Remote host closed the connection)
> >  FranciscoD: i am a maintainer - @shlomif
> > * calexil2 (~cale...@node-nr9.pool-182-53.dynamic.totinternet.net) has
> > joined
> > * calexil2 has quit (Remote host closed the connection)
> >  rindolf: then you should be able to update it?
> >  FranciscoD: as evidence:
> > https://www.shlomifish.org/me/rindolf/
> >  rindolf: sure, I'm not questioning that, but I don't
> > understand why you're asking someone else to update the package if you
> > are the maintainer?
> >  :D
> >  rindolf: also, if you weren't aware, we've moved to a
> > different network now (see /topic)
> >  FranciscoD: i no longer have access to a fast enuf fedora sys
> >  rindolf: ah, in that case, it'll be best to e-mail the
> > devel list and ask for co-maintainers who can help?
> >  FranciscoD: ah
> >  FranciscoD: can you do it please? i'm not subscribed and
> > there are anti-spam traps and stuffs. feel free to quote this irc convo
> >  rindolf: I could but it's really best coming from a
> > maintainer. I see `sheltren` is the main admin for the package too---
> > can they not help?
> > * rindolf remembers being subscribed to lkml - gmai
> >  FranciscoD: "perfect is the enemy of good"
> >  rindolf: no, it's more that if some else posts they end up
> > playing middle man between you and the list---which is not efficient
> > ___
> > 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  
> 



-- 

Shlomi Fish   https://www.shlomifish.org/
Let’s talk about restores instead of backups - https://is.gd/WatQqu

Sarah: Ken, would you like some more juice?
Ken: No, Sarah, that's OK, I’m stuffed. Anyway, I think I’ll return to my
dimension of evil now - they will be clueless without me. Thanks for everything.
— https://www.shlomifish.org/humour/Buffy/A-Few-Good-Slayers/

Please reply to list if it's a mailing list post - https://shlom.in/reply .
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

I'll address the larger "mandatory tests" issue later; thanks for all 
your concerns!

This point deserves a reply on its own:

On 14. 06. 21 19:35, Benjamin Beasley wrote:
[...]

It’s also not clear to me why the Python guidelines should be so much stricter 
than the overall Fedora guidelines 
(https://docs.fedoraproject.org/en-US/packaging-guidelines/#_test_suites) in 
this area.


Two reasons:
- Python is a dynamic language; most errors only happen at runtime. In 
C, just compiling and linking might work as a reasonable smoke test.
- I'd like the Python guidelines to be a bit "ahead" of the Fedora-wide 
ones. The proposal contains a few ideas that might be better 
Fedora-wide, but I'd rather introduce and test them in the ecosystem I know.


___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


On 14. 06. 21 20:09, Alexander Bokovoy wrote:

On ma, 14 kesä 2021, Ben Cotton wrote:

[...]

 PyPI Parity 

Machine-readable metadata (''distribution'' names in
dist-info directories on disk and the corresponding
python3.Xdist(foo) RPM provides) will match the Python
Package Index (PyPI).

This solves a ''namespace'' issue. Python packaging tools use a flat 
namespace,

and PyPI is ''the'' place where open-source Python packages are generally
published, so users and tools assume a package called 
requests

is whatever requests means on PyPI.
While this is not ideal (especially for private packages), it makes sense
for Fedora to align with the PyPI namespace.

Note that Fedora package names are not affected – just the Python 
packaging

metadata on disk and virtual RPM Provides generated from it.

The new guidelines cover what to do for packages that cannot be 
registered

on PyPI. The Change owner is prepared to help with PyPI registration.

Note that names found in Fedora but not on PyPI
[https://github.com/pypa/pypi-support/issues/355 have been reserved on 
PyPI]

to avoid being taken by unrelated projects.


samba has extensive Python C bindings but does not use PyPI at all. We
don't want to, we don't need to, it is technically not possible without
building Samba from scratch and it would not make it usable for PIP
install without a stricter coordination of the non-Python dependencies
-- that's what Linux distributions do.

In addition, 'samba' name is taken by an unrelated package on PyPI which
was not updated since 2019. For us this namespacing enforcement would
only be a problem.


Then I'd recommend that the project name in dist-info metadata would be, 
for example "samba-bindings".
This matters in cases like a pip-installable package declaring a 
dependency on Samba bindings: it now can't use `samba` because that 
means something else on PyPI.


I fully agree about not installing Samba itself via pip.

(Also, this is one of the cases that might take a decade -- I'm not 
putting pressure on you to implement this, but pointing out a direction 
for the future.)



=== Burdening packagers ===

[https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/IYBF5GX6HVQYPC5EJ6HVK7GJHAIKHVBK/ 


Neal]
does
“not necessarily disagree that PyPI and Fedora pythonXdist() names
should match, but [he disagrees] on burdening packagers with this.”

However, actually pushing a package to PyPI (and maintaining it there)
is not necessary.
The minimal-effort solution is to ''reserve'' the name on PyPI
so that a conflicting package can not be created there.

The author of this change is willing to do this work for all
Python packages whose upstream is not on PyPI;
packagers need to send a request to the Python SIG list.
If something happens to me, Red Hat's python-maint team is also ready
to do this, and in the event of catastrophic management change,
PyPI maintainers can be e-mailed directly.

This is all described in the new guidelines (see the ''PyPI parity'' 
section).


The new guidelines discourage the minimal-effort solution because it is
suboptimal ''for users'' (and for the wider Python ecosystem).


In case of Samba I would argue that going with anything but
minimal-effort is actually suboptimal to users.


I agree; Samba is a special case.
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


Hi Neal,
We had this conversation in the past (and you can see it in the change). 
I don't think I can convince you, but I'll reiterate since it's new for 
devel@.


Unlike the "mandatory tests" issue elsewhere in this thread, using the 
PyPI namespace is the main point of the change. I can't take it out.



On 15. 06. 21 2:11, Neal Gompa wrote:

On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer  wrote:


On 6/14/21 1:53 PM, Neal Gompa wrote:

This is completely unreasonable. The dist-info/egg-info data of a
Python module is for generating dependencies, not for forcing people
to deal with PyPI.



I don't think we can reasonably separate the two.

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

(I believe this is the "namespace" issue mentioned in the proposed change.)


You can. When it comes to distribution packages, we can maintain
consistency of the package names referenced within the distribution.
The point of this was to be able to use the names Python packages call
themselves for dependencies. PyPI is merely a distribution center for
such things. Fedora is another distribution center for such things.


You can only separate the namespaces if you sacrifice interoberability, 
i.e. allowing pip-installable packages to depend on Fedora packages.
It turns out you can already do that (venv --system-site-packages), and 
users expect that dist-info project names use the PyPI namespace. This 
is a current problem that we need to solve.


There are other (harder) solutions for the issue than reusing the PyPI 
namespace in Fedora, but why should we bother with them? There already 
is an ecosystem-wide namespace; why should we add a Fedora-specific one? 
(Or a Linux-distro-specific one, if we're interested in cross-distro 
collaboration.)


You seem to assume that registering/blocking a name on PyPI is hard.
I say it is not and I am willing to do it for packagers who need it. 
(And to mitigate the bus factor, I'll make it a responsibility of Red 
Hat's python-maint team.)



It's not terribly different from how organizations may have private
Python package indexes that may use whatever names they want for
Python software they build and release.


I agree, in fact, I think Fedora's problems here are a subset of the 
problems the private organizations have: if issues of proprietary corps 
are solved, we can use the solution as well. (However, it'll need more 
work than is necessary for Fedora/FOSS needs, so I don't want to drive 
the effort.)
BUT, if the issues are solved, it'll likely be through namespacing: we'd 
need to prefix our names with `fedora-` or `fedora:`. I still think it 
is better for Fedora to reuse the public PyPI namespace rather than 
start its own.



___
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: F35 Change: Sphinx 4 (Self-Contained Change proposal)


On 02. 06. 21 16:57, Ben Cotton wrote:

* 
[https://copr.fedorainfracloud.org/coprs/ksurma/pygments-2.9.0/package/python-sphinx-click/
python-sphinx-click]


Fixed.


* 
[https://copr.fedorainfracloud.org/coprs/ksurma/pygments-2.9.0/package/python-myst-parser
python-myst-parser]


Fixed.

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

Fedora-Cloud-34-20210615.0 compose check report

No missing expected images.

Failed openQA tests: 8/8 (x86_64)

Old failures (same test failed in Fedora-Cloud-34-20210614.0):

ID: 908223  Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/908223
ID: 908224  Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/908224
ID: 908225  Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/908225
ID: 908226  Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start
URL: https://openqa.fedoraproject.org/tests/908226
ID: 908227  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux
URL: https://openqa.fedoraproject.org/tests/908227
ID: 908228  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/908228
ID: 908229  Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging
URL: https://openqa.fedoraproject.org/tests/908229
ID: 908230  Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli
URL: https://openqa.fedoraproject.org/tests/908230

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

Old soft failures (same test soft failed in Fedora-Cloud-34-20210614.0):

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

Passed openQA tests: 7/8 (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

Re: Draft of New Python Packaging Guidelines


On 14. 06. 21 7:31, Zbigniew Jędrzejewski-Szmek wrote:

BuildRequires: %{py3_dist pytest}

Does it make sense to recommend py3_dist here? python3dist(pytest) is
not more complex but can be fed to 'dnf install' directly, so in the
end it's more flexible. I always find the macro more obfuscation than
anything for package names which don't require normalization.


Replaced with python3dist(pytest). The %py3_dist remains documented in the 
guidelines but is not longer used in examples like this (this was the only 
instance).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Draft of New Python Packaging Guidelines


On 14. 06. 21 7:31, Zbigniew Jędrzejewski-Szmek wrote:

  For example, if a user runs pip install requests[security]

Please quote 'requests[security]' in the command. [] are special to the shell.


Done.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)


On 14. 06. 21 17:39, Richard W.M. Jones wrote:

Questions, questions ...

These new guidelines seem to be fine for pure Python packages, but I'm
maintaining a couple of packages where Python bindings are built as
subpackages of existing C libraries:

https://src.fedoraproject.org/rpms/libnbd
https://src.fedoraproject.org/rpms/libguestfs

[Yes there are good reasons for this.  No we are not going to decouple
them and package the Python stuff separately.]

Running %pyproject_install etc is not really an option for us.
However I guess some of these macros could make sense
(%pyproject_save_files?  %pyproject_files?).  Also I don't think these
projects generate the extra *.egg-info files or how to create them.


Note that the macros are helpers/implementation details. They're not 
necessary; you can use other tools to be compatible with the guidelines.

Some of those tools are still to be written.
That's the main reason why adopting the guidelines might take a decade. 
We do intend to add helpers for more use cases, but it's not a priority 
right now.


Like the change says, there's no rush; the old guidelines will be 
retired "some time after the vast majority of Python packages follow the 
new guidelines and there are no known blockers for the remaining ones".
I hope it's clear that I do not expect individual packagers to solve 
this problem. (Though if y'all want to help, I won't object.)



=== Not removing older guidelines ===
There's no rush; it might well take a decade.


I guess we've got a while ...

While I've got your attention, one other package is interesting:

https://src.fedoraproject.org/rpms/nbdkit

This has Python 3 bindings but they work in completely the opposite
way to normal bindings, namely a Python interpreter is embedded in a
C program.  As far as I know none of the Python guidelines in Fedora
address this scenario directly, and indeed we don't currently use any
of the special %python* macros.


Thanks for the examples!
___
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 1972092] New: perl-WebService-Dropbox-2.08b is available

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

Bug ID: 1972092
   Summary: perl-WebService-Dropbox-2.08b is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-WebService-Dropbox
  Keywords: FutureFeature, Triaged
  Assignee: robinlee.s...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: fed...@me.benboeckel.net,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.08b
Current version/release in rawhide: 2.07-13.fc35
URL: http://search.cpan.org/dist/WebService-Dropbox/

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


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

Schedule for Tuesdays's FESCo Meeting (2021-06-15)

2021-06-15 Thread Zbigniew Jędrzejewski-Szmek


Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.

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

or run:
  date -d '2021-06-15 17: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 =

#2621 F35 Change: Build Fedora Cloud Images with Hybrid BIOS+UEFI Boot Support
https://pagure.io/fesco/2621
APPROVED fast-track (+7, 0, 0)

= Followups =

New meeting time
(We held a poll, but exactly 0 times are fine for everyone, so we'll
need to discuss this. I assume that today's meeting will be the last
in this time slot.)

#2617 F35 Change: Make btrfs the default file system for Fedora Cloud
https://pagure.io/fesco/issue/2617


= New business =


= Open Floor = 

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Draft of New Python Packaging Guidelines


On 14. 06. 21 7:57, Zbigniew Jędrzejewski-Szmek wrote:

What about making this conditional:

   Requires: (pyproject-rpm-macros if rpm-build)

You can't really*use*  the macros without rpmbuild, and one less
hard dependency is always good. With the conditional dep, pretty
much any real system will get the dep, but it's easier to build a
leaner custom containers and such.


That is the plan. Currently python3-devel already has:

Requires: (python-rpm-macros if rpm-build)
Requires: (python3-rpm-macros if rpm-build)
Requires: (python3-rpm-generators if rpm-build)

We would just add another one like that.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ways to contact wakko666 / Brett Lentz


On 15. 06. 21 3:06, Miro Hrončok wrote:

Hello Fedorans.

I wanted to NEEDINFO Brett, but Bugzilla says:

You can't ask Brett Lentz  because that account is disabled.

Do you know any alternate ways to contact them?


Hey Brett.

Are you still interested in maintaining your Fedora packages? It seems that 
your @redhat.com email address associated to your packager account wakko666 no 
longer works in bugzilla. Could you change it to your personal one please?


--
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

2021-06-15 Thread Vít Ondruch



Dne 14. 06. 21 v 19:30 Vitaly Zaitsev via devel napsal(a):

On 14.06.2021 19:16, Miro Hrončok wrote:
That is exactly the thing we need to avoid. Python packages without 
tests always cause trouble when we measure impact of our changes. 
E.g. when we continuously rebuild packages with the next Python 
release, pure Python packages with incompatibilities but without 
%check always succeed the build, but they break other packages.


OK, I will orphan all my Python packages than. I don't want to deal 
with tests at all.




I think that "use your bests judgement" still applies. So whatever is in 
guidelines should be respected, but sometimes there needs to be exceptions.


Nevertheless, I definitely support Python team in making %check section 
mandatory and should if disabled, it should be well reasoned. This is 
what Ruby guidelines says on this topic:



~~~

If there is test suite available for the package (even separately, for 
example not included in the gem but available in the upstream 
repository), it SHOULD be run in |%check|. The test suite is the only 
automated tool which can assure basic functionality of the package. 
Running it is especially helpful when mass rebuilds are required. You 
MAY skip test suite execution when not all build dependencies are met 
but this MUST be documented in the specfile. The missing build 
dependencies to enable the test suite SHOULD be packaged for Fedora as 
soon as possible and the test suite re-enabled.


~~~


Vít

___
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-33-20210615.0 compose check report

No missing expected images.

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

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

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

Passed openQA tests: 7/8 (x86_64), 7/8 (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

Re: Ways to contact wakko666 / Brett Lentz

2021-06-15 Thread Paweł Marciniak

Try https://twitter.com/brett_lentz or https://github.com/blentz
___
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: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

2021-06-15 Thread Alexander Bokovoy

On ma, 14 kesä 2021, Adam Williamson wrote:

On Mon, 2021-06-14 at 15:40 +0300, Alexander Bokovoy wrote:

>
> The fact that this blocks FreeIPA was indeed only discovered by chance
> while the side tag rebuild was already in progress (and about to be
> merged). I wonder haw can we improve the process to ensure problems
> like this are known to FreeIPA maintainers since the beginning and
> prioritized accordingly. (Ideally, the process would not only be
> improved for FreeIPA but the entire distro.)

Well, this is a dependency problem in the first place. When an ABI
change happens, like a Python ABI change with 3.10 mass-rebuild, it
should be assumed and expected that until all previously successfully
built packages were to be rebuilt, there will be broken dependencies.
Perhaps, we could extend our existing checks for a broken compose to be
done on a side-tag on demand? This way mass-rebuilders could ask for
such a run one they consider to be ready to merge and see how that
side-tag merge would affect the distribution. I don't think we have a
better way to detect it before the merge.

Note, we did do a limited version of this; I built a Rawhide installer
image with Python 3.10 and ran a subset of openQA tests on it. We did
not include the FreeIPA tests in that, which was a bit of an oversight;
however, FreeIPA tests failed for an unrelated reason in the compose
before the merge, so it wouldn't necessarily have turned up the issue
anyway.

I think in this particular case even getting a compose closure would
have been enough to get us on track to mod_wsgi problem.

We do have the ODCS - https://pagure.io/odcs ,
https://odcs.fedoraproject.org/composes/ - which we might be able to
use to do this in a more comprehensive and organized way, but I haven't
checked in on exactly what its capabilities are lately. I don't know if
it's possible to request a compose "like Rawhide, but with this side
tag" from it. We might also be able to get releng to hand-roll one, I
guess.

Thanks, this would be a great contribution to side-tag rebuilds.
We are using a similar tooling in RHEL *a lot* (in fact, for IDM CI
testing we do it with every package update).

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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 1964657] F35FailsToInstall: perl-XML-Atom-SimpleFeed

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 CC||jples...@redhat.com
 Resolution|--- |RAWHIDE
Last Closed||2021-06-15 06:39:56



--- Comment #2 from Jitka Plesnikova  ---
perl-XML-Atom-SimpleFeed-0.904-5.fc35 was build against Perl 5.34.


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

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

2021-06-15 Thread Adam Williamson

On Mon, 2021-06-14 at 15:40 +0300, Alexander Bokovoy wrote:
> > 
> > The fact that this blocks FreeIPA was indeed only discovered by chance 
> > while the side tag rebuild was already in progress (and about to be 
> > merged). I wonder haw can we improve the process to ensure problems 
> > like this are known to FreeIPA maintainers since the beginning and 
> > prioritized accordingly. (Ideally, the process would not only be 
> > improved for FreeIPA but the entire distro.)
> 
> Well, this is a dependency problem in the first place. When an ABI
> change happens, like a Python ABI change with 3.10 mass-rebuild, it
> should be assumed and expected that until all previously successfully
> built packages were to be rebuilt, there will be broken dependencies.
> Perhaps, we could extend our existing checks for a broken compose to be
> done on a side-tag on demand? This way mass-rebuilders could ask for
> such a run one they consider to be ready to merge and see how that
> side-tag merge would affect the distribution. I don't think we have a
> better way to detect it before the merge.

Note, we did do a limited version of this; I built a Rawhide installer
image with Python 3.10 and ran a subset of openQA tests on it. We did
not include the FreeIPA tests in that, which was a bit of an oversight;
however, FreeIPA tests failed for an unrelated reason in the compose
before the merge, so it wouldn't necessarily have turned up the issue
anyway.

We do have the ODCS - https://pagure.io/odcs , 
https://odcs.fedoraproject.org/composes/ - which we might be able to
use to do this in a more comprehensive and organized way, but I haven't
checked in on exactly what its capabilities are lately. I don't know if
it's possible to request a compose "like Rawhide, but with this side
tag" from it. We might also be able to get releng to hand-roll one, I
guess.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

[Bug 1964653] F35FailsToInstall: perl-WWW-OrangeHRM-Client

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-WWW-OrangeHRM-Client-0
   ||.12.0-6.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-06-15 06:22:05



--- Comment #1 from Jitka Plesnikova  ---
perl-WWW-OrangeHRM-Client-0.12.0-6.fc35 was build against Perl 5.34.


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

[Bug 1932203] perl-Crypt-GPG-1.64-20.fc35 FTBFS: Use of uninitialized value in string eq at t/02-import.t line 40.

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



--- Comment #2 from Petr Pisar  ---
This issues still exists . I
guess it's a non-determinist issues which clutters CI.


-- 
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 1964655] F35FailsToInstall: perl-Web-Scraper