[Test-Announce] 2022-02-21 @ 17:00 UTC - Fedora 36 Blocker Review Meeting

[Adam Williamson]

# F36 Blocker Review meeting
# Date: 2022-02-21
# Time: 17:00 UTC
# Location: #fedora-blocker-review on irc.libera.chat

Hi folks! We have 4 proposed Beta blockers and 8 proposed Final blockers
to review, so let's have a review meeting on Monday. Note I will not be
around to lead it, Frantisek Zatloukal will be taking charge - thanks!

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F36 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and Frantisek will see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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

Self Introduction: Yunmei Li

[Yunmei LI]

Hi All: I am Yunmei Li and I am working at Zilliz as a DevOps engineer. I am an 
active contributor to the Milvus Vector Database project. Zilliz is an 
open-source software company dedicated to unstruc___
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 2055982] New: perl-Sereal-Encoder-4.021 is available

[bugzilla]

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

Bug ID: 2055982
   Summary: perl-Sereal-Encoder-4.021 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Encoder
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.021
Current version/release in rawhide: 4.020-1.fc37
URL: http://search.cpan.org/dist/Sereal-Encoder/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055982
___
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-20220217.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 97/231 (x86_64), 57/161 (aarch64)

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

ID: 1134484 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/1134484
ID: 1134728 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1134728

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

ID: 1134358 Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1134358
ID: 1134378 Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/1134378
ID: 1134392 Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/1134392
ID: 1134393 Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/1134393
ID: 1134401 Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/1134401
ID: 1134408 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/1134408
ID: 1134411 Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/1134411
ID: 1134412 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1134412
ID: 1134414 Test: x86_64 Workstation-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1134414
ID: 1134415 Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1134415
ID: 1134440 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1134440
ID: 1134462 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1134462
ID: 1134497 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1134497
ID: 1134502 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1134502
ID: 1134509 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1134509
ID: 1134510 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1134510
ID: 1134538 Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/1134538
ID: 1134580 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1134580
ID: 1134602 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1134602
ID: 1134625 Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1134625
ID: 1134626 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1134626
ID: 1134635 Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1134635
ID: 1134701 Test: aarch64 universal upgrade_2_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1134701
ID: 1134702 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1134702
ID: 1134715 Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1134715
ID: 1134734 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1134734
ID: 1134746 Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1134746
ID: 1134769 Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1134769
ID: 1134770 Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1134770
ID: 1134771 Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1134771
ID: 1134772 Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1134772
ID: 1134773 Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1134773
ID: 1134774 Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/1134774
ID: 1134775 Test: x86_64 Server-dvd-iso install_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/1134775
ID: 1134778 Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/1134778
ID: 1134779 Test

[Bug 2055977] New: perl-Sereal-4.021 is available

[bugzilla]

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

Bug ID: 2055977
   Summary: perl-Sereal-4.021 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.021
Current version/release in rawhide: 4.020-1.fc37
URL: http://search.cpan.org/dist/Sereal/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055977
___
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-36-20220217.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 14/229 (x86_64), 17/161 (aarch64)

New failures (same test not failed in Fedora-36-20220216.n.0):

ID: 1133953 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/1133953
ID: 1133974 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/1133974
ID: 1134099 Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1134099
ID: 1134126 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1134126
ID: 1134157 Test: x86_64 Workstation-upgrade desktop_terminal
URL: https://openqa.fedoraproject.org/tests/1134157
ID: 1134177 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1134177
ID: 1134248 Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/1134248
ID: 1134273 Test: aarch64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/1134273
ID: 1134315 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1134315
ID: 1134324 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1134324

Old failures (same test failed in Fedora-36-20220216.n.0):

ID: 1134005 Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1134005
ID: 1134010 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1134010
ID: 1134043 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1134043
ID: 1134044 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1134044
ID: 1134073 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1134073
ID: 1134127 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1134127
ID: 1134131 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1134131
ID: 1134133 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/1134133
ID: 1134134 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1134134
ID: 1134161 Test: x86_64 Workstation-upgrade desktop_background
URL: https://openqa.fedoraproject.org/tests/1134161
ID: 1134174 Test: aarch64 Workstation-upgrade desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/1134174
ID: 1134178 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1134178
ID: 1134185 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1134185
ID: 1134186 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1134186
ID: 1134218 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1134218
ID: 1134286 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1134286
ID: 1134314 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1134314
ID: 1134333 Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/1134333
ID: 1134334 Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1134334
ID: 1134352 Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1134352
ID: 1134353 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1134353

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

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

ID: 1134107 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1134107

Old soft failures (same test soft failed in Fedora-36-20220216.n.0):

ID: 1134004 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1134004
ID: 1134041 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1134041
ID: 1134049 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1134049
ID: 1134136 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1134136
ID: 1134147 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: 

[Bug 2055954] perl-Business-ISSN-1.005 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Scratch build failed. Details bellow:

GenericError: File upload failed:
cli-build/1645152516.071939.oDBfJsdM/perl-Business-ISSN-1.005-1.fc34.src.rpm
Traceback:
  File
"/usr/local/lib/python3.9/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line
198, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line
451, in _scratch_build
session.uploadWrapper(source, serverdir)
  File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 3027, in
uploadWrapper
self.fastUpload(localfile, path, name, callback, blocksize, overwrite,
volume=volume)
  File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 2962, in
fastUpload
raise GenericError("File upload failed: %s/%s" % (path, name))

If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055954
___
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 2055954] New: perl-Business-ISSN-1.005 is available

[bugzilla]

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

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



Latest upstream release: 1.005
Current version/release in rawhide: 1.004-7.fc36
URL: http://search.cpan.org/dist/Business-ISSN

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055954
___
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 2055412] perl-File-Find-utf8-0.014 is available

[bugzilla]

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



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

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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ba28d36d05   
radare2-5.6.0-1.el8
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f2ae791306   
xpra-4.3.2-1.el8


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

packit-0.46.0-1.el8
python-ogr-0.35.0-1.el8
snapd-2.54.3-1.el8
spamassassin-dqs-1.2.1-1.el8
tayga-0.9.2-17.el8

Details about builds:



 packit-0.46.0-1.el8 (FEDORA-EPEL-2022-fa9360580f)
 A tool for integrating upstream projects with Fedora operating system

Update Information:

new upstream release 0.46.0

ChangeLog:

* Wed Feb 16 2022 Packit Service  - 
0.46.0-1
- Synchronization of default files can now be disabled using a new config
  `files_to_sync`. Key `sync_files` is now deprecated. (#1483)
- Packit now correctly handles colons in git trailer values in source-git 
commits. (#1478)
- Fedora 36 was added to the static list of `fedora-` aliases. (#1480)




 python-ogr-0.35.0-1.el8 (FEDORA-EPEL-2022-fca773d58c)
 One API for multiple git forges

Update Information:

New upstream release 0.35.0

ChangeLog:

* Wed Feb 16 2022 Packit Service  - 
0.35.0-1
- We have added `target_branch_head_commit` property to the `PullRequest`
  class in `ogr` that allows you to get commit hash of the HEAD of the
  target branch (i.e. base, where the changes are merged to).




 snapd-2.54.3-1.el8 (FEDORA-EPEL-2022-2a06cd58d0)
 A transactional software package manager

Update Information:

Update to 2.54.3. Cherry pick misc SELinux policy fixes.

ChangeLog:

* Thu Feb 17 2022 Maciek Borzecki  - 2.54.3-1
- Release 2.54.3 to Fedora
- Cherry pick SELinux policy fixes for RHBZ#1944390, RHBZ#2043160, RHBZ#2043161,
  RHBZ#2046358, RHBZ#2046363, RHBZ#2046361, RHBZ#2046364, RHBZ#2046365,
  RHBZ#2051594, RHBZ#2043902, RHBZ#1944390
* Tue Feb 15 2022 Michael Vogt 
- New upstream release 2.54.3
 - bugfixes




 spamassassin-dqs-1.2.1-1.el8 (FEDORA-EPEL-2022-57af8bb5bc)
 SpamAssassin plugin for Spamhaus Data Query Service (DQS)

Update Information:

The Spamhaus Data Query Service (DQS) plugin for SpamAssassin enhances existing
functions by checking HELO/EHLO, From, Reply-To, Envelope-From and Return-Path
against Spamhaus DBL/ZRD blacklists. It also scans the e-mail body for e-mail
addresses and performs blacklist lookups against the domains or its
authoritative nameservers. Further checks cover the reverse DNS matches in
DBL/ZRD blacklists or the SBL/CSS lookups for IP addresses or IP addresses of
authoritative nameservers of domains being part of the e-mail body.  While the
DQS usage is free under the same terms like when using public mirrors (which are
shipped in SpamAssassin as default configuration), a registration procedure for
a free DQS key is mandatory nevertheless.

ChangeLog:

* Thu Feb 17 2022 Robert Scheck  1.2.1-1
- Upgrade to 1.2.1 (#2048938)
* Mon Feb 14 2022 Robert Scheck  1.2.0-1
- Upgrade to 1.2.0 (#2048938)
* Sat Jan 22 2022 Fedora Release Engineering  - 
1.1.3-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Fri Jul 23 2021 Fedora Release Engineering  - 
1.1.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Sat Jul 17 2021 Robert Scheck  1.1.3-1
- Upgrade to 1.1.3 (#1982505)
* Mon Jul  5 2021 Robert Scheck  1.1.2-1
- Upgrade to 1.1.2
* Wed Jul 10 2019 Robert Scheck  1.0.3-1
- Upgrade to 1.0.3 (#1729302)
- Initial spec file for Fedora and Red Hat Enterprise Linux




 tayga-0.9.2-17.el8 (FEDORA-EPEL-2022-71a1b9ae76)
 Simple, no-fuss NAT64

Fedora rawhide compose report: 20220217.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220217.n.0
NEW: Fedora-Rawhide-20220217.n.1

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

Size of added packages:  10.59 MiB
Size of dropped packages:0 B
Size of upgraded packages:   5.24 GiB
Size of downgraded packages: 2.07 MiB

Size change of upgraded packages:   2.39 MiB
Size change of downgraded packages: 1.32 KiB

= ADDED IMAGES =
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220217.n.1.s390x.raw.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20220217.n.1.s390x.tar.xz
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20220217.n.1.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220217.n.1.s390x.qcow2
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20220217.n.1.iso
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20220217.n.1.s390x.tar.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20220217.n.1.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: gnome-console-42~beta-1.fc37
Summary: Simple user-friendly terminal emulator for the GNOME desktop
RPMs:gnome-console gnome-console-nautilus
Size:570.91 KiB

Package: golang-github-ipfs-detect-race-0.0.1-1.fc37
Summary: Detect if compiled with race
RPMs:golang-github-ipfs-detect-race-devel
Size:10.43 KiB

Package: golang-github-jbenet-cienv-0.1.0-1.fc37
Summary: None
RPMs:golang-github-jbenet-cienv-devel
Size:11.65 KiB

Package: python-editables-0.2.0-1.20220217git5112e1b.fc37
Summary: Editable installations
RPMs:python3-editables
Size:14.37 KiB

Package: swig-4.0.2-13.module_f37+13824+b9f0f79f
Summary: Connects C/C++/Objective C to some high-level programming languages
RPMs:ccache-swig swig swig-doc swig-gdb
Size:9.97 MiB

Package: uniol-fonts-1.0.1-6.fc37
Summary: Unicode compliant Open source Ol Chiki font
RPMs:uniol-fonts
Size:21.23 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  PackageKit-1.2.5-1.fc37
Old package:  PackageKit-1.2.4-4.fc36
Summary:  Package management service
RPMs: PackageKit PackageKit-command-not-found PackageKit-cron 
PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin 
PackageKit-gtk3-module
Size: 5.58 MiB
Size change:  14.13 KiB
Changelog:
  * Thu Feb 17 2022 Richard Hughes  - 1.2.5-1
  - New upstream release
  - Properly handle allow-reinstall flag for installations
  - Provide better error message if trying to install an installed package
  - Searches by name and package details should be case insensitive
  - Update appstream xml files if dnf_sack_add_repos() does the download
  - Wait until online to activate systemd service


Package:  ProDy-2.0.2-1.fc37
Old package:  ProDy-2.0.1-2.fc36
Summary:  Application for protein structure, dynamics and sequence analysis
RPMs: python3-ProDy
Size: 18.69 MiB
Size change:  -26.48 KiB
Changelog:
  * Thu Feb 17 2022 Antonio Trande  - 2.0.2-1
  - Release 2.0.2


Package:  RdRand-2.1.4-1.fc37
Old package:  RdRand-2.1.2-7.fc36
Summary:  Library for generating random numbers using the RdRand 
instruction on Intel CPUs
RPMs: RdRand RdRand-devel
Size: 107.66 KiB
Size change:  -91 B
Changelog:
  * Thu Feb 17 2022 Jirka Hladky  - 2.1.4-1
  - Updated to v2.1.4


Package:  blivet-gui-2.3.0-5.fc37
Old package:  blivet-gui-2.3.0-4.fc36
Summary:  Tool for data storage configuration
RPMs: blivet-gui blivet-gui-runtime
Size: 336.42 KiB
Size change:  -2.68 KiB
Changelog:
  * Thu Feb 17 2022 Adam Williamson  - 2.3.0-5
  - Backport PR #331 to fix with adwaita-icon-theme 42+


Package:  bluedevil-5.24.1-1.fc37
Old package:  bluedevil-5.24.0-2.fc36
Summary:  Bluetooth stack for KDE
RPMs: bluedevil
Size: 1.75 MiB
Size change:  427 B
Changelog:
  * Tue Feb 15 2022 Marc Deop  - 5.24.1-1
  - 5.24.1


Package:  bodhi-5.7.4-2.fc37
Old package:  bodhi-5.7.0-2.fc35
Summary:  A modular framework that facilitates publishing software updates
RPMs: bodhi-client bodhi-composer bodhi-docs bodhi-server python3-bodhi 
python3-bodhi-client python3-bodhi-messages
Size: 4.96 MiB
Size change:  -12.70 KiB
Changelog:
  * Wed Feb 16 2022 Nils Philippsen  - 5.7.4-1
  - Update to 5.7.4

  * Thu Feb 17 2022 Nils Philippsen  - 5.7.4-2
  - Fix building with newer Sphinx versions


Package:  breeze-gtk-5.24.1-1.fc37
Old package:  breeze-gtk-5.24.0-1.fc36
Summary:  Breeze widget theme for GTK
RPMs: breeze-gtk breeze-gtk-common breeze-gtk-gtk2 breeze-gtk-gtk3 
breeze-gtk-gtk4
Size: 318.97 KiB
Size change:  222 B
Changelog

[Bug 2052036] perl-experimental-0.027 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-experimental-0.027-1.f |perl-experimental-0.027-1.f
   |c36 |c36
   |perl-experimental-0.027-1.f |perl-experimental-0.027-1.f
   |c37 |c37
   |perl-experimental-0.027-1.f |perl-experimental-0.027-1.f
   |c34 |c34
   ||perl-experimental-0.027-1.f
   ||c35



--- Comment #11 from Fedora Update System  ---
FEDORA-2022-e49fcf1463 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2052036
___
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 2055942] New: perl-Test-PostgreSQL-1.29 is available

[bugzilla]

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

Bug ID: 2055942
   Summary: perl-Test-PostgreSQL-1.29 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-PostgreSQL
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.29
Current version/release in rawhide: 1.28-4.fc36
URL: http://search.cpan.org/dist/Test-PostgreSQL/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055942
___
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 2055412] perl-File-Find-utf8-0.014 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2022-1268123a5b 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-2022-1268123a5b`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-1268123a5b

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.
https://bugzilla.redhat.com/show_bug.cgi?id=2055412
___
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 2052036] perl-experimental-0.027 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-experimental-0.027-1.f |perl-experimental-0.027-1.f
   |c36 |c36
   |perl-experimental-0.027-1.f |perl-experimental-0.027-1.f
   |c37 |c37
   ||perl-experimental-0.027-1.f
   ||c34
 Resolution|--- |ERRATA
Last Closed|2022-02-09 15:36:25 |2022-02-18 01:13:15



--- Comment #10 from Fedora Update System  ---
FEDORA-2022-6550504440 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2052036
___
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] Proposal to CANCEL: 2022-02-21 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday. It's a
public holiday where I live, so I won't be around to run the meeting.
I'll plan for one the following week.

If you think there is something important to discuss this week, you
can volunteer to run the meeting by sending out an announcement with an
agenda like I usually would, and follow
https://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process to run the
meeting.

Thanks folks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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

[Bug 2055936] New: perl-XML-Generator-1.08 is available

[bugzilla]

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

Bug ID: 2055936
   Summary: perl-XML-Generator-1.08 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-XML-Generator
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.08
Current version/release in rawhide: 1.04-31.fc36
URL: http://search.cpan.org/dist/XML-Generator/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055936
___
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

why opencv Python package doesn't provide python3dist(opencv-python) ?

[Sérgio Basto]

Hi,
Can someone help me ? 
https://src.fedoraproject.org/rpms/opencv/blob/rawhide/f/opencv.spec
have py_provides but 
https://bugzilla.redhat.com/show_bug.cgi?id=2054951

Thank you . 
-- 
Sérgio M. B.
___
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

Fedora 36 compose report: 20220217.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220216.n.0
NEW: Fedora-36-20220217.n.1

= SUMMARY =
Added images:16
Dropped images:  0
Added packages:  13
Dropped packages:0
Upgraded packages:   187
Downgraded packages: 0

Size of added packages:  32.21 MiB
Size of dropped packages:0 B
Size of upgraded packages:   7.46 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-36-20220217.n.1.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-36-20220217.n.1.iso
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-36-20220217.n.1.s390x.tar.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-36-20220217.n.1.ppc64le.tar.xz
Image: Server boot ppc64le
Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-36-20220217.n.1.iso
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-36-20220217.n.1.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-36-20220217.n.1.iso
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-36-20220217.n.1.iso
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-36-20220217.n.1.ppc64le.tar.xz
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-36-20220217.n.1.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-36-20220217.n.1.s390x.qcow2
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-36-20220217.n.1.ppc64le.raw.xz
Image: Everything boot ppc64le
Path: 
Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-36-20220217.n.1.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-36-20220217.n.1.iso
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-36-20220217.n.1.s390x.tar.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-36-20220217.n.1.ppc64le.qcow2

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: f36-backgrounds-36.0.0-1.fc36
Summary: Fedora 36 default desktop background
RPMs:f36-backgrounds f36-backgrounds-base f36-backgrounds-extras-base 
f36-backgrounds-extras-gnome f36-backgrounds-extras-kde 
f36-backgrounds-extras-mate f36-backgrounds-extras-xfce f36-backgrounds-gnome 
f36-backgrounds-kde f36-backgrounds-mate f36-backgrounds-xfce
Size:21.93 MiB

Package: fbf-mukti-fonts-3.0.2-4.fc36
Summary: Bangla open source Opentype font
RPMs:fbf-mukti-fonts
Size:210.35 KiB

Package: gnome-bluetooth3.34-3.34.5-1.fc36
Summary: Bluetooth graphical utilities
RPMs:gnome-bluetooth3.34 gnome-bluetooth3.34-libs 
gnome-bluetooth3.34-libs-devel
Size:2.15 MiB

Package: golang-github-cskr-pubsub-1.0.2-1.fc36
Summary: A simple pubsub package for go
RPMs:golang-github-cskr-pubsub-devel
Size:12.41 KiB

Package: golang-github-ipfs-cid-0.1.0-1.fc36
Summary: Content ID v1 implemented in go
RPMs:golang-github-ipfs-cid-devel
Size:26.72 KiB

Package: golang-github-ipfs-detect-race-0.0.1-1.fc36
Summary: Detect if compiled with race
RPMs:golang-github-ipfs-detect-race-devel
Size:10.35 KiB

Package: golang-github-ipfs-log-2.5.0-1.fc36
Summary: A logging library used by go-ipfs
RPMs:golang-github-ipfs-log-devel
Size:20.37 KiB

Package: golang-github-jbenet-cienv-0.1.0-1.fc36
Summary: None
RPMs:golang-github-jbenet-cienv-devel
Size:11.56 KiB

Package: golang-github-kubuxu-os-helper-0.0.1-1.fc36
Summary: Returns OS type
RPMs:golang-github-kubuxu-os-helper-devel
Size:9.00 KiB

Package: golang-github-texttheater-levenshtein-1.0.1-1.fc36
Summary: An implementation of the Levenshtein algorithm in Go.
RPMs:golang-github-texttheater-levenshtein-devel
Size:13.27 KiB

Package: python-editables-0.2.0-1.20220217git5112e1b.fc36
Summary: Editable installations
RPMs:python3-editables
Size:14.42 KiB

Package: rocm-compilersupport-5.0.0-1.fc36
Summary: Various AMD ROCm LLVM related services
RPMs:rocm-comgr rocm-comgr-devel
Size:6.65 MiB

Package: rocm-device-libs-5.0.0-1.fc36
Summary: AMD ROCm LLVM bit code libraries
RPMs:rocm-device-libs
Size:1.15 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  APLpy-2.0.3-15.fc36
Old package:  APLpy-2.0.3-13.fc35
Summary:  The Astronomical Plotting Library in Python
RPMs: python3-APLpy
Size: 131.93 KiB
Size change:  -234 B
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
2.0.3-14
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Thu Feb 17 2022 Sergio Pascual  - 2.0.3-15
  - Fix astropy 5 function incompatibility


Package:  PackageKit-1.2.5-1.fc36
Old

[Bug 2055608] Perl 5.32.1 Incorrectly Processes Hash Key Existence in Two-Dimensional Hashes

[bugzilla]

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



--- Comment #3 from BZ  ---
Thanks for that. Even though semantically it seems like it SHOULD be a bug, for
better or worse at least it's not something unexpected. I just didn't find any
reference to that behavior in the documents I checked. Thanks!


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608
___
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: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Adam Williamson]

On Thu, 2022-02-17 at 15:29 -0500, Owen Taylor wrote:
> 
> I just tried this, actually, for giggles. Two reasons it's a non-
> > starter: it prompts for the root password, not for my user password (my
> > user is an 'admin' so far as sudo etc. are concerned, but apparently
> > not an 'admin' so far as interactive pkexec is concerned). I do not
> > know the root password, it is intentionally a 24-character random
> > string I would have to look up. And it prompts with one of those
> > goddamn 'secure' GNOME popovers which prevents you accessing your
> > password manager, so every time you hit one, you have to cancel it, go
> > to your password manager, copy the password it wants, then trigger it
> > again.
> > 
> 
> I think you misinterpreted the prompt. Assuming your user is in the wheel
> group:
> 
>  "Authentication is needed to run '' as the superuser'
> 
> Isn't asking for the root password, but rather your password to do
> something as root.

Nope. The name shown was "Administrator" (which means it wants the root
password), and entering my user password does not work. Entering the
root password does.

This may not be the case for everyone, but hey, I just did a quick test
on my desktop, and that's what I found.
-- 
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

Re: Review requests

[Sandro Mani]

On 17.02.22 18:36, Mattia Verga via devel wrote:

Il 15/02/22 11:15, Sandro Mani ha scritto:


Hi

I've submitted the two packages which are missing dependencies for 
review, which I'd appreciate if someone could review, as 
mingw-python-requests and mingw-python-OWSLib are currently 
FailsToInstall:


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2053753 - 
mingw-python-charset-normalizer - needed for mingw-python-requests
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2053761 - 
mingw-pyproj - needed for mingw-python-OWSLib


Both are straight forward mingw-python packages. Happy to review in 
exchange.


Thanks
Sandro


Both taken. If you have some time I have these two waiting in the queue:

https://bugzilla.redhat.com/show_bug.cgi?id=2051107 - python-pymediawiki
https://bugzilla.redhat.com/show_bug.cgi?id=2053682 - stellarsolver

The first one should be quite simple, while stellarsolver is a bit 
more complex... feel free to choose one (if you can).



Thanks! I took both your reviews.

Sandro
___
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-20220217.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 106/231 (x86_64), 64/161 (aarch64)

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

ID: 1132640 Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/1132640
ID: 1132641 Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/1132641
ID: 1132649 Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/1132649
ID: 1132656 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/1132656
ID: 1132660 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1132660
ID: 1132710 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1132710
ID: 1132750 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1132750
ID: 1132756 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1132756
ID: 1132757 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1132757
ID: 1132758 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1132758
ID: 1132786 Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/1132786
ID: 1132893 Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/1132893
ID: 1132964 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1132964
ID: 1133242 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/1133242
ID: 1133243 Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/1133243
ID: 1133244 Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/1133244
ID: 1133245 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/1133245
ID: 1133246 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/1133246
ID: 1133283 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1133283
ID: 1133285 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1133285
ID: 1133294 Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/1133294
ID: 1133296 Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1133296
ID: 1133297 Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/1133297
ID: 1133299 Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1133299
ID: 1133300 Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/1133300
ID: 1133301 Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/1133301
ID: 1133302 Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/1133302
ID: 1133303 Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/1133303
ID: 1133304 Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/1133304
ID: 1133305 Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/1133305
ID: 1133306 Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/1133306
ID: 1133307 Test: x86_64 universal install_delete_pata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1133307
ID: 1133309 Test: x86_64 universal install_sata **GATING**
URL: https://openqa.fedoraproject.org/tests/1133309
ID: 1133311 Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/1133311
ID: 1133313 Test: x86_64 universal install_multi **GATING**
URL: https://openqa.fedoraproject.org/tests/1133313
ID: 1133324 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1133324
ID: 1133325 Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1133325
ID: 1133326 Test: aarch64 Server-dvd-iso 
install_repository_nfs_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1133326
ID: 1133327 Test: aarch64 Server-dvd-iso 

Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[James Szinger]

On Wed, 16 Feb 2022 09:17:41 -0800
Adam Williamson  wrote:

> On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec
> > 
> > == Summary ==
> > Split `pkexec` from the polkit package and make it a recommended
> > only sub-package. Similarly, make the polkit-pkla-compat package a
> > recommended package too. This will enable users and desktop no
> > longer relying on those features to avoid installing them.  
> 
> Splitting them off but making them Recommended seems odd to me. At
> that point we've got all the work of splitting them but little of the
> benefit, because soft dependencies are included when building images,
> so our default installs are still going to include pkexec.
> 
> Why not just not have them recommended at all, and instead try to find
> all packages that use them and add dependencies, so that they will be
> included when an image or whatever really does need them? Is that
> considered too difficult?

I woould prefer having hard dependencies on the necessary packages
instead of a recommends.  Some of us run with weak dependencies turned
off and the missing requires will break things for us.  Having the
recommends in place will mask the breakage instead of letting it be
caught in testing.

Jim
___
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: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Owen Taylor]

On Wed, Feb 16, 2022 at 12:14 PM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec
> [..]
> `pkexec` and `pkla-compat`
> ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
> legacy tools that are no longer needed on a desktop and increase the
> attack surface as they are SetUID binaries (`pkexec`) or not
> maintained anymore (`pkla-compat`).


For pkexec, "no longer needed on a desktop" definitely does not reflect the
situation for Fedora Workstation and GNOME. If you run:

 grep org.freedesktop.policykit.exec.path /usr/share/polkit-1/actions/*

there is considerable usage - there are config files using pkexec provided
by, among others:

 gamemode, fedora-third-party, systemd, gnome-control-center,
gnome-system-monitor, gnome-settings-daemon, gvfs,

Would it be possible to rewrite all of the usage as D-Bus services? Yes -
but it would be considerable work and risk of new bugs and regressions.
(fedora-third-party is a recent addition by me - I considered not using
pkexec and writing a service instead, but it seemed like extra work and
complexity for little gain.)

If KDE or another desktop doesn't use pkexec, and there's a desire to split
pkexec out in packaging and add explicit dependencies on it, I'm not
opposed to that, but I don't think we should be calling pkexec legacy, and
it would require considerable (upstream, not just Fedora) changes to remove
the usage in Workstation.

- Owen
___
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: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Garry T. Williams]

On Wednesday, February 16, 2022 6:01:48 PM EST Adam Williamson wrote:
> I just tried this, actually, for giggles. Two reasons it's a non-
> starter: it prompts for the root password, not for my user password
> (my user is an 'admin' so far as sudo etc. are concerned, but
> apparently not an 'admin' so far as interactive pkexec is
> concerned).

That is odd.  I am never prompted for the root password for anything.
Maybe this is a policy difference between GNOME and KDE.

My supplemental groups:

wheel mock systemd-journal wireshark

> I do not know the root password, it is intentionally a
> 24-character random string I would have to look up. And it prompts
> with one of those goddamn 'secure' GNOME popovers which prevents you
> accessing your password manager, so every time you hit one, you have
> to cancel it, go to your password manager, copy the password it
> wants, then trigger it again.
>
> No way on earth I'm using that.

Again, in KDE, there is a prompt for MY password and it is only modal
as far as the pkexec command is concerned.  I can open my password
manager before responding to the prompt (not that I need to, since it
wants my password -- not root's).

Anyway, until this discussion, I never knew there was a pkexec.  I
note that pkexec will not operate correctly outside of my KDE session.
It prompts for my password from a terminal session and then fails with

$ pkexec ls
 AUTHENTICATING FOR org.freedesktop.policykit.exec 
Authentication is needed to run `/usr/bin/ls' as the super user
Authenticating as: Garry T. Williams (garry)
Password:
polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
 AUTHENTICATION FAILED 
Error executing command as another user: Not authorized

This incident has been reported.
$

Of course, sudo will operate correctly without a desktop session.  I
don't think I will be eager to use pkexec instead of sudo.

-- 
Garry T. Williams


___
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: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Owen Taylor]

On Thu, Feb 17, 2022 at 2:28 PM Adam Williamson 
wrote:

> On Wed, 2022-02-16 at 13:55 -0500, Neal Gompa wrote:
> > On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering
> >  wrote:
> > >
> > > On Mi, 16.02.22 12:12, Ben Cotton (bcot...@redhat.com) wrote:
> > >
> > > > `pkexec` and `pkla-compat`
> > > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package])
> are
> > > > legacy tools that are no longer needed on a desktop and increase the
> > > > attack surface as they are SetUID binaries (`pkexec`) or not
> > > > maintained anymore (`pkla-compat`).
> > >
> > > I find this wording weird... I seriously doubt we should consider
> > > "pkexec" legacy. It's the much nicer approach to the "sudo" problem,
> > > as mentioned in earlier discussions...
> > >
> > > Splitting it off into a separate package might be OK, but claiming
> > > that the fact that it is a suid binary makes it "legacy" sounds really
> > > strange to me, by that means we should also mark "sudo", "su", "ping",
> > > "mount", "umount", "write", "passwd", … and so on "legacy", but I
> > > doubt we are at that point, are we?
> > >
> > > hence I am not against the feature but please tone down the wording
> > > regarding pkexec, it's misleading. Say you want to split it out to
> > > reduce the attack surface, but don't use the word "legacy" in its
> > > context.
> > >
> > > (dropping "pkla-compat" given its unmaintained state is Ok to be
> > > called "legacy" i guess)
> > >
> >
> > I think I'd go stronger and say I don't really see the value in
> > splitting out pkexec at all. I'd rather people have a default path to
> > do safer privilege escalation, and pkexec is way better than
> > sudo/doas/etc in that regard.
>
> This feels a bit unrealistic to me. In the real world, I can recall off
> the top of my head exactly zero docs, guides, articles, howtos etc.
> that use pkexec. They all use sudo. Like it or not, sudo is what people
> use. The sensible thing to do there is devote attention to making sure
> sudo is as secure as possible, or actually make some kind of big effort
> to convince people to use pkexec instead.
>
> But just shipping pkexec as well as sudo by default is IMHO not helping
> anything, all it does is add unnecessary attack surface. I bet you
> could shoulder-surf for an entire weekend at Flock and not see a single
> person type 'pkexec'.
>

Perhaps it actually works well that pkexec is used for "behind-the-scenes"
privilege escalation, and sudo is what people are familiar with for
interactive and sysadmin-configured use. PolKit and hence pkexec can make
decisions on things that sudo doesn't have an idea about like the idea of
"logged in at a graphical console", but they aren't really useful if you
just want to quickly run a command as root with authentication.

I just tried this, actually, for giggles. Two reasons it's a non-
> starter: it prompts for the root password, not for my user password (my
> user is an 'admin' so far as sudo etc. are concerned, but apparently
> not an 'admin' so far as interactive pkexec is concerned). I do not
> know the root password, it is intentionally a 24-character random
> string I would have to look up. And it prompts with one of those
> goddamn 'secure' GNOME popovers which prevents you accessing your
> password manager, so every time you hit one, you have to cancel it, go
> to your password manager, copy the password it wants, then trigger it
> again.
>

I think you misinterpreted the prompt. Assuming your user is in the wheel
group:

 "Authentication is needed to run '' as the superuser'

Isn't asking for the root password, but rather your password to do
something as root.

- Owen
___
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: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Adam Williamson]

On Wed, 2022-02-16 at 13:55 -0500, Neal Gompa wrote:
> On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering
>  wrote:
> > 
> > On Mi, 16.02.22 12:12, Ben Cotton (bcot...@redhat.com) wrote:
> > 
> > > `pkexec` and `pkla-compat`
> > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
> > > legacy tools that are no longer needed on a desktop and increase the
> > > attack surface as they are SetUID binaries (`pkexec`) or not
> > > maintained anymore (`pkla-compat`).
> > 
> > I find this wording weird... I seriously doubt we should consider
> > "pkexec" legacy. It's the much nicer approach to the "sudo" problem,
> > as mentioned in earlier discussions...
> > 
> > Splitting it off into a separate package might be OK, but claiming
> > that the fact that it is a suid binary makes it "legacy" sounds really
> > strange to me, by that means we should also mark "sudo", "su", "ping",
> > "mount", "umount", "write", "passwd", … and so on "legacy", but I
> > doubt we are at that point, are we?
> > 
> > hence I am not against the feature but please tone down the wording
> > regarding pkexec, it's misleading. Say you want to split it out to
> > reduce the attack surface, but don't use the word "legacy" in its
> > context.
> > 
> > (dropping "pkla-compat" given its unmaintained state is Ok to be
> > called "legacy" i guess)
> > 
> 
> I think I'd go stronger and say I don't really see the value in
> splitting out pkexec at all. I'd rather people have a default path to
> do safer privilege escalation, and pkexec is way better than
> sudo/doas/etc in that regard.

This feels a bit unrealistic to me. In the real world, I can recall off
the top of my head exactly zero docs, guides, articles, howtos etc.
that use pkexec. They all use sudo. Like it or not, sudo is what people
use. The sensible thing to do there is devote attention to making sure
sudo is as secure as possible, or actually make some kind of big effort
to convince people to use pkexec instead.

But just shipping pkexec as well as sudo by default is IMHO not helping
anything, all it does is add unnecessary attack surface. I bet you
could shoulder-surf for an entire weekend at Flock and not see a single
person type 'pkexec'.

I just tried this, actually, for giggles. Two reasons it's a non-
starter: it prompts for the root password, not for my user password (my
user is an 'admin' so far as sudo etc. are concerned, but apparently
not an 'admin' so far as interactive pkexec is concerned). I do not
know the root password, it is intentionally a 24-character random
string I would have to look up. And it prompts with one of those
goddamn 'secure' GNOME popovers which prevents you accessing your
password manager, so every time you hit one, you have to cancel it, go
to your password manager, copy the password it wants, then trigger it
again.

No way on earth I'm using that.
-- 
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

Re: strange ppc64le failures

[Dan Horák]

On Thu, 17 Feb 2022 20:06:48 +0100
Florian Weimer  wrote:

> * Peter Lemenkov:
> 
> > I've got a very suspiciously looking compilation issues while building
> > PSPP package. All other arches are good except for ppc64le. Just grep
> > for "error:" in the log attached.
> >
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
> > * https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
> > (ppc64le build log)
> >
> > Is it a known issue or something new?
> 
> Your package contains a bundled copy of sys/cdefs.h, a glibc header.
> It probably comes from gnulib.  You need to delete it or import an
> updated version of gnulib.

actually this seems to be the better case, pspp is using a system copy
of gnulib (from gnulib-devel), we should fix it (replace the cdefs.h
or rebase to newer snapshot)


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

Re: strange ppc64le failures

[Florian Weimer]

* Peter Lemenkov:

> I've got a very suspiciously looking compilation issues while building
> PSPP package. All other arches are good except for ppc64le. Just grep
> for "error:" in the log attached.
>
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
> * https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
> (ppc64le build log)
>
> Is it a known issue or something new?

Your package contains a bundled copy of sys/cdefs.h, a glibc header.
It probably comes from gnulib.  You need to delete it or import an
updated version of gnulib.

Thanks,
Florian
___
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-20220217.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

Fedora-Cloud-35-20220217.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

New failures (same test not failed in Fedora-Cloud-35-20220216.0):

ID: 1133606 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1133606

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-35-20220216.0):

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

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

strange ppc64le failures

[Peter Lemenkov]

[resent w/o 500+ kBytes file attached]

Hello,
I've got a very suspiciously looking compilation issues while building
PSPP package. All other arches are good except for ppc64le. Just grep
for "error:" in the build log.

* https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
* https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
(ppc64le build log)

Is it a known issue or something new?


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

Re: Do we have any policy for disabling inactive users

[Stephen Snow]

On Thu, 2022-02-17 at 19:22 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Feb 16, 2022 at 12:51:13PM -0500, Stephen Snow wrote:
> > On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote:
> > > On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote:
> > > > Hello,
> > > > I don't mean to jump in the midle here, and I am just tossing
> > > > out
> > > > an
> > > > idea for consideration that doesn't address security issues
> > > > pointed
> > > > out
> > > > really, but does discuss the non-responsive main maintainer. 
> > > > I note there is a difficulty in defining the criteria for
> > > > determining
> > > > when an (apparently) inactive packager should be removed from
> > > > the
> > > > packager group. Perhaps a different POV is required. What is
> > > > the
> > > > problem trying to be solved? Removal of inactive packagers? Or
> > > > the
> > > > demotion of said packager in favour for the one(s) who are
> > > > supporting
> > > > the package to be promoted to main.
> > > 
> > > The former. The main issue here is a security concern: that the
> > > accounts of dormant packagers could be taken over and used for
> > > evil.
> > > So
> > > just shuffling the deckchairs of whether someone is a 'primary'
> > > or
> > > 'co'
> > > maintainer on a given package doesn't help. As long as they are
> > > allowed
> > > to submit official builds of the package, the problem remains
> > But wouldn't be possible to move their deckchair into a sandbox?
> 
> That is what we are effectively doing. By removing them from
> @packager,
> they lose write access to packages. It is also very easy to undo.
> In your approach, we'd do this package-by-package. That'd be more
> complicated and harder to undo, and wouldn't really help with
> the security concerns.
> 
Thanks for the explanation, and I appreciate that I was naive
potentially with my simplistic question and the complexity of doing
packager rights on a per package basis does seem onerous. So if I
understand it correctly this is a @packager group level demotion, so no
longer a packager at all, but could be easily promoted to that status
if need be in the future. That would seem to be a sensible approach.

I would assume there is already a process to deal with accounts that
may have been compromised.

Stephen
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 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: Review swap - python-specfile

[Ken Dreyer]

On Wed, Feb 16, 2022 at 4:09 AM Nikola Forró  wrote:
> Hello,
>
> is there anybody willing to review python-specfile [1]?

Your email made me look at this upstream
(https://github.com/packit/specfile). It looks interesting! I wonder
if we could use it more broadly (like for pyrpkg). It reminds me of
https://github.com/containerbuildsystem/dockerfile-parse .

I'm looking forward to playing around with this API.

- Ken
___
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-IoT-37-20220217.1 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

ID: 1133200 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1133200
ID: 1133260 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1133260
ID: 1133353 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1133353
ID: 1133494 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1133494
ID: 1133611 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1133611

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

Re: Do we have any policy for disabling inactive users

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 16, 2022 at 12:51:13PM -0500, Stephen Snow wrote:
> On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote:
> > On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote:
> > > Hello,
> > > I don't mean to jump in the midle here, and I am just tossing out
> > > an
> > > idea for consideration that doesn't address security issues pointed
> > > out
> > > really, but does discuss the non-responsive main maintainer. 
> > > I note there is a difficulty in defining the criteria for
> > > determining
> > > when an (apparently) inactive packager should be removed from the
> > > packager group. Perhaps a different POV is required. What is the
> > > problem trying to be solved? Removal of inactive packagers? Or the
> > > demotion of said packager in favour for the one(s) who are
> > > supporting
> > > the package to be promoted to main.
> > 
> > The former. The main issue here is a security concern: that the
> > accounts of dormant packagers could be taken over and used for evil.
> > So
> > just shuffling the deckchairs of whether someone is a 'primary' or
> > 'co'
> > maintainer on a given package doesn't help. As long as they are
> > allowed
> > to submit official builds of the package, the problem remains
> But wouldn't be possible to move their deckchair into a sandbox?

That is what we are effectively doing. By removing them from @packager,
they lose write access to packages. It is also very easy to undo.
In your approach, we'd do this package-by-package. That'd be more
complicated and harder to undo, and wouldn't really help with
the security concerns.

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

Re: Review requests

[Mattia Verga via devel]

Il 15/02/22 11:15, Sandro Mani ha scritto:

> Hi
>
> I've submitted the two packages which are missing dependencies for review, 
> which I'd appreciate if someone could review, as mingw-python-requests and 
> mingw-python-OWSLib are currently FailsToInstall:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2053753 - 
> mingw-python-charset-normalizer - needed for mingw-python-requests
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2053761 - mingw-pyproj - 
> needed for mingw-python-OWSLib
>
> Both are straight forward mingw-python packages. Happy to review in exchange.
>
> Thanks
> Sandro

Both taken. If you have some time I have these two waiting in the queue:

https://bugzilla.redhat.com/show_bug.cgi?id=2051107 - python-pymediawiki
https://bugzilla.redhat.com/show_bug.cgi?id=2053682 - stellarsolver

The first one should be quite simple, while stellarsolver is a bit more 
complex... feel free to choose one (if you can).

Thanks
Mattia___
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: F36 Beta blocker status summary

[Stephen Gallagher]

On Thu, Feb 10, 2022 at 3:27 PM Ben Cotton  wrote:

> Now that we've reached the branch point, it's time to start doing
> weekly blocker summaries again! Beta freeze begins on 22 February and
> the current target Beta release date is 15 March.
>
> Action summary
> 
>
> Accepted blockers
> -
>
...

> 3. fedora-release — fedora-release-identity-cloud says "Cloud
> Edition", Cloud has not been an edition for years — NEW
> ACTION: Maintainers to update fedora-release-identity-cloud or
> group-with-such-authority to waive this.
>
...

I offer https://src.fedoraproject.org/rpms/fedora-release/pull-request/215
as a potential solution here. (Rawhide version at
https://src.fedoraproject.org/rpms/fedora-release/pull-request/214)
___
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 2053914] perl-Dist-Milla-1.0.21 is available

[bugzilla]

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



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

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.
https://bugzilla.redhat.com/show_bug.cgi?id=2053914
___
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: F36 Beta blocker status summary

[Ben Cotton]

As a reminder: Beta freeze begins on 22 February and the current
target Beta release date is 15 March.


Action summary


Accepted blockers
-
1. anaconda — When running anaconda on Wayland with two keyboard
layouts configured, hitting any modifier key with the second layout
selected switches to the first layout — ASSIGNED
ACTION: Maintainers to diagnose issue

2. distribution — Fedora 36 backgrounds not present on
release-blocking desktops (GNOME, KDE) — ASSIGNED
ACTION: KDE Maintainers to update background packages (BZ 2055437)

3. fedora-release — fedora-release-identity-cloud says "Cloud
Edition", Cloud has not been an edition for years — NEW
ACTION: Maintainers to update fedora-release-identity-cloud or
group-with-such-authority to waive this.

4. kwin — openQA clicks in anaconda on KDE stop working shortly after
it starts — NEW
ACTION: Maintainers to diagnose issue

5. libinput — GNOME doesn't accept input from wireless keyboard if
there's not another "keyboard" input available — NEW
ACTION: Maintainers to diagnose issue

6. dnf — exclude_from_weak_autodetect=true effectively renders rich
weak dependencies useless — NEW
ACTION: QA and maintainers to test upstream PR

Proposed blockers
-

1. distribution — Some variants are missing /etc/resolv.conf symlink
(use systemd-resolved) — POST
ACTION: QA to verify issue is resolved

2. gnome-shell — Updating gnome-shell to 42~beta-1.fc37 or mutter to
42~beta-1.fc37 version breaks the login screen. — ON_QA
ACTION: QA to verify a compose with gjs-1.71.1

3. pipewire — dnf system-upgrade 35 to 36 fails with various pipewire
wireplumber conflicts — NEW
ACTION: Maintainers to diagnose and fix issue


Bug-by-bug detail
=

Accepted blockers
-
1.  anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2016613 — ASSIGNED
When running anaconda on Wayland with two keyboard layouts configured,
hitting any modifier key with the second layout selected switches to
the first layout

adamwill's research shows that this bug has existed since F25, but
became more viisble after KDE switched to Wayland by default. This bug
was deferred to F36 Beta under the "too hard to fix" exception.
There's ongoing discussion trying to come up with a potential fix,
however we still seem to be a long way from that point.

2. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2052654 — NEW
Fedora 36 backgrounds not present on release-blocking desktops (GNOME, KDE)

Update FEDORA-2022-08d5acc11b adds the F36 backgrounds. KDE Plasma
needs an update to pick up the new backgrounds (BZ 2055437)

3. fedora-release — https://bugzilla.redhat.com/show_bug.cgi?id=2018271 — NEW
fedora-release-identity-cloud says "Cloud Edition", Cloud has not been
an edition for years

Waived from F35 final under the "late blocker exception." Cloud WG is
working on a proposal to re-promote Cloud to Edition status, but that
will not happen for F36 release cycle.

4. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2047503 — NEW
openQA clicks in anaconda on KDE stop working shortly after it starts

Shortly after the installer starts, mouse clicks in openQA stop
working. Using 'development mode' which allows for manual interaction
still works. This bug only affects KDE, and appears to have been
introduced in the KDE Plasma 5.24 pre-release on 2022-01-19. This bug
is accepted under the "hinders execution of required Beta test plans"
criterion.

5. libinput — https://bugzilla.redhat.com/show_bug.cgi?id=2017043 — NEW
GNOME doesn't accept input from wireless keyboard if there's not
another "keyboard" input available

On some hardware, devices with multiple capabilities that include
keyboard do not get registered as a keyboard. Thus they only work if
another keyboard is connected. It seems to mostly (or exclusively)
affect some ARM hardware.

6. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=2033130 — ASSIGNED
exclude_from_weak_autodetect=true effectively renders rich weak
dependencies useless

Behavior introduced by the "Enable exclude_from_weak_autodetect by
default in LIBDNF" System-Wide Change appear to have undesired effects
in some use cases, particularly with language packs. Upstream pull
request 1439 (https://github.com/rpm-software-management/libdnf/pull/1439)
contains an improvement for autodetection.


Proposed blockers
-

1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2032085 — POST
Some variants are missing /etc/resolv.conf symlink (use systemd-resolved)

Some variants are not using systemd-resolved as intended. With some
recently-merged changes to Anaconda, this appears to be working
correctly now, at least for ostree variants.

2. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2054761 — ON_QA
Updating gnome-shell to 42~beta-1.fc37 or mutter to 42~beta-1.fc37
version breaks the login screen.

A crash message is displayed instead of the login screen. This is
fixed in gjs 1.71.1.

3. 

Re: CVE's and older versions of software

[Dan Horák]

On Thu, 17 Feb 2022 10:26:54 -0500
"Steven A. Falco"  wrote:

> On 2/17/22 09:58 AM, Ben Beasley wrote:
> > This is covered by the Updates Policy[1]. There is quite a bit written 
> > there about why an incompatible update might or might not be allowed in a 
> > stable release. It also specifically addresses security updates[2], and 
> > describes how you can petition FESCo for an exception, either for a 
> > particular update or as a blanket exception for your package.
> > 
> > 
> > [1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions
> > 
> > [2] 
> > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#security-fixes
> > 
> 
> Thanks for the links.  I've opened an issue [1].
> 
> [1] https://pagure.io/fesco/issue/2762

personally I consider KiCad as the kind of application where I would not
like to get a major upgrade potentially breaking my work during a
lifetime of a Fedora release


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] Re: Plea: Take a moment before you branch everything for EPEL 9

[Felix Schwarz]

Am 17.02.22 um 13:52 schrieb Stephen John Smoogen:
The working assumption has been that the Fedora package is already cleaned up 
and dependencies are there because the main packager thought they were needed. I 
and other EPEL packagers have spent enough time 'cleaning up' a package and then 
getting yelled at by the main packager that I broke something important and they 
wanted me to not touch their package anymore. [Heck we have caused a couple of 
people to quit Fedora completely over the years because of this.]


I'm sorry that you had that experience however mine has been quite different: 
When worked on getting certbot in EPEL 8 I had to branch quite a few (2-3 dozen) 
packages and while doing that I added test suites and gpg verification if possible.


I never got any angry responses - maybe that is because Python packagers in 
Fedora are pretty nice people (we have Miro after all ;-). The key I think is to 
submit pull requests first and wait for some time. I have to admit that I got 
frustrated more than once by inactive packagers but as far as I can see there is 
no better alternative. Pushing stuff with provenpackager powers without PR is 
certainly quite toxic.


Anyway: I hope you'll have a better experience with EPEL 9 :-)
Felix
___
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: Packaging scrcpy with a precompiled APK dependency.

[Demi Marie Obenour]

On 2/16/22 15:57, Diego Herrera wrote:
> Hi. I was checking if the scrcpy software [1] could get packaged, but to
> continue I need to know how to package an APK package file. For context,
> this project consists on a Linux client and an Android server app that is
> uploaded as an APK package by the client to an Android device using adb to
> share the Android device screen.
> 
> The project provides the sources to build that APK file, but it depends on
> gradle and the Android SDK to build it. Even if we revive the gradle
> package, I doubt that we can package the Android SDK since it requires it's
> own set of licenses and I don't think that everything complies to the
> policies. I also don't know if there is a way to compile the APK without
> those dependencies.
> 
> On the other hand, the project also provides the precompiled APK that can
> get directly added to the package (that's how other distros package this
> software), but I doubt that adding a binary package complies with Fedora's
> policies even if its not used on the same Fedora machine.
> 
> Another idea that I thought of was to patch the program or add a script
> that downloads the APK on the first run and save it on userspace.
> Technically you are not packaging the binary, but in my opinion it's just a
> roundabout way to get the same result.
> 
> Is any of these approaches viable from a policy perspective? Is there a
> better way to do this? Or should I desist on packaging this project on
> Fedora for now?
> 
> [1] https://github.com/Genymobile/scrcpy
> 
> Best regards.
> 
> --
> Diego Herrera C.

Why is packaging the Android SDK not an option?

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.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: CVE's and older versions of software

[Steven A. Falco]

On 2/17/22 09:58 AM, Ben Beasley wrote:

This is covered by the Updates Policy[1]. There is quite a bit written there 
about why an incompatible update might or might not be allowed in a stable 
release. It also specifically addresses security updates[2], and describes how 
you can petition FESCo for an exception, either for a particular update or as a 
blanket exception for your package.


[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions

[2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#security-fixes



Thanks for the links.  I've opened an issue [1].

[1] https://pagure.io/fesco/issue/2762

Steve
___
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: CVE's and older versions of software

[Ben Beasley]

This is covered by the Updates Policy[1]. There is quite a bit written 
there about why an incompatible update might or might not be allowed in 
a stable release. It also specifically addresses security updates[2], 
and describes how you can petition FESCo for an exception, either for a 
particular update or as a blanket exception for your package.



[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions

[2] 
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#security-fixes


On 2/17/22 09:23, Steven A. Falco wrote:
That is a good point.  KiCad now plans to have annual major version 
bumps - these will naturally not coincide with Fedora releases.  Thus 
I expect that Fedora will often have unsupported versions of KiCad for 
long periods of time, going forward.


Is approval from FESCO or other group needed to permit major version 
bumps in a stable Fedora release?


Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Bug 2055633] perl-Sereal-4.020 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Sereal-4.020-1.fc36
   ||perl-Sereal-4.020-1.fc37
Last Closed||2022-02-17 14:46:54



--- Comment #1 from Paul Howarth  ---
f36 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=82928171
rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=82927445


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

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[Troy Dawson]

On Thu, Feb 17, 2022 at 6:03 AM Miro Hrončok  wrote:

> On 17. 02. 22 13:52, Stephen John Smoogen wrote:
> >
> >
> > On Thu, 17 Feb 2022 at 07:11, Miro Hrončok  > > wrote:
> >
> > Hello EPEL packagers.
> >
> > I get it that you want as much as possible packages available in
> EPEL 9, but
> > before you blindly branch all the dependencies of the packages you
> care about,
> > could you maybe take a step back and consider for a few minutes if
> all the
> > dependencies actually make sense?
> >
> > The dependency might be a leftover from long time ago and might not
> be
> > actually
> > needed. Get rid of it in Fedora instead of keeping it that way on
> EPEL 9.
> >
> > The dependency might be optional (e.g. it is only BuildRequired to
> test
> > integration with that thing). Do you really need to add a package to
> EPEL 9
> > just because your package tests that it can interact with it if it
> is present?
> >
> >
> > The working assumption has been that the Fedora package is already
> cleaned up
> > and dependencies are there because the main packager thought they were
> needed.
>
> That is however not the reality. In reality, a Fedora package has an
> unknown
> quality. It has historical baggage. The miantainer who added that
> dependency
> has left 12 years ago. In my opinion, the EPEL packager should inspect the
> package they want to branch and improve both Fedora and EPEL by getting it
> in a
> better shape. I see now that you've been yelled at in the past for doing
> that
> (that is a new information to me) so I understand why you would not want
> to do
> that again. See my next replies.
>
> > I and other EPEL packagers have spent enough time 'cleaning up' a
> package and
> > then getting yelled at by the main packager that I broke something
> important
> > and they wanted me to not touch their package anymore. [Heck we have
> caused a
> > couple of people to quit Fedora completely over the years because of
> this.]
>
> In the past we didn't have pull requests. I don't propose the EPEL
> maintainers
> go and change Fedora packages freely. I propose they suggest changes. And
> if
> the Fedora maintainers are not interested, they can just make those
> changes in
> EPEL branches only.
>
> Furthermore, some changes are not suitable for Fedora but might be
> suitable for
> EPEL. IMHO we must understand that some maintainers might not want an
> %if-%rhel
> conditional to be pushed to a Fedora branch by the EPEL maintainer. That
> however does not mean the change cannot be done in EPEL only to avoid an
> unwanted dependency.
>
> See for example this PR:
>
> https://src.fedoraproject.org/rpms/python-django/pull-request/24
>
> The EPEL maintainer suggested to drop dependencies that are not needed.
> It turned out that it would skip a bunch of tests that we don't want to
> skip in
> Fedora.
>
> Had the EPEL maintainer pushed this change directly, the Fedora
> maintainers
> would be perfectly OK to tell them this was not OK.
> Instead, they used a pull request, received feedback and only done the
> changes
> in EPEL. Everybody is happy.
>
>
> > Due to that, we usually err on if the upstream SIG or packager has put
> the
> > package dependency in, they know what they are doing and we are just
> going to
> > cause another round of 'EPEL is breaking our distro' threads if we do
> > otherwise. Heck just getting the package into EPEL from many groups is
> on the
> > promise that WE DON'T MAKE CHANGES to their spec file. So while I
> understand
> > where you are coming from, we are also not in a position to know when we
> can do
> > this and when we can't.
>
> My opinion? It is always OK to suggest changes. It is never OK to push
> nontrivial changes without giving Fedora maintainers chance for a review
> (unless we enjoy being yelled at).
>
> > Finally. There is NO PROMISE that we are putting these packages in for
> 10
> > years. We have said this over and over again for the last 4 years, but
> it comes
> > up like a bad penny. Packages that are not useful and are not to be
> maintained
> > CAN and WILL be retired. We just need guidance versus pissed off emails.
>
> But packages that are not useful are being imported, built and left to
> rot. Why
> bother retiring them later if we don't bother not adding them in the first
> place? In other words, retiring the packages requires somebody to do
> exactly
> what I am asking here: Taking a moment to reconsider a dependency. I'm
> just
> asking everybody to do it now because I know from experience, that it will
> probably not happen later. The packages will be in EPEL forever, despite
> not
> being useful.
>
> >
> > The package might be deprecated in Fedora and used just because
> nobody got the
> > time to do a trivial removal of the dependency. Try removing it or
> poke the
> > Fedora maintainer to do it, before you blindly include that tech
> debt to EPEL
> > 9. (E.g. I'd be happy to 

Re: CVE's and older versions of software

[Steven A. Falco]

On 2/17/22 06:46 AM, Stephen Snow wrote:

On Wed, 2022-02-16 at 22:50 -0500, Demi Marie Obenour wrote:

On 2/16/22 18:05, Adam Williamson wrote:

On Wed, 2022-02-16 at 14:20 -0500, Steven A. Falco wrote:

On 2/16/22 01:58 PM, Dan Horák wrote:

On Wed, 16 Feb 2022 13:53:04 -0500
"Steven A. Falco"  wrote:


There are some CVE's against KiCad that have been fixed in
the latest version, namely KiCad 6.0.2.  I've built that for
F36 and Rawhide.

I have not released KiCad 6.0.2 into Fedora 34 and 35,
because my understanding is that by policy, we don't
generally allow "major version" updates in stable Fedora
releases.  Thus F34 and F35 still ship KiCad 5.1.12, which is
affected by the CVE's.

I could easily build KiCad 6.0.2 for F34 / F35 - in fact, I
have done so in the KiCad Copr repository.

So, should this situation be an exception to the policy of
"no major version changes in a stable release"?


as often, it depends :-)

- what's the severity level of the CVEs?
- does KiCad 6 come with substantial changes like UI redesign,
compatibility issues with previous release, etc?


The vulnerability is rated as "7.8 -
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", whatever that
means. :-)

Basically, attempting to read a malicious file can cause a buffer
overflow, and then execute malicious code.

KiCad is not suid, so the risk would be to an individual user
rather than the whole system.


As shown in https://xkcd.com/1200/, this is not a mitigation in
practice, because most Linux systems are single-user, which means
that
a user compromise is effectively equivalent to root compromise


KiCad 6 does have UI changes and files it creates cannot be read
by KiCad 5 or earlier.

I contacted upstream, and I know what patches form a part of the
solution, but they don't apply cleanly to KiCad 5.  I might be
able to sort them out...


The 'ideal' solution is to backport the security fix, yes. If
you're
not able to do this, or find anyone else who can do it for you, I
guess
it kinda becomes a judgment call whether fixing the security issue
is
"worth" the compatibility problems. I don't think we have a
definite
guide/policy to what to do if the optimal solution isn't practical,
here?


Security researcher here.  My view is that there are some packages
for
which the release cycle needs to be that of upstream, even if Fedora
has a different one.  Browser engines and the Linux kernel certainly
fall into that category, and complex desktop software such as KiCad
might as well.  I would rather take the compatibility breakage a bit
early than have an insecure system.


Fedora Linux user here +1 on these comments by Demi


That is a good point.  KiCad now plans to have annual major version bumps - 
these will naturally not coincide with Fedora releases.  Thus I expect that 
Fedora will often have unsupported versions of KiCad for long periods of time, 
going forward.

Is approval from FESCO or other group needed to permit major version bumps in a 
stable Fedora release?

Steve
___
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: Self-Introduction: Steve Cossette

[Steve Cossette]

Thank you very much! I will not let you down!

Le jeu. 17 févr. 2022, à 09 h 04, Ben Beasley  a
écrit :

> Thank you for contributing to Fedora. At the request[1] of Christopher
> King (FAS bunnyapocalypse), I have sponsored you to the packager group
> as a co-maintainer[2] for the lutris package.
>
> Welcome, and happy packaging!
>
> [1] https://pagure.io/packager-sponsors/issue/522
>
> [2]
>
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#become_a_co_maintainer
>
> On 2/14/22 07:11, Steve Cossette wrote:
> > Good morning, Fedora Developers. My name is Steve Cossette, I am a
> > Developer/IT Manager at a small HVAC company in Virginia who also
> > happens to be a real computer nerd.
> >
> > I started using Linux as my main OS in November, starting with Manjaro
> > and migrated over to Fedora 35 in December, craving better structure,
> > updates and stability. And I just fell in love with it.
> >
> > It only recently dawned on me that, unlike Windows, Linux distros are
> > maintained by the community (duh) so I thought I'd offer to help. One
> > of the ways I can help is by helping maintain packages (As a
> > Co-Maintainer).
> >
> > I'm willing to learn how to do so, and I believe it shouldn't be very
> > difficult as I do have experience building packages (I am also
> > managing several Linux-based servers for the last 5+ years) and also
> > know my way around code (I code in VB/c# in .NET).
> >
> > I was looking in the Fedora Docs for this information, but is there a
> > specific place I should look for a list of package maintainers looking
> > for package co-maintainers? Or looking to mentor one?
> >
> > Thanks!
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self-Introduction: Steve Cossette

[Ben Beasley]

Thank you for contributing to Fedora. At the request[1] of Christopher 
King (FAS bunnyapocalypse), I have sponsored you to the packager group 
as a co-maintainer[2] for the lutris package.


Welcome, and happy packaging!

[1] https://pagure.io/packager-sponsors/issue/522

[2] 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#become_a_co_maintainer


On 2/14/22 07:11, Steve Cossette wrote:
Good morning, Fedora Developers. My name is Steve Cossette, I am a 
Developer/IT Manager at a small HVAC company in Virginia who also 
happens to be a real computer nerd.


I started using Linux as my main OS in November, starting with Manjaro 
and migrated over to Fedora 35 in December, craving better structure, 
updates and stability. And I just fell in love with it.


It only recently dawned on me that, unlike Windows, Linux distros are 
maintained by the community (duh) so I thought I'd offer to help. One 
of the ways I can help is by helping maintain packages (As a 
Co-Maintainer).


I'm willing to learn how to do so, and I believe it shouldn't be very 
difficult as I do have experience building packages (I am also 
managing several Linux-based servers for the last 5+ years) and also 
know my way around code (I code in VB/c# in .NET).


I was looking in the Fedora Docs for this information, but is there a 
specific place I should look for a list of package maintainers looking 
for package co-maintainers? Or looking to mentor one?


Thanks!

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

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

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[Miro Hrončok]

On 17. 02. 22 13:52, Stephen John Smoogen wrote:



On Thu, 17 Feb 2022 at 07:11, Miro Hrončok > wrote:


Hello EPEL packagers.

I get it that you want as much as possible packages available in EPEL 9, but
before you blindly branch all the dependencies of the packages you care 
about,
could you maybe take a step back and consider for a few minutes if all the
dependencies actually make sense?

The dependency might be a leftover from long time ago and might not be
actually
needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9.

The dependency might be optional (e.g. it is only BuildRequired to test
integration with that thing). Do you really need to add a package to EPEL 9
just because your package tests that it can interact with it if it is 
present?


The working assumption has been that the Fedora package is already cleaned up 
and dependencies are there because the main packager thought they were needed.


That is however not the reality. In reality, a Fedora package has an unknown 
quality. It has historical baggage. The miantainer who added that dependency 
has left 12 years ago. In my opinion, the EPEL packager should inspect the 
package they want to branch and improve both Fedora and EPEL by getting it in a 
better shape. I see now that you've been yelled at in the past for doing that 
(that is a new information to me) so I understand why you would not want to do 
that again. See my next replies.


I and other EPEL packagers have spent enough time 'cleaning up' a package and 
then getting yelled at by the main packager that I broke something important 
and they wanted me to not touch their package anymore. [Heck we have caused a 
couple of people to quit Fedora completely over the years because of this.]


In the past we didn't have pull requests. I don't propose the EPEL maintainers 
go and change Fedora packages freely. I propose they suggest changes. And if 
the Fedora maintainers are not interested, they can just make those changes in 
EPEL branches only.


Furthermore, some changes are not suitable for Fedora but might be suitable for 
EPEL. IMHO we must understand that some maintainers might not want an %if-%rhel 
conditional to be pushed to a Fedora branch by the EPEL maintainer. That 
however does not mean the change cannot be done in EPEL only to avoid an 
unwanted dependency.


See for example this PR:

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

The EPEL maintainer suggested to drop dependencies that are not needed.
It turned out that it would skip a bunch of tests that we don't want to skip in 
Fedora.


Had the EPEL maintainer pushed this change directly, the Fedora maintainers 
would be perfectly OK to tell them this was not OK.
Instead, they used a pull request, received feedback and only done the changes 
in EPEL. Everybody is happy.



Due to that, we usually err on if the upstream SIG or packager has put the 
package dependency in, they know what they are doing and we are just going to 
cause another round of 'EPEL is breaking our distro' threads if we do 
otherwise. Heck just getting the package into EPEL from many groups is on the 
promise that WE DON'T MAKE CHANGES to their spec file. So while I understand 
where you are coming from, we are also not in a position to know when we can do 
this and when we can't.


My opinion? It is always OK to suggest changes. It is never OK to push 
nontrivial changes without giving Fedora maintainers chance for a review 
(unless we enjoy being yelled at).


Finally. There is NO PROMISE that we are putting these packages in for 10 
years. We have said this over and over again for the last 4 years, but it comes 
up like a bad penny. Packages that are not useful and are not to be maintained 
CAN and WILL be retired. We just need guidance versus pissed off emails.


But packages that are not useful are being imported, built and left to rot. Why 
bother retiring them later if we don't bother not adding them in the first 
place? In other words, retiring the packages requires somebody to do exactly 
what I am asking here: Taking a moment to reconsider a dependency. I'm just 
asking everybody to do it now because I know from experience, that it will 
probably not happen later. The packages will be in EPEL forever, despite not 
being useful.




The package might be deprecated in Fedora and used just because nobody got 
the
time to do a trivial removal of the dependency. Try removing it or poke the
Fedora maintainer to do it, before you blindly include that tech debt to 
EPEL
9. (E.g. I'd be happy to help you remove any python-mock or python-nose
dependency.)

I realize that analyzing the dependencies is tedious and boring. But please 
do
us all a favor and invest couple minutes of your time *before* you open that
bugzilla EPEL 9 request or branch that package. If you are not able to 
donate
couple 

[Bug 2055632] perl-Sereal-Encoder-4.020 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Sereal-Encoder-4.020-1
   ||.fc36
   ||perl-Sereal-Encoder-4.020-1
   ||.fc37
Last Closed||2022-02-17 13:53:40



--- Comment #1 from Paul Howarth  ---
f36 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=82927383
rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=82926845


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055632
___
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 2055631] perl-Sereal-Decoder-4.020 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Sereal-Decoder-4.020-1
   ||.fc36
   ||perl-Sereal-Decoder-4.020-1
   ||.fc37
Last Closed||2022-02-17 13:41:46



--- Comment #1 from Paul Howarth  ---
f36 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=82926814
rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=82925609


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

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[Stephen John Smoogen]

And of course sending emails like this do not help make things better for
either party. My apologies and I am going to cut back on sending email
without a 24 hour "Did you really want to send this timeout?"

On Thu, 17 Feb 2022 at 07:52, Stephen John Smoogen  wrote:

>
>
> Finally. There is NO PROMISE that we are putting these packages in for 10
> years. We have said this over and over again for the last 4 years, but it
> comes up like a bad penny. Packages that are not useful and are not to be
> maintained CAN and WILL be retired. We just need guidance versus pissed off
> emails.
>
>

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Packaging scrcpy with a precompiled APK dependency.

[Vitaly Zaitsev via devel]

On 16/02/2022 21:57, Diego Herrera wrote:
I was checking if the scrcpy software [1] could get packaged, but to 
continue I need to know how to package an APK package file.


All Fedora packages must be build from sources. You can't package and 
redistribute precompiled APK/JAR files.


It must be removed.


Another idea that I thought of was to patch the program or add a script that 
downloads the APK on the first run and save it on userspace. Technically you 
are not packaging the binary, but in my opinion it's just a roundabout way to 
get the same result.


You can upload this APK to one of the Android marketplaces like F-Droid 
and patch your package to show the download link.


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

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[Stephen John Smoogen]

On Thu, 17 Feb 2022 at 07:11, Miro Hrončok  wrote:

> Hello EPEL packagers.
>
> I get it that you want as much as possible packages available in EPEL 9,
> but
> before you blindly branch all the dependencies of the packages you care
> about,
> could you maybe take a step back and consider for a few minutes if all the
> dependencies actually make sense?
>
> The dependency might be a leftover from long time ago and might not be
> actually
> needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9.
>
> The dependency might be optional (e.g. it is only BuildRequired to test
> integration with that thing). Do you really need to add a package to EPEL
> 9
> just because your package tests that it can interact with it if it is
> present?
>
>
The working assumption has been that the Fedora package is already cleaned
up and dependencies are there because the main packager thought they were
needed. I and other EPEL packagers have spent enough time 'cleaning up' a
package and then getting yelled at by the main packager that I broke
something important and they wanted me to not touch their package anymore.
[Heck we have caused a couple of people to quit Fedora completely over the
years because of this.]

Due to that, we usually err on if the upstream SIG or packager has put the
package dependency in, they know what they are doing and we are just going
to cause another round of 'EPEL is breaking our distro' threads if we do
otherwise. Heck just getting the package into EPEL from many groups is on
the promise that WE DON'T MAKE CHANGES to their spec file. So while I
understand where you are coming from, we are also not in a position to know
when we can do this and when we can't.

Finally. There is NO PROMISE that we are putting these packages in for 10
years. We have said this over and over again for the last 4 years, but it
comes up like a bad penny. Packages that are not useful and are not to be
maintained CAN and WILL be retired. We just need guidance versus pissed off
emails.



> The package might be deprecated in Fedora and used just because nobody got
> the
> time to do a trivial removal of the dependency. Try removing it or poke
> the
> Fedora maintainer to do it, before you blindly include that tech debt to
> EPEL
> 9. (E.g. I'd be happy to help you remove any python-mock or python-nose
> dependency.)
>
> I realize that analyzing the dependencies is tedious and boring. But
> please do
> us all a favor and invest couple minutes of your time *before* you open
> that
> bugzilla EPEL 9 request or branch that package. If you are not able to
> donate
> couple minutes of your time to the package now, will you be able to take
> care
> of the dozens packages you've just imported in the next ten years?
>
> Thanks for listening, I'll show myself out.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 16, 2022 at 12:12:59PM -0500, Ben Cotton wrote:
> == Summary ==
> 
> This change is about enabling an opt-in ostree feature that re-mounts
> `/sysroot` as read only to avoid accidental changes.
> 
> Users and administrators are not expected to directly interact with
> the content available there and should instead use the interface
> offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
> manage their system.

> This change is about enabling an opt-in ostree feature that re-mounts
> `/sysroot` as read only to avoid accidental changes.
> 
> Users and administrators are not expected to directly interact with
> the content available there and should instead use the interface
> offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
> manage their system.

Not a big thing, but please remove the duplicated text.

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

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[Felix Schwarz]

+1

I'd like to highlight python3-nose and python3-mock. If your package depends on 
one of these you should really fix your package and/or code upstream.


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

[Bug 2055631] New: perl-Sereal-Decoder-4.020 is available

[bugzilla]

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

Bug ID: 2055631
   Summary: perl-Sereal-Decoder-4.020 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Decoder
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.020
Current version/release in rawhide: 4.019-1.fc36
URL: http://search.cpan.org/dist/Sereal-Decoder/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055631
___
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 2055633] New: perl-Sereal-4.020 is available

[bugzilla]

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

Bug ID: 2055633
   Summary: perl-Sereal-4.020 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.020
Current version/release in rawhide: 4.019-1.fc36
URL: http://search.cpan.org/dist/Sereal/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055633
___
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 2055632] New: perl-Sereal-Encoder-4.020 is available

[bugzilla]

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

Bug ID: 2055632
   Summary: perl-Sereal-Encoder-4.020 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Encoder
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.020
Current version/release in rawhide: 4.019-1.fc36
URL: http://search.cpan.org/dist/Sereal-Encoder/

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


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

[EPEL-devel] Plea: Take a moment before you branch everything for EPEL 9

[Miro Hrončok]

Hello EPEL packagers.

I get it that you want as much as possible packages available in EPEL 9, but 
before you blindly branch all the dependencies of the packages you care about, 
could you maybe take a step back and consider for a few minutes if all the 
dependencies actually make sense?


The dependency might be a leftover from long time ago and might not be actually 
needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9.


The dependency might be optional (e.g. it is only BuildRequired to test 
integration with that thing). Do you really need to add a package to EPEL 9 
just because your package tests that it can interact with it if it is present?


The package might be deprecated in Fedora and used just because nobody got the 
time to do a trivial removal of the dependency. Try removing it or poke the 
Fedora maintainer to do it, before you blindly include that tech debt to EPEL 
9. (E.g. I'd be happy to help you remove any python-mock or python-nose 
dependency.)


I realize that analyzing the dependencies is tedious and boring. But please do 
us all a favor and invest couple minutes of your time *before* you open that 
bugzilla EPEL 9 request or branch that package. If you are not able to donate 
couple minutes of your time to the package now, will you be able to take care 
of the dozens packages you've just imported in the next ten years?


Thanks for listening, I'll show myself out.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

[Sérgio Basto]

On Sun, 2022-02-13 at 14:11 +0100, Miro Hrončok wrote:
> Hey,
> apparently some ELF files are identical between Fedora's pypy3.7-libs
> and 
> pypy3.8-libs packages.
> 
> On Fedora 34, this leads to installation conflict:
> 
> Error: Transaction test error:
>    file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>    file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6
> from 
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
> package 
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> 
> As reported in https://bugzilla.redhat.com/2053880
> 
> I've read all the previous discussion about this on Fedora devel
> list, but I 
> still have no idea what should I do to prevent this conflict.
> 
> Moving the files to a common component seems like a bad idea given
> it's not 
> "two packages bundle the same thing" but rather "two packages built
> in a 
> different way".
> 
> I see this:
> 
> https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L177
> 
> %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> 
> I suppose I could pass in %{NAME} as well, right?


yes , I like your solution , as talked in previous messages we have a
long historical of .build-id file conflicts , which we should prevent 


> What are the side effects for changing the seed like this?:
> 
> %global __debug_install_post \
>  
> %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-
> seed%s+"',
> rpm.expand('--build-id-seed "%{NAME}-')))}
> 
> 
> Actually, should RPM pass %{NAME} by default? Or at least have a
> macro I could 
> redefine in a less cryptic and fragile way?
> 
> -- 
> 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

-- 
Sérgio M. B.
___
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 2055608] Perl 5.32.1 Incorrectly Processes Hash Key Existence in Two-Dimensional Hashes

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
   Doc Type|--- |If docs needed, set a value
 Status|NEW |CLOSED
Last Closed||2022-02-17 11:42:53



--- Comment #1 from Jitka Plesnikova  ---
This behavior is describe in perldoc for 'exists':


Note that the EXPR can be arbitrarily complicated as long as the 
final operation is a hash or array key lookup or subroutine
name:

if (exists $ref->{A}->{B}->{$key})  { }
if (exists $hash{A}{B}{$key})   { }

if (exists $ref->{A}->{B}->[$ix])   { }
if (exists $hash{A}{B}[$ix]){ }

if (exists &{$ref->{A}{B}{$key}})   { }

Although the most deeply nested array or hash element will not
spring into existence just because its existence was tested, any 
intervening ones will. Thus "$ref->{"A"}" and
"$ref->{"A"}->{"B"}" will spring into existence due to the
existence test for the $key element above. This happens anywhere
the arrow operator is used, including even here:

undef $ref;
if (exists $ref->{"Some key"}){ }
print $ref;  # prints HASH(0x80d3d5c)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608
___
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: CVE's and older versions of software

[Stephen Snow]

On Wed, 2022-02-16 at 22:50 -0500, Demi Marie Obenour wrote:
> On 2/16/22 18:05, Adam Williamson wrote:
> > On Wed, 2022-02-16 at 14:20 -0500, Steven A. Falco wrote:
> > > On 2/16/22 01:58 PM, Dan Horák wrote:
> > > > On Wed, 16 Feb 2022 13:53:04 -0500
> > > > "Steven A. Falco"  wrote:
> > > > 
> > > > > There are some CVE's against KiCad that have been fixed in
> > > > > the latest version, namely KiCad 6.0.2.  I've built that for
> > > > > F36 and Rawhide.
> > > > > 
> > > > > I have not released KiCad 6.0.2 into Fedora 34 and 35,
> > > > > because my understanding is that by policy, we don't
> > > > > generally allow "major version" updates in stable Fedora
> > > > > releases.  Thus F34 and F35 still ship KiCad 5.1.12, which is
> > > > > affected by the CVE's.
> > > > > 
> > > > > I could easily build KiCad 6.0.2 for F34 / F35 - in fact, I
> > > > > have done so in the KiCad Copr repository.
> > > > > 
> > > > > So, should this situation be an exception to the policy of
> > > > > "no major version changes in a stable release"?
> > > > 
> > > > as often, it depends :-)
> > > > 
> > > > - what's the severity level of the CVEs?
> > > > - does KiCad 6 come with substantial changes like UI redesign,
> > > > compatibility issues with previous release, etc?
> > > 
> > > The vulnerability is rated as "7.8 -
> > > CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", whatever that
> > > means. :-)
> > > 
> > > Basically, attempting to read a malicious file can cause a buffer
> > > overflow, and then execute malicious code.
> > > 
> > > KiCad is not suid, so the risk would be to an individual user
> > > rather than the whole system.
> 
> As shown in https://xkcd.com/1200/, this is not a mitigation in
> practice, because most Linux systems are single-user, which means
> that
> a user compromise is effectively equivalent to root compromise
> 
> > > KiCad 6 does have UI changes and files it creates cannot be read
> > > by KiCad 5 or earlier.
> > > 
> > > I contacted upstream, and I know what patches form a part of the
> > > solution, but they don't apply cleanly to KiCad 5.  I might be
> > > able to sort them out...
> > 
> > The 'ideal' solution is to backport the security fix, yes. If
> > you're
> > not able to do this, or find anyone else who can do it for you, I
> > guess
> > it kinda becomes a judgment call whether fixing the security issue
> > is
> > "worth" the compatibility problems. I don't think we have a
> > definite
> > guide/policy to what to do if the optimal solution isn't practical,
> > here?
> 
> Security researcher here.  My view is that there are some packages
> for
> which the release cycle needs to be that of upstream, even if Fedora
> has a different one.  Browser engines and the Linux kernel certainly
> fall into that category, and complex desktop software such as KiCad
> might as well.  I would rather take the compatibility breakage a bit
> early than have an insecure system.
> 
Fedora Linux user here +1 on these comments by Demi

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

[Bug 2055608] Perl 5.32.1 Incorrectly Processes Hash Key Existence in Two-Dimensional Hashes

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
This feature is called "autovivification". See perlref POD.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608
___
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 2055608] New: Perl 5.32.1 Incorrectly Processes Hash Key Existence in Two-Dimensional Hashes

[bugzilla]

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

Bug ID: 2055608
   Summary: Perl 5.32.1 Incorrectly Processes Hash Key Existence
in Two-Dimensional Hashes
   Product: Fedora
   Version: 34
  Hardware: x86_64
OS: Linux
Status: NEW
 Component: perl
  Severity: medium
  Assignee: jples...@redhat.com
  Reporter: b...@twics.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, iarn...@gmail.com,
jples...@redhat.com, ka...@ucw.cz,
mmasl...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rhug...@redhat.com,
sandm...@redhat.com, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Description of problem:

This appears to be a basic Perl runtime error. Checking for the existence of an
element in a two-dimensional hash has the side-effect of bringing into
existence a hash entry with the first index value. It's easier to see in code:

#!/usr/bin/perl

%X = ();
@I = ("1","2","3");
$N = 0;
foreach $D (@I)
{
$N++ if (exists($X{$D}{"A"}));
printf "K: %u\n",scalar(keys %X);
}
printf "N: %u\n",$N;

Running the code inexplicably generates this output:

K: 1
K: 2
K: 3
N: 0

Version-Release number of selected component (if applicable):

5.32.1 with 51 patches applied by Fedora (this is the current package version
available in Fedora 34)

How reproducible:

100%

Steps to Reproduce:
1. Run the above code
2.
3.

Actual results:

K: 1
K: 2
K: 3
N: 0

Expected results:

K: 0
K: 0
K: 0
N: 0

Additional info:

The problem only seems to arise with multi-dimensional hashes. Code such as:

#!/usr/bin/perl

%X = ();
@I = ("1","2","3");
$N = 0;
foreach $D (@I)
{
$N++ if (exists($X{$D}));
printf "K: %u\n",scalar(keys %X);
}
printf "N: %u\n",$N;

behaves as expected, returning:

K: 0
K: 0
K: 0
N: 0

I find it difficult to believe that this bug, if it is a bug rather than a
not-very-well-documented "feature," has not been noticed before, but perhaps
nothing critical depended upon it? But then again, something critical might, in
which case this package version dates back to 23 June 2021...


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608
___
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: Packaging scrcpy with a precompiled APK dependency.

[Alexander Sosedkin]

On Wed, Feb 16, 2022 at 10:00 PM Diego Herrera  wrote:
>
> Hi. I was checking if the scrcpy software [1] could get packaged, but to 
> continue I need to know how to package an APK package file. For context, this 
> project consists on a Linux client and an Android server app that is uploaded 
> as an APK package by the client to an Android device using adb to share the 
> Android device screen.
>
> The project provides the sources to build that APK file, but it depends on 
> gradle and the Android SDK to build it. Even if we revive the gradle package, 
> I doubt that we can package the Android SDK since it requires it's own set of 
> licenses and I don't think that everything complies to the policies. I also 
> don't know if there is a way to compile the APK without those dependencies.
>
> On the other hand, the project also provides the precompiled APK that can get 
> directly added to the package (that's how other distros package this 
> software), but I doubt that adding a binary package complies with Fedora's 
> policies even if its not used on the same Fedora machine.
>
> Another idea that I thought of was to patch the program or add a script that 
> downloads the APK on the first run and save it on userspace. Technically you 
> are not packaging the binary, but in my opinion it's just a roundabout way to 
> get the same result.
>
> Is any of these approaches viable from a policy perspective? Is there a 
> better way to do this? Or should I desist on packaging this project on Fedora 
> for now?
>
> [1] https://github.com/Genymobile/scrcpy

How's the version-to-version protocol compatibility doing?
If it's stable, would it make sense to package the Android part in
F-Droid and direct users to install it from there?

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

Re: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Jiri Konecny]

Thanks a lot for creating this. It wasn't nice experience after running 
`restorecon -Rv /` -- yeah, now I know you shouldn't do that on SB.


Jirka

Dne 16. 02. 22 v 18:12 Ben Cotton napsal(a):

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

== Summary ==

This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.

Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.

== Owner ==

* Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš
Popela]], [[User:jkonecny| Jiří Konečný]]
* Email: si...@fedoraproject.org, tpop...@fedoraproject.org, jkone...@redhat.com
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] ngo...@fedoraproject.org


== Detailed Description ==

On rpm-ostree based systems, the real root (the root directory of the
root partition on the disk) is mounted under the `/sysroot` path. By
default it contains the state of the system (the content of `var` and
`etc`) as well as the system versions themselves (each versioned copy
of `/usr`) in the ostree repository (`/ostree/repo`).

This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.

Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.

Example of issue: https://github.com/fedora-silverblue/issue-tracker/issues/232

This change replicates for Fedora Silverblue/Kinoite what has been
done in Fedora CoreOS in a previous release.

== Feedback ==

None so far.


== Benefit to Fedora ==

This will make Fedora Silverblue/Kinoite more robust to accidental
damage from users.

== Scope ==
* Proposal owners:
** Work on the changes requires for new installations (potentially
Anaconda configuration changes) and support for in place updates for
existing installations (requires a two step process).
* Other developers:
** Potential Anaconda changes required.
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

We will create a systemd unit that perform the updates in place for
existing systems. This will require a two step process (changing the
existing kernel arguments, and then enabling the ostree feature). Once
the feature is enabled, user won't be able to rollback to previous
deployments where the kernel argument is not set. We will have to
clearly document that in the documentation for easier troubleshooting.

== How To Test ==

Only try the following if you are confortable debugging an un-bootable
system and have made backups!

`$ sudo rpm-ostree kargs --append-if-missing=rw`

`$ sudo ostree config --repo=/sysroot/ostree/repo set "sysroot.readonly" "true"`

`$ sudo systemctl reboot`

Note that you can not "rollback" to the previous deployment to undo
this change. You will have to boot into a Live ISO and edit the config
file in the ostree repo to remove this config option.

== User Experience ==

There should be no visible change in user experience.

== Dependencies ==

Requires changes in Anaconda (maybe just config?) to set default kargs
and property on ostree repo for new installations.

== Contingency Plan ==

Revert the change before the release.

== Documentation ==

N/A (not a System Wide Change)

== Release Notes ==

TODO



___
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 2055412] perl-File-Find-utf8-0.014 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-1268123a5b has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-1268123a5b


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055412
___
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 2055412] perl-File-Find-utf8-0.014 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055412
___
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 2055412] perl-File-Find-utf8-0.014 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-File-Find-utf8-0.014-1
   ||.fc36



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055412
___
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 2055412] perl-File-Find-utf8-0.014 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055412
___
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: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

> https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec

> See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2

From a comment in the PR:
> IMHO making polkit-pkla-compat optional is seriously risky. The
> configuration can contain “if user=foo deny” entries, and silently
> ignoring those configuration files can break the security of the
> system.

If polkit indeed treats rules it doesn't have currently support for
as always satisfied, I would treat this is a blocker for splitting
out polkit-pkla-compat.

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