[Bug 1953146] New: perl-PDL-2.039 is available

[bugzilla]

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

Bug ID: 1953146
   Summary: perl-PDL-2.039 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PDL
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
jakub.jedel...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com, tjczep...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.039
Current version/release in rawhide: 2.38.0-1.fc35
URL: http://search.cpan.org/dist/PDL/

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


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

Re: Retiring a set of old X utilities

[Peter Hutterer]

On Fri, Apr 23, 2021 at 06:25:21PM +0900, Stephen J. Turnbull wrote:
> Peter Hutterer writes:
> 
>  > Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
>  > retire a set of old X utilities that I think don't need to be in Fedora:
>  > 
>  > oclock
>  > xbiff
>  > xload
>  > xman
>  > xrefresh
>  > xlogo
>  > xpr
>  > xfd
>  > viewres
>  > listres
>  > xconsole
> 
> Wow.  Can't argue that any of them should be in Fedora (although xlogo
> is in the X11 menu on my Mac! ;-), but seeing those retired is like
> going back to my hometown and discovering that my elementary school
> was replaced by a personal finance consultancy and barbershop.  :-)

don't worry, xeyes will stay around for the forseeable future, so just
direct all your sentinmental memories to that :)

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

Fedora 34 compose report: 20210423.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-34-20210423.n.0
NEW: Fedora-34-20210423.n.1

= SUMMARY =
Added images:2
Dropped images:  3
Added packages:  0
Dropped packages:0
Upgraded packages:   18
Downgraded packages: 0

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

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

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-34-20210423.n.1.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-34-20210423.n.1.iso

= DROPPED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-34-20210423.n.0.aarch64.raw.xz
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-34-20210423.n.0.armhfp.raw.xz
Image: KDE raw-xz aarch64
Path: Spins/aarch64/images/Fedora-KDE-34-20210423.n.0.aarch64.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  at-spi2-core-2.40.0-2.fc34
Old package:  at-spi2-core-2.40.0-1.fc34
Summary:  Protocol definitions and daemon for D-Bus at-spi
RPMs: at-spi2-core at-spi2-core-devel
Size: 1.84 MiB
Size change:  3.83 KiB
Changelog:
  * Thu Apr 15 2021 Adam Williamson  - 2.40.0-2
  - Install a scriptlet to fix AT_SPI_BUS for Xwayland apps run as root 
(#1821345)


Package:  dracut-053-4.fc34
Old package:  dracut-053-2.fc34
Summary:  Initramfs generator using udev
RPMs: dracut dracut-caps dracut-config-generic dracut-config-rescue 
dracut-live dracut-network dracut-squash dracut-tools
Size: 2.29 MiB
Size change:  20.12 KiB
Changelog:
  * Mon Apr 19 2021 Adam Williamson  - 053-3
  - Fix removal of key system files when kdump enabled (thanks kasong) 
(#1936781)

  * Mon Apr 19 2021 Dusty Mabe  - 053-4
  - Backport: fix(dracut-logger.sh): double dash trigger unknown logger 
warnings during run
  - Backport: fix(network-manager): nm-run.service: don't kill forked processes
  - Backport: fix(network-manager): only run NetworkManager if rd.neednet=1
  - Backport: fix(network-manager): use /run/NetworkManager/initrd/neednet in 
initqueue


Package:  efi-rpm-macros-5-2.fc34
Old package:  efi-rpm-macros-4-6.fc34
Summary:  Common RPM Macros for building EFI-related packages
RPMs: efi-filesystem efi-srpm-macros
Size: 29.00 KiB
Size change:  11 B
Changelog:
  * Tue Apr 06 2021 Peter Jones  - 5-1
  - Add arm as an alt for aarch64

  * Tue Apr 06 2021 Peter Jones  - 5-2
  - There's always a typo.


Package:  ibus-anthy-1.5.12-6.fc34
Old package:  ibus-anthy-1.5.12-4.fc34
Summary:  The Anthy engine for IBus input platform
RPMs: ibus-anthy ibus-anthy-devel ibus-anthy-python ibus-anthy-tests
Size: 5.24 MiB
Size change:  2.68 KiB
Changelog:
  * Tue Apr 20 2021 Takao Fujiwara  - 1.5.12-5
  - Delete postscripts

  * Wed Apr 21 2021 Takao Fujiwara  - 1.5.12-6
  - Resolves: #1948197 Move post to posttrans


Package:  ibus-chewing-1.6.1-13.fc34
Old package:  ibus-chewing-1.6.1-12.fc34
Summary:  The Chewing engine for IBus input platform
RPMs: ibus-chewing
Size: 505.85 KiB
Size change:  -750 B
Changelog:
  * Wed Apr 21 2021 Takao Fujiwara  - 1.6.1-13
  - Resolves: #1948197 Change post to posttrans


Package:  ibus-hangul-1.5.4-5.fc34
Old package:  ibus-hangul-1.5.4-4.fc34
Summary:  The Hangul engine for IBus input platform
RPMs: ibus-hangul ibus-hangul-tests
Size: 473.37 KiB
Size change:  -3.23 KiB
Changelog:
  * Wed Apr 21 2021 Takao Fujiwara  - 1.5.4-5
  - Resolves: #1948197 Change post to posttrans


Package:  ibus-input-pad-1.4.99.20140916-16.fc34
Old package:  ibus-input-pad-1.4.99.20140916-14.fc34
Summary:  Input Pad for IBus
RPMs: ibus-input-pad
Size: 210.29 KiB
Size change:  -752 B
Changelog:
  * Tue Apr 20 2021 Takao Fujiwara  - 1.4.99.20140916-15
  - Delete postscripts

  * Wed Apr 21 2021 Takao Fujiwara  - 1.4.99.20140916-16
  - Resolves: #1948197 Change post to posttrans


Package:  ibus-kkc-1.5.22-16.fc34
Old package:  ibus-kkc-1.5.22-15.fc34
Summary:  Japanese Kana Kanji input method for ibus
RPMs: ibus-kkc
Size: 424.22 KiB
Size change:  -782 B
Changelog:
  * Wed Apr 21 2021 Takao Fujiwara  - 1.5.22-16
  - Resolves: #1948197 Change post to posttrans


Package:  ibus-libpinyin-1.12.0-3.fc34
Old package:  ibus-libpinyin-1.12.0-2.fc34
Summary:  Intelligent Pinyin engine based on libpinyin for IBus
RPMs: ibus-libpinyin
Size: 4.83 MiB
Size change:  8.08 KiB
Changelog:
  * Wed Apr 21 2021 Takao Fujiwara  - 1.12.0-3
  - Resolves: #1948197 Change post to posttrans


Package:  ibus-rawcode-1.3.2-19.fc34
Old package:  ibus-rawcode-1.3.2-18.fc34
Summary:  The Rawcode engine for IBus input platform
RPMs: ibus-rawcode
Size: 128.91 KiB

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Jeff Law]

On 4/23/2021 6:37 PM, Tom Stellard wrote:

On 4/23/21 4:55 PM, Kevin Kofler via devel wrote:

Ben Cotton wrote:

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


Is the change owners' plan here to resubmit this same rejected change 
for
every single release until people get so fed up that they end up 
approving

it just to get it out of the way?



This change was never rejected.  It become stalled waiting for the change
owners to address some feedback from FESCo.  The feedback has been 
addressed now,

which is why it was resubmitted.


Right.  I just never had time to take the FESCo feedback and run the 
change to completion.  I'm not sure why Kevin is trying to characterize 
this as a rejected change.



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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 4:55 PM, Kevin Kofler via devel wrote:

Ben Cotton wrote:

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


Is the change owners' plan here to resubmit this same rejected change for
every single release until people get so fed up that they end up approving
it just to get it out of the way?



This change was never rejected.  It become stalled waiting for the change
owners to address some feedback from FESCo.  The feedback has been addressed 
now,
which is why it was resubmitted.

You can review the discussion here: https://pagure.io/fesco/issue/2409

-Tom


Sorry, but resubmitting a rejected change when nothing in the context
situation has really changed since is not a productive thing to do.

What will FESCo's workload look like if the owners of every rejected change
start doing this? Do you want me to resubmit "KDE Plasma Desktop by Default"
for every single release?

 Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Kevin Kofler via devel]

Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy

Is the change owners' plan here to resubmit this same rejected change for 
every single release until people get so fed up that they end up approving 
it just to get it out of the way?

Sorry, but resubmitting a rejected change when nothing in the context 
situation has really changed since is not a productive thing to do.

What will FESCo's workload look like if the owners of every rejected change 
start doing this? Do you want me to resubmit "KDE Plasma Desktop by Default" 
for every single release?

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

Fedora-34-20210423.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/189 (x86_64), 1/127 (aarch64)

ID: 867939  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/867939
ID: 867955  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/867955
ID: 868101  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/868101
ID: 868127  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/868127

Soft failed openQA tests: 4/189 (x86_64), 6/127 (aarch64)
(Tests completed, but using a workaround for a known bug)

ID: 867861  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/867861
ID: 867888  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/867888
ID: 867964  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/867964
ID: 867969  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/867969
ID: 867984  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/867984
ID: 867985  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/867985
ID: 868022  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/868022
ID: 868045  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/868045
ID: 868068  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/868068
ID: 868141  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/868141

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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Florian Weimer]

* Gary Buhrmaster:

> For C/C++ projects:
>
> If the upstream has no stated preference for the compiler, the
>packager SHOULD use the system default compiler (i.e. GCC).
>
> If the upstream specifies a preference, in their documentation,
>build, or support processes, the packager SHOULD follow
>the direction of the upstream.

Are there any upstreams that specify a preference for Clang in general?

Usually it's a specific binary build of Clang, or maybe a source build
with certain patches applied (and that is downloaded and built the first
time the project is built, as some sort of bootstrapping step).

So it's not so much “use Clang”, but “use our compiler, not the system
compiler”.

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-34-20210423.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/189 (x86_64), 7/127 (aarch64)

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

ID: 867630  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/867630
ID: 867673  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/867673
ID: 867704  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/867704
ID: 867714  Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/867714
ID: 867718  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/867718
ID: 867831  Test: aarch64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/867831

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

ID: 867621  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/867621
ID: 867689  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/867689
ID: 867783  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/867783
ID: 867809  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/867809

Soft failed openQA tests: 4/189 (x86_64), 5/127 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 867543  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/867543
ID: 867570  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/867570
ID: 867646  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/867646
ID: 867651  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/867651
ID: 867666  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/867666
ID: 867667  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/867667
ID: 867727  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/867727
ID: 867750  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/867750
ID: 867823  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/867823

Passed openQA tests: 182/189 (x86_64), 108/127 (aarch64)

Skipped non-gating openQA tests: 7 of 316

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
6 packages(s) added since previous compose: iscsi-initiator-utils, 
iscsi-initiator-utils-iscsiuio, isns-utils-libs, libblockdev-lvm, 
udisks2-iscsi, udisks2-lvm2
Previous test data: https://openqa.fedoraproject.org/tests/865711#downloads
Current test data: https://openqa.fedoraproject.org/tests/867544#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
6 packages(s) added since previous compose: iscsi-initiator-utils, 
iscsi-initiator-utils-iscsiuio, isns-utils-libs, libblockdev-lvm, 
udisks2-iscsi, udisks2-lvm2
System load changed from 0.10 to 0.27
Previous test data: https://openqa.fedoraproject.org/tests/865716#downloads
Current test data: https://openqa.fedoraproject.org/tests/867558#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 1.08 to 0.83
Previous test data: https://openqa.fedoraproject.org/tests/866602#downloads
Current test data: https://openqa.fedoraproject.org/tests/867597#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.63 to 0.50
Previous test data: https://openqa.fedoraproject.org/tests/866020#downloads
Current test data: https://openqa.fedoraproject.org/tests/867605#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 0.94 to 0.78
Previous test data: https://openqa.fedoraproject.org/tests/865779#downloads
Current test data: https://openqa.fedoraproject.org/tests/867616#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 1.99 to 0.93
Previous test data: https://openqa.fedoraproject.org/tests/865780#downloads
Current test data: https://openqa.fedoraproject.org/tests/867617#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.29 to 0.40
Previous test data: 

Fedora Linux 34 Final is GO

[Ben Cotton]

The Fedora 34 Final RC1.2 compose [1] is GO and will be shipped live
on Tuesday, 27 April 2021.

For more information please check the Go/No-Go meeting minutes [2] or logs [3].

Thank you to everyone who has worked on this on-time release.

[1] https://dl.fedoraproject.org/pub/alt/stage/34_RC-1.2/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-04-23/f34-final-go_no_go-meeting.2021-04-23-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-04-23/f34-final-go_no_go-meeting.2021-04-23-17.00.log.html

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

[Test-Announce] Fedora Linux 34 Final is GO

[Ben Cotton]

The Fedora 34 Final RC1.2 compose [1] is GO and will be shipped live
on Tuesday, 27 April 2021.

For more information please check the Go/No-Go meeting minutes [2] or logs [3].

Thank you to everyone who has worked on this on-time release.

[1] https://dl.fedoraproject.org/pub/alt/stage/34_RC-1.2/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-04-23/f34-final-go_no_go-meeting.2021-04-23-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-04-23/f34-final-go_no_go-meeting.2021-04-23-17.00.log.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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

[Security] Critical OpenVPN update (CVE-2020-15078)

[David Sommerseth]

Hi,

Just a quick update on an OpenVPN update which was released this week.

Fedora packages are in the release pipe, but needs to get some karma to 
move on quicker.  Since this issue is critical, I'm adding an additional 
notice here.


The TL;DR version:

OpenVPN 2.5.1 and earlier versions allows a remote attackers to
bypass authentication and access control channel data on servers
configured with deferred authentication, which can be used to
potentially trigger further information leaks.

Details on the issue can be found here: 



Please test and update as soon as possible.


Updated packages


Fedora 33: 
Fedora 34: 
Fedora Rawhide: 



EPEL-7: 

EPEL-8: 




In addition, we have Fedora Copr builds with the latest OpenVPN 2.5 
release for distros shipping OpenVPN 2.4 in the main repos:




--
kind regards,

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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Jakub Jelinek]

On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> The Red Hat tools team believes that LLVM/Clang and GCC should be
> considered equals from
> a Fedora policy standpoint.  Selection of one toolchain over the other should 
> be
> driven by the packager's preferences not by Fedora specific policy.
> The only policy restriction should be that the compiler must exist in
> Fedora.

I'll be probably repeating myself, but the two compilers are known to be
ABI incompatible in very important ways, none of the
https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
bugs have been touched since last time this was discussed and I'm not aware
of any ABI compatibility testing between the two compilers.
So if some library packages switch compilers and programs using those
libraries don't or vice versa, this proposal has quite high risks of
introducing hard to debug debugs.

I agree that for open source software and generally for users it is useful
if there are multiple competing implementations, in this case for the
toolchain, and the competition has been IMHO quite fruitful for both GCC and
LLVM over the past years.  It is also very useful if open source packages
are made portable or kept portable, so that one can use multiple compilers
to compile them, one can benefit from different diagnostics, instrumentation
etc.  But I'm not sure this proposal is a step in the right direction
though, e.g. in the Firefox case that is being used as an example for this
proposal that leads in a completely different direction, a package that has
been formerly portable and supported multiple compilers will turn into a
single compiler only application and will lose its portability.
Google, Apple, BSDs don't really care about toolchain choice and they push
a single toolchain only.

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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 23.04.2021 17:18, Ben Cotton wrote:

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.


+1 for this change.

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

[Bug 1952976] New: perl-List-AllUtils-0.19 is available

[bugzilla]

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

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



Latest upstream release: 0.19
Current version/release in rawhide: 0.18-2.fc34
URL: http://search.cpan.org/dist/List-AllUtils/

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


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 9:44 AM, Björn Persson wrote:

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc


[...]


Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.


Should the macro names really contain "toolchain" if they only select
the compiler? "Toolchain" suggests to me that they swap out the whole
toolchain including preprocessor, compiler, assembler, linker and
whatever else may be involved.



Having a consistent toolchain is important, and I wanted to name it so that
in the future there would be the flexibility to change other parts of
the toolchain if needed.

-Tom



Björn Persson


___
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: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Robert Marcano via devel]

On 4/23/21 12:52 PM, Tom Stellard wrote:

On 4/23/21 9:38 AM, Robert Marcano via devel wrote:

On 4/23/21 11:18 AM, Ben Cotton wrote:

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

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstel...@redhat.com


== Detailed Description ==

The main goal here is to give a packager some freedom to select the
best compiler for their package.  This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so.  The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:

* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the 
package.


If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers.  This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:

* %cc   - equivalent to %__cc (C Compiler)
* %cxx  - equivalent to %__cxx (C++ Compiler)
* %cpp  - equivalent to %_cpp (C preprocessor)

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.

== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==

This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience.  Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.

An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.

Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).

== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if 

Fedora-IoT-34-20210423.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/15 (aarch64)

New failures (same test not failed in Fedora-IoT-34-20210422.0):

ID: 868197  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/868197
ID: 868202  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/868202

Old failures (same test failed in Fedora-IoT-34-20210422.0):

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

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

Old soft failures (same test soft failed in Fedora-IoT-34-20210422.0):

ID: 868174  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/868174

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

New passes (same test not passed in Fedora-IoT-34-20210422.0):

ID: 868196  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/868196
ID: 868204  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/868204
-- 
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: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 9:38 AM, Robert Marcano via devel wrote:

On 4/23/21 11:18 AM, Ben Cotton wrote:

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

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstel...@redhat.com


== Detailed Description ==

The main goal here is to give a packager some freedom to select the
best compiler for their package.  This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so.  The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:

* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the package.

If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers.  This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:

* %cc   - equivalent to %__cc (C Compiler)
* %cxx  - equivalent to %__cxx (C++ Compiler)
* %cpp  - equivalent to %_cpp (C preprocessor)

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.

== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==

This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience.  Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.

An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.

Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).

== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if they want, but there is no
required action for 

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 9:27 AM, Qiyu Yan wrote:

在 2021-04-23星期五的 11:18 -0400，Ben Cotton写道：

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

replacing current
%global toolchain clang
or
%global toolchain gcc

described at
https://src.fedoraproject.org/rpms/redhat-rpm-config//blob/rawhide/f/macros#_41
?


No, you would still need to use the toolchain macro.  The bcond_with is for 
adding
an option that you can pass to rpmbuild or mock to control the compiler.  I will
try to add a full example to the packager guidelines so this is clear, but if
you wanted to add the option to build with clang, while still using gcc by 
default,
then your spec file would look like this:

%bcond_with toolchain_clang

%if %{with toolchain_clang}
%global toolchain clang
%endif

-Tom




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


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Gary Buhrmaster]

On Fri, Apr 23, 2021 at 3:57 PM Daniel P. Berrangé  wrote:

> This is quite a niche problem that's unlikely to cause issues
> for most people, but its a illustration that swapping compilers
> out can have unexpected consequences/complications.

Presuming I am remembering my s390x history
correctly, that is a most interesting use case, as
to why someone needs to emulate a z900 which
was EOS over six years ago, and for which a
z12 should (famous last words) be able to run
all the same user level software(*) would likely
be separately interesting.

But I think most would agree that there will always
be edge cases (and s390x does seem to find
edge cases).


(*) I suppose if you have something like a z/OS
v1.7 image that was never upgraded to a z/OS
version more recent with the necessary hardware
enablements for a z12 that might be a reason.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Jeff Law]

On 4/23/2021 9:57 AM, Daniel P. Berrangé wrote:

On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy == Summary == 
Fedora has historically forced packages to build with GCC unless the 
upstream project for the package only supported Clang/LLVM. This 
change proposal replaces that policy with one where, given a good 
technical reason, a packager may: * Choose to build with their 
package with clang even if the upstream project supports gcc. * 
Choose to build with gcc even if upstream does not support it. The 
goal is to give the packager the ability to use their own technical 
judgement to choose the best compiler. 
Does the choice have to be consistent per package, or is it within 
expectations to use different compilers on different Fedora arches ?
I'd think most packages would be consistent, but I don't think it 
necessarily needs to be policy.  If a package maintainer has a good 
reason to use gcc for part of the package and llvm/clang for another, 
then they should be able to do that.


== Detailed Description == 
It is worth noting that Clang/LLVM's implementation of 
-fstack-clash-protection, which is one of Fedora's default compiler 
flags, is under development and does not yet have an implementation 
for AArch64. 
This would suggest need to use GCC on x86 and CLang on aarch64 within 
a single package.
Note the lack of stack-clash on aarch64 is a transient issue.  It is 
being worked on, but just didn't make it into llvm12, I would expect it 
to land for llvm13 (Tom's a better resource on that going forward, so if 
he's got newer information than mine, believe his :-)



Upstream QEMU has been considering whether there's any loss of 
features implied by replacing GCC with use of CLang in QEMU builds. 
One edge case was discovered for s390x target. GCC has a min code 
generation target of z900 (hw release circa 2000), CLang has a min 
code genreation target of z10 (hw release circa 2008) This doesn't 
matter for compiling QEMU itself, as anyone actually running QEMU on 
an s390x is likely to have z10 or newer. It does cause a problem with 
firmware builds though. If QEMU wants to emulate old hardware 
(qemu-system-s390x -cpu z900 ..args...), then the firmware blob needs 
to have been built to target z900 which is not possible with CLang. So 
if QEMU is switched to use CLang, then we will possibly need to use 
GCC still for QEMU's firmware builds, or only use CLang on certain 
Fedora arches. This is quite a niche problem that's unlikely to cause 
issues for most people, but its a illustration that swapping compilers 
out can have unexpected consequences/complications.
This is a great example where trying to force consistency doesn't make 
sense and the maintainers can/should do what is best for the package and 
Fedora.


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Björn Persson]

> The policy update will also recommend that packagers use standardized
> macro names when using conditional options to control the compiler
> choice:
> 
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc

[...]

> Note this change is only for compiler selection.  It does not change
> existing policies WRT runtime library selection, linker selection,
> debuggers, etc.

Should the macro names really contain "toolchain" if they only select
the compiler? "Toolchain" suggests to me that they swap out the whole
toolchain including preprocessor, compiler, assembler, linker and
whatever else may be involved.

Björn Persson


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 8:57 AM, Daniel P. Berrangé wrote:

On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:

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

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.


Does the choice have to be consistent per package, or is it within
expectations to use different compilers on different Fedora arches ?



This would be up to the packager to decide.


== Detailed Description ==



It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.


This would suggest need to use GCC on x86 and CLang on aarch64 within
a single package.



Again, the packager would need to consider this when weighing the pros
and cons.

-Tom


== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==



Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).


Upstream QEMU has been considering whether there's any loss of
features implied by replacing GCC with use of CLang in QEMU builds.

One edge case was discovered for s390x target.

GCC has a min code generation target of z900 (hw release circa 2000),

CLang has a min code genreation target of z10 (hw release circa 2008)

This doesn't matter for compiling QEMU itself, as anyone actually
running QEMU on an s390x is likely to have z10 or newer.

It does cause a problem with firmware builds though. If QEMU wants
to emulate old hardware (qemu-system-s390x -cpu z900 ..args...),
then the firmware blob needs to have been built to target z900
which is not possible with CLang.

So if QEMU is switched to use CLang, then we will possibly need to
use GCC still for QEMU's firmware builds, or only use CLang on
certain Fedora arches.

This is quite a niche problem that's unlikely to cause issues
for most people, but its a illustration that swapping compilers
out can have unexpected consequences/complications.

Regards,
Daniel


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Robert Marcano via devel]

On 4/23/21 11:18 AM, Ben Cotton wrote:

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

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstel...@redhat.com


== Detailed Description ==

The main goal here is to give a packager some freedom to select the
best compiler for their package.  This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so.  The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:

* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the package.

If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers.  This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:

* %cc   - equivalent to %__cc (C Compiler)
* %cxx  - equivalent to %__cxx (C++ Compiler)
* %cpp  - equivalent to %_cpp (C preprocessor)

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.

== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==

This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience.  Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.

An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.

Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).

== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if they want, but there is no
required action for packagers with this change.
* Release engineering: 

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Jeff Law]

On 4/23/2021 10:32 AM, Tom Stellard wrote:

On 4/23/21 8:27 AM, Ben Cotton wrote:

On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton  wrote:


change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.


To be clear, does "given a good technical reason" imply that there is
some kind of approval process for this? Or that there's a way to
object to the compiler usage based on an insufficiently-good technical
reason?

Or is it just a way of saying "we trust you to exercise good judgment"?



I did not have in mind any kind of process for either approving the
technical justification or for auditing packages that had decided to
switch compilers to make sure their reasons are valid.
Nor did I when I made the original proposal.  I'm of the opinion that we 
should be
trusting the package maintainers and upstreams to make these kinds of 
decisions.





I think it would be better to not have an approval process, but I would
rather have this proposal + an approval process than no proposal at all.

Agreed.

And just to be clear to the wider community.  Tom asked to take over 
pushing on

this proposal after I left Red Hat.  I fully support that effort.

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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 8:37 AM, Gary Buhrmaster wrote:

On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton  wrote:


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



Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:



For C/C++ projects:

If the upstream has no stated preference for the compiler, the
packager SHOULD use the system default compiler (i.e. GCC).

If the upstream specifies a preference, in their documentation,
build, or support processes, the packager SHOULD follow
the direction of the upstream.

The packager MAY, at their discretion, choose to use
an alternative compiler that is otherwise available in
Fedora.  The reasons for those override choices
MUST be documented in the .spec file.



The current proposed changes to the packaging guidelines require
documenting the reason in bugzilla and linking it to an umbrella
"Non-default compiler" bug.  Is that sufficient?

-Tom

 ___

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


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 8:37 AM, Neal Gompa wrote:

On Fri, Apr 23, 2021 at 11:19 AM Ben Cotton  wrote:


An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.



This is not a good reason for changing the default compiler. This
makes it sound like Fedora alone is building Firefox with GCC, which
is not the case. If anything, *most* Linux distributions build it with
GCC. Even if I grant the idea that using Clang is "better", our builds
would not be very close to Mozilla's because we use different compiler
flags, system libraries, crypto policies, etc.

To me, this sounds like an excuse to avoid doing the right thing and
leveraging the toolchain that offers the highest quality code
generation (performance, security, etc.).

To be clear, I'm not necessarily outright saying this policy change is
bad, but the reasoning is weak and you're not providing a compelling
case for it. Fedora is known as the distribution where the folks
working on it help drive technical excellence in other projects, and
this sounds like you want to give up on that in this case.

I'm not particularly enthused by this Change if that's the kind of
rationale I would get for people switching compiler stacks.



OK, I also listed some other packages (qemu, clang, llvm) that might benefit,
what do you think of those reasons?  Or should I expand more on what the 
benefits
would be to those packages?

-Tom





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


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Ben Cotton]

On Fri, Apr 23, 2021 at 12:32 PM Tom Stellard  wrote:

> The proposed changes[1] to the packaging guidelines does require packagers
> document their reasons in bugzilla, but that's it.
>
At the risk of getting too bikesheddy, wouldn't it be better to
document it in the spec file? It seems like that would be easier to
find two years in the future when someone wants to know why a
particular package builds with compilerX instead of gcc.

Am I missing a benefit that having a tracking bug would provide?

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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Tom Stellard]

On 4/23/21 8:27 AM, Ben Cotton wrote:

On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton  wrote:


change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.


To be clear, does "given a good technical reason" imply that there is
some kind of approval process for this? Or that there's a way to
object to the compiler usage based on an insufficiently-good technical
reason?

Or is it just a way of saying "we trust you to exercise good judgment"?



I did not have in mind any kind of process for either approving the
technical justification or for auditing packages that had decided to
switch compilers to make sure their reasons are valid.

The proposed changes[1] to the packaging guidelines does require packagers
document their reasons in bugzilla, but that's it.

I think it would be better to not have an approval process, but I would
rather have this proposal + an approval process than no proposal at all.

-Tom

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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Qiyu Yan]

在 2021-04-23星期五的 11:18 -0400，Ben Cotton写道：
> The policy update will also recommend that packagers use standardized
> macro names when using conditional options to control the compiler
> choice:
> 
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc
replacing current 
%global toolchain clang
or
%global toolchain gcc

described at
https://src.fedoraproject.org/rpms/redhat-rpm-config//blob/rawhide/f/macros#_41
?
-- 
Qiyu Yan
GPG keyid: 0x4FC914F065F2DF12






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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Gary Buhrmaster]

On Fri, Apr 23, 2021 at 3:38 PM Neal Gompa  wrote:

> To me, this sounds like an excuse to avoid doing the right thing and
> leveraging the toolchain that offers the highest quality code
> generation (performance, security, etc.).

I am not in favor of switching the distro (or any
package) to the compiler flavor of the month (llvm
this week, gcc next month, llvm six months from
now, etc.) to constantly be chasing the current
best toolchain.

And neither am I in favor of requiring packagers
to use a toolchain that upstream is not interested
in supporting (anyone should be free to spend
their time on such, requiring others to do so
does not sound like a good choice to me).
___
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: Kerberos and Fedora's 2FA UX

[Kevin Fenzi]

On Fri, Apr 23, 2021 at 07:40:14AM +0200, Miroslav Suchý wrote:
> I have been using 2FA with the new Fedora Account system and the UX is ... 
> can be improved. The question is how?
...snip...

I am pretty sure the IPA folks are aware that this can be improved and
are working on it. Hopefully one of them will chime in here. :) 

kevin


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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 4/23/21 5:37 PM, Gary Buhrmaster wrote:
> On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>>
> 
> Ultimately, I think what the packaging guidelines should be if
> the proposal is accepted are essentially:
> 
> 
> 
> For C/C++ projects:
> 
> If the upstream has no stated preference for the compiler, the
>packager SHOULD use the system default compiler (i.e. GCC).
> 
> If the upstream specifies a preference, in their documentation,
>build, or support processes, the packager SHOULD follow
>the direction of the upstream.
> 
> The packager MAY, at their discretion, choose to use
>an alternative compiler that is otherwise available in
>Fedora.  The reasons for those override choices
>MUST be documented in the .spec file.

+1 I think that this is a good way to formulate the guidelines around
this.

It also matches nicely with the firefox example from the changes page,
I have heard others in this thread call the reasoning surrounding
building firefox with llvm somewhat weak (I'm paraphrasing here),
but firefox is a quite large project; and needlessly deviating from
upstream really is not doing anyone any favors here IMHO.

Regards,

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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Daniel P . Berrangé]

On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
> 
> == Summary ==
> Fedora has historically forced packages to build with GCC unless the
> upstream project for the package only supported Clang/LLVM.  This
> change proposal replaces that policy with one where, given a good
> technical reason, a packager may:
> * Choose to build with their package with clang even if the upstream
> project supports gcc.
> * Choose to build with gcc even if upstream does not support it.
> 
> The goal is to give the packager the ability to use their own
> technical judgement to choose the best compiler.

Does the choice have to be consistent per package, or is it within
expectations to use different compilers on different Fedora arches ?

> == Detailed Description ==

> It is worth noting that Clang/LLVM's implementation of
> -fstack-clash-protection, which is one of Fedora's default compiler
> flags, is under development and does not yet have an implementation
> for AArch64.

This would suggest need to use GCC on x86 and CLang on aarch64 within
a single package.

> == Feedback ==
> * The original proposal stated that Fedora packagers should follow
> upstream's compiler preferences, but based on feedback, the proposal
> was updated to allow a packager to choose the compiler they feel is
> best as long as there is a valid technical reason to do so.
> 
> == Benefit to Fedora ==

> Other packages that may benefit include:
> * llvm/clang (currently has to disable LTO due to compilation failures).
> * qemu (could take advantage of clang's CFI hardening feature).

Upstream QEMU has been considering whether there's any loss of
features implied by replacing GCC with use of CLang in QEMU builds.

One edge case was discovered for s390x target.

GCC has a min code generation target of z900 (hw release circa 2000),

CLang has a min code genreation target of z10 (hw release circa 2008)

This doesn't matter for compiling QEMU itself, as anyone actually
running QEMU on an s390x is likely to have z10 or newer.

It does cause a problem with firmware builds though. If QEMU wants
to emulate old hardware (qemu-system-s390x -cpu z900 ..args...),
then the firmware blob needs to have been built to target z900
which is not possible with CLang.

So if QEMU is switched to use CLang, then we will possibly need to
use GCC still for QEMU's firmware builds, or only use CLang on
certain Fedora arches.

This is quite a niche problem that's unlikely to cause issues
for most people, but its a illustration that swapping compilers
out can have unexpected consequences/complications.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

ELN composes

[Troy Dawson]

First, it looks like the ELN composes have been broken for a while.
It's failing on "Cant locate template for uri 'runtime-install.tmpl'"[1]
but lorax-templates-generic is installed.[2]
I'm at a loss on this one.

Second, I thought we were shifting ELN Composes to just be once a day.  It
looks like they are still every 3 hours.

Troy
[1] -
https://kojipkgs.fedoraproject.org//work/tasks/8652/66538652/mock_output.log
[2] - https://kojipkgs.fedoraproject.org//work/tasks/8652/66538652/root.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Gary Buhrmaster]

On Fri, Apr 23, 2021 at 3:30 PM Ben Cotton  wrote:

> Or is it just a way of saying "we trust you to exercise good judgment"?

If one does not trust the packagers good
judgement you likely have a bigger
issue to address.

I doubt many packagers are going to
change from the default compiler
unless there is a compelling reason.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Gary Buhrmaster]

On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>

Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:



For C/C++ projects:

If the upstream has no stated preference for the compiler, the
   packager SHOULD use the system default compiler (i.e. GCC).

If the upstream specifies a preference, in their documentation,
   build, or support processes, the packager SHOULD follow
   the direction of the upstream.

The packager MAY, at their discretion, choose to use
   an alternative compiler that is otherwise available in
   Fedora.  The reasons for those override choices
   MUST be documented in the .spec file.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Neal Gompa]

On Fri, Apr 23, 2021 at 11:19 AM Ben Cotton  wrote:
>
> An example of a package that could benefit from this policy is
> Firefox.  Upstream, the Firefox project builds primarily with
> Clang/LLVM.  Yet we force the Fedora package owner to find and fix
> issues building with GCC then either carry those custom fixes forward
> in Fedora or negotiate with upstream to get those changes upstreamed.
> While this process can be helpful in finding non-portable code, this
> is ultimately a poor use of the packager's time.
>
> Additionally Fedora loses the benefit of the testing provided by other
> distributions where Firefox is compiled in the same way as the
> upstream project -- when issues arise the Fedora team must consider
> the possibility that the problem is due to using GCC instead of
> Clang/LLVM or the patches to make that possible.  Again, this is a
> poor use of Fedora developer's time.
>

This is not a good reason for changing the default compiler. This
makes it sound like Fedora alone is building Firefox with GCC, which
is not the case. If anything, *most* Linux distributions build it with
GCC. Even if I grant the idea that using Clang is "better", our builds
would not be very close to Mozilla's because we use different compiler
flags, system libraries, crypto policies, etc.

To me, this sounds like an excuse to avoid doing the right thing and
leveraging the toolchain that offers the highest quality code
generation (performance, security, etc.).

To be clear, I'm not necessarily outright saying this policy change is
bad, but the reasoning is weak and you're not providing a compelling
case for it. Fedora is known as the distribution where the folks
working on it help drive technical excellence in other projects, and
this sounds like you want to give up on that in this case.

I'm not particularly enthused by this Change if that's the kind of
rationale I would get for people switching compiler stacks.




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

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Ben Cotton]

On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton  wrote:
>
> change proposal replaces that policy with one where, given a good
> technical reason, a packager may:
> * Choose to build with their package with clang even if the upstream
> project supports gcc.
> * Choose to build with gcc even if upstream does not support it.
>
To be clear, does "given a good technical reason" imply that there is
some kind of approval process for this? Or that there's a way to
object to the compiler usage based on an insufficiently-good technical
reason?

Or is it just a way of saying "we trust you to exercise good judgment"?

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

F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstel...@redhat.com


== Detailed Description ==

The main goal here is to give a packager some freedom to select the
best compiler for their package.  This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so.  The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:

* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the package.

If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers.  This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:

* %cc   - equivalent to %__cc (C Compiler)
* %cxx  - equivalent to %__cxx (C++ Compiler)
* %cpp  - equivalent to %_cpp (C preprocessor)

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.

== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==

This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience.  Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.

An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.

Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).

== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if they want, but there is no
required action for packagers with this change.
* Release engineering: [https://pagure.io/releng/issue/9503] (a 

F35 Change: CompilerPolicy Change (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstel...@redhat.com


== Detailed Description ==

The main goal here is to give a packager some freedom to select the
best compiler for their package.  This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so.  The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:

* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the package.

If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers.  This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:

* %cc   - equivalent to %__cc (C Compiler)
* %cxx  - equivalent to %__cxx (C++ Compiler)
* %cpp  - equivalent to %_cpp (C preprocessor)

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.

== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==

This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience.  Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.

An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.

Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).

== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if they want, but there is no
required action for packagers with this change.
* Release engineering: [https://pagure.io/releng/issue/9503] (a 

[Bug 1952877] perl-Prima-1.61 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Prima-1.61-1.fc35




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

[Bug 1952766] perl-File-ReadBackwards-1.06 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-File-ReadBackwards-1.0
   ||6-1.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-04-23 14:53:20




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

[rpms/perl-File-ReadBackwards] PR #1: Tests

[Jitka Plesnikova]

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

Merged pull-request:

``
Tests
``

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

[rpms/perl-File-ReadBackwards] PR #1: Tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: 
`perl-File-ReadBackwards` that you are following:
``
Tests
``

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

[Bug 1952877] perl-Prima-1.61 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
Some features removed. Suitable only for Rawhide.


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

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

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 104/189 (x86_64), 60/127 (aarch64)

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

ID: 867044  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/867044
ID: 867045  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/867045
ID: 867046  Test: x86_64 Server-dvd-iso install_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/867046
ID: 867047  Test: x86_64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/867047
ID: 867049  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/867049
ID: 867050  Test: x86_64 Server-dvd-iso install_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/867050
ID: 867051  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/867051
ID: 867052  Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/867052
ID: 867054  Test: x86_64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/867054
ID: 867056  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/867056
ID: 867058  Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/867058
ID: 867059  Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/867059
ID: 867061  Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/867061
ID: 867063  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/867063
ID: 867065  Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/867065
ID: 867066  Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/867066
ID: 867067  Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/867067
ID: 867097  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/867097
ID: 867098  Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/867098
ID: 867099  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/867099
ID: 867100  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/867100
ID: 867101  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/867101
ID: 867102  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/867102
ID: 867119  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/867119
ID: 867120  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/867120
ID: 867121  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/867121
ID: 867122  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/867122
ID: 867138  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/867138
ID: 867139  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/867139
ID: 867151  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/867151
ID: 867164  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/867164
ID: 867166  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/867166
ID: 867168  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/867168
ID: 867174  Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/867174
ID: 867175  Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/867175
ID: 867178  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/867178
ID: 867179  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/867179
ID: 867180  

[Bug 1952877] perl-Prima-1.61 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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

Fedora 34 compose report: 20210423.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-34-20210422.n.0
NEW: Fedora-34-20210423.n.0

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  0
Dropped packages:0
Upgraded packages:   5
Downgraded packages: 0

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

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-34-20210422.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-34-20210422.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  arm-image-installer-3.4-1.fc34
Old package:  arm-image-installer-3.1-2.fc34
Summary:  Writes binary image files to any specified block device
RPMs: arm-image-installer
Size: 53.48 KiB
Size change:  701 B
Changelog:
  * Tue Apr 06 2021 Paul Whalen  - 3.3-1
  - Update to 3.3

  * Mon Apr 19 2021 Paul Whalen  - 3.4-1
  - Update to 3.4
  - Add spi-flashing-disk script


Package:  bcm283x-firmware-20210407-1.8c7c524.fc34
Old package:  bcm283x-firmware-20210310-1.0591568.fc34
Summary:  Firmware for the Broadcom bcm283x/bcm2711 used in the Raspberry Pi
RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware 
bcm283x-overlays
Size: 13.67 MiB
Size change:  14.92 KiB
Changelog:
  * Sun Apr 11 2021 Peter Robinson  
20210407-1.8c7c524
  - Update to latest firmware


Package:  kde-settings-34.5-1.fc34
Old package:  kde-settings-34.4-1.fc34
Summary:  Config files for kde
RPMs: kde-settings kde-settings-plasma kde-settings-pulseaudio 
qt-settings
Size: 66.24 KiB
Size change:  635 B
Changelog:
  * Tue Apr 20 2021 Rex Dieter  - 34.5-1
  - kdeglobals: disable user switching (#1929643)


Package:  pam-1.5.1-5.fc34
Old package:  pam-1.5.1-3.fc34
Summary:  An extensible library which provides authentication for 
applications
RPMs: pam pam-devel pam-docs
Size: 4.60 MiB
Size change:  8.41 KiB
Changelog:
  * Mon Apr 12 2021 Iker Pedrosa  - 1.5.1-4
  - Change fingerprint-auth.pamd to return PAM_AUTHINFO_UNAVAIL from 
pam_fprintd.so
  - Clean auto-generated message from pam stack files

  * Fri Apr 16 2021 Benjamin Berg  - 1.5.1-5
  - Add script to avoid fingerprint-auth issues for long term Fedora users
Resolves: #1942443


Package:  uboot-tools-2021.04-2.fc34
Old package:  uboot-tools-2021.04-0.5.rc3.fc34
Summary:  U-Boot utilities
RPMs: uboot-images-armv7 uboot-images-armv8 uboot-tools
Size: 24.17 MiB
Size change:  -1.97 MiB
Changelog:
  * Wed Mar 17 2021 Peter Robinson  - 
2021.04-0.6.rc4
  - Update to 2021.04 RC4
  - Move to upstream fix for SMP on RPi3B and RPi3B+

  * Sun Apr 18 2021 Peter Robinson  - 2021.04-1
  - Update to 2021.04 GA
  - Fix DTB load check (rhbz 1946278)
  - Build Rockchip SPI support as idbloader.spi
  - Fixes for Rockchip devices
  - Build Turris Omnia for MMC/SPI/UART

  * Wed Apr 21 2021 Peter Robinson  - 2021.04-2
  - Revert keyboard console regression change (rhbz 1946278)



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

[Bug 1952766] perl-File-ReadBackwards-1.06 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|st...@silug.org |
   Doc Type|--- |If docs needed, set a value




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

[Test-Announce] Fedora 34 Candidate RC-1.2 Available Now!

[rawhide]

According to the schedule [1], Fedora 34 Candidate RC-1.2 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-34/f-34-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_34_RC_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
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 1952877] New: perl-Prima-1.61 is available

[bugzilla]

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

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



Latest upstream release: 1.61
Current version/release in rawhide: 1.60-2.fc34
URL: http://search.cpan.org/dist/Prima/

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


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

Re: Outreachy 2021 applicant

[KUNAL PRAKASH]

Hello Lukas.
I have noticed that spinner component run when we are calling LOAD_DATA for 
LandingPage component but not when we are loading LOAD_WIZARD_DATA for WIZARD 
component. I like to implement this feature. 

But I have some problem because we are using this.props.stable === 0 for 
LandingPage component. And there is no such state to handle for WIZARD 
component.

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

Fedora rawhide compose report: 20210423.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210422.n.0
NEW: Fedora-Rawhide-20210423.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  3
Dropped packages:1
Upgraded packages:   76
Downgraded packages: 1

Size of added packages:  34.44 MiB
Size of dropped packages:27.44 MiB
Size of upgraded packages:   6.35 GiB
Size of downgraded packages: 35.25 MiB

Size change of upgraded packages:   45.10 MiB
Size change of downgraded packages: 4.17 KiB

= ADDED IMAGES =
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20210423.n.0.iso

= DROPPED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20210422.n.0.iso

= ADDED PACKAGES =
Package: morphio-3.0.2-1.fc35
Summary: A python and C++ library for reading and writing neuronal morphologies
RPMs:morphio morphio-devel morphio-doc python3-morphio
Size:3.25 MiB

Package: toml11-3.6.1-1.fc35
Summary: TOML for Modern C++
RPMs:toml11-devel
Size:76.76 KiB

Package: xiphos-4.2.1-9.fc35
Summary: Bible study and research tool
RPMs:xiphos
Size:31.12 MiB


= DROPPED PACKAGES =
Package: python-cryptography-vectors-3.4.6-1.fc35
Summary: Test vectors for the cryptography package
RPMs:python3-cryptography-vectors
Size:27.44 MiB


= UPGRADED PACKAGES =
Package:  annobin-9.69-1.fc35
Old package:  annobin-9.68-1.fc35
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-plugin-clang 
annobin-plugin-gcc annobin-plugin-llvm
Size: 1.23 MiB
Size change:  2.44 KiB
Changelog:
  * Thu Apr 22 2021 Nick Clifton   - 9.69-1
  - Fix the testsuite so that it can be run in parallel.


Package:  awscli-1.19.56-1.fc35
Old package:  awscli-1.19.54-1.fc35
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.03 MiB
Size change:  -214 B
Changelog:
  * Thu Apr 22 2021 Gwyn Ciesla  - 1.19.55-1
  - 1.19.55

  * Thu Apr 22 2021 Gwyn Ciesla  - 1.19.56-1
  - 1.19.56


Package:  chrony-4.1-0.1.pre1.fc35
Old package:  chrony-4.0-4.fc35
Summary:  An NTP client/server
RPMs: chrony
Size: 1.50 MiB
Size change:  23.16 KiB
Changelog:
  * Thu Apr 22 2021 Miroslav Lichvar  4.1-0.1.pre1
  - update to 4.1-pre1
  - rework NM-dispatcher/dhclient detection
  - enable LTO on s390x


Package:  clang-12.0.0-1.fc35
Old package:  clang-12.0.0-0.11.rc5.fc35
Summary:  A C language family front-end for LLVM
RPMs: clang clang-analyzer clang-devel clang-libs 
clang-resource-filesystem clang-tools-extra git-clang-format python3-clang
Size: 220.84 MiB
Size change:  92.18 KiB
Changelog:
  * Wed Apr 14 2021 Tom Stellard  - 12.0.0-0.12.rc5
  - Add symlink to clang-format-diff in /usr/bin
  - rhbz#1939018

  * Fri Apr 16 2021 Tom Stellard  - 12.0.0-1
  - 12.0.0 Release


Package:  cockpit-machines-243.1-1.fc35
Old package:  cockpit-machines-243-1.fc35
Summary:  Cockpit user interface for virtual machines
RPMs: cockpit-machines
Size: 1.69 MiB
Size change:  4.29 KiB
Changelog:
  * Thu Apr 22 2021 Martin Pitt  - 243.1-1
  - Fix tooltip on Plug/Unplug button
  - Integration test fixes


Package:  compiler-rt-12.0.0-1.fc35
Old package:  compiler-rt-12.0.0-0.6.rc5.fc35
Summary:  LLVM "compiler-rt" runtime libraries
RPMs: compiler-rt
Size: 9.68 MiB
Size change:  21.68 KiB
Changelog:
  * Fri Apr 16 2021 Tom Stellard  - 12.0.0-1
  - 12.0.0 Release


Package:  crun-0.19.1-2.fc35
Old package:  crun-0.19-2.fc35
Summary:  OCI runtime written in C
RPMs: crun
Size: 847.85 KiB
Size change:  3.42 KiB
Changelog:
  * Thu Apr 22 2021 Giuseppe Scrivano  - 0.19.1-1
  - built version 0.19.1

  * Thu Apr 22 2021 Lokesh Mandvekar  - 0.19.1-2
  - rebuild for new bodhi


Package:  distribution-gpg-keys-1.52-1.fc35
Old package:  distribution-gpg-keys-1.51-1.fc35
Summary:  GPG keys of various Linux distributions
RPMs: distribution-gpg-keys distribution-gpg-keys-copr
Size: 17.21 MiB
Size change:  1.70 MiB
Changelog:
  * Thu Apr 22 2021 Miroslav Such??  1.52-1
  - update copr keys


Package:  dl-fedora-0.9-1.fc35
Old package:  dl-fedora-0.8-1.fc35
Summary:  Fedora image download tool
RPMs: dl-fedora
Size: 28.33 MiB
Size change:  74.78 KiB
Changelog:
  * Thu Apr 22 2021 Jens Petersen  - 0.9-1
  - edition is now an argument after release, not an option
  - --local --dryrun only accesses local files now for speed


Package:  dracut-053-5.fc35
Old package:  dracut-053-4.fc35
Summary:  Initramfs generator using udev
RPMs: dracut dracut-caps dracut-config-generic dracut-config-rescue 
dracut-live dracut-network dracut-squash dracut-tools
Size: 2.30 MiB
Size change:  5.98 KiB
Changelog:
  * Thu Apr 22 2021 Peter Robinson  - 053-5
  - Backport: fix(90kern

Retiring a set of old X utilities

[Stephen J. Turnbull]

Peter Hutterer writes:

 > Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
 > retire a set of old X utilities that I think don't need to be in Fedora:
 > 
 > oclock
 > xbiff
 > xload
 > xman
 > xrefresh
 > xlogo
 > xpr
 > xfd
 > viewres
 > listres
 > xconsole

Wow.  Can't argue that any of them should be in Fedora (although xlogo
is in the X11 menu on my Mac! ;-), but seeing those retired is like
going back to my hometown and discovering that my elementary school
was replaced by a personal finance consultancy and barbershop.  :-)
___
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 Source-git SIG kicked off successfully!

[Tomas Tomecek]

Happy Friday everyone!

We just wanted to give you a brief update that we successfully started
the Fedora Source-git SIG [1] yesterday via our first SIG meeting [2].

As this was our first contact, we did mostly introductions, talked
about the SIG setup and finally touched a bit on the topic of
source-based maintenance.

For those who would still want to join the group, please let me know.
We now have official communication channels: an issue tracker [3] and
an IRC channel [4].

If you want to be an early adopter (and thank you to all of you who
signalled their interest in my previous thread), you can watch for
updates here on devel@ once we start rolling the workflow out -
though, we need to develop and deploy it first :)


Happy hacking!
Tomas, on behalf of the SIG.


[1] https://fedoraproject.org/wiki/SIGs/Source-git
[2] 
https://meetbot.fedoraproject.org/packit/2021-04-22/source-git-sig.2021-04-22-13.01.html
[3] https://pagure.io/fedora-source-git/sig/issues
[4] #fedora-source-git at freenode
___
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: Kerberos and Fedora's 2FA UX

[Miro Hrončok]

On 23. 04. 21 7:40, Miroslav Suchý wrote:
I have been using 2FA with the new Fedora Account system and the UX is ... can 
be improved. The question is how?


If you are not using 2FA yet then you may not know what I am talking about. 
Here:

https://fedoraproject.org/wiki/Infrastructure/Kerberos#Command_line

You have to run:

     kinit -n @FEDORAPROJECT.ORG -c FILE:${HOME}/armor.ccache

     kinit -T FILE:${HOME}/armor.ccache @FEDORAPROJECT.ORG

To obtain the Kerberos ticket.

I already created my personal alias for this in my bashrc, but can we create 
some well known global alias for all Fedora's devels? Any other idea how to 
improve the UX?


I use this:

alias fkinit='kinit -n @FEDORAPROJECT.ORG -c 
FILE:/home/churchyard/.cache/armor.ccache && kinit -T 
FILE:/home/churchyard/.cache/armor.ccache churchy...@fedoraproject.org'


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

Fedora-Cloud-33-20210423.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

Re: Kerberos and Fedora's 2FA UX

[Pavel Raiskup]

On Friday, April 23, 2021 7:40:14 AM CEST Miroslav Suchý wrote:
> I have been using 2FA with the new Fedora Account system and the UX is ... 
> can be improved. The question is how?
> 
> If you are not using 2FA yet then you may not know what I am talking about. 
> Here:
> 
> https://fedoraproject.org/wiki/Infrastructure/Kerberos#Command_line
> 
> You have to run:
> 
>  kinit -n @FEDORAPROJECT.ORG -c FILE:${HOME}/armor.ccache
> 
>  kinit -T FILE:${HOME}/armor.ccache @FEDORAPROJECT.ORG

Additional feedback, the prompt is misleading:

$ kinit -T FILE:${HOME}/.krb5-fedora-armor.ccache prais...@fedoraproject.org
Enter OTP Token Value:

But it actually wants Password+Token.

Pavel


> To obtain the Kerberos ticket.
> 
> I already created my personal alias for this in my bashrc, but can we create 
> some well known global alias for all 
> Fedora's devels? Any other idea how to improve the UX?
> 
> Miroslav
> ___
> 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

[389-devel] 389 DS nightly 2021-04-23 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/04/23/report-389-ds-base-2.0.4-20210423git4559a89c0.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure