date:20220624

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

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



Releases retrieved: 3.18
Upstream release that is considered latest: 3.18
Current version/release in rawhide: 3.17-488.fc37
URL: http://search.cpan.org/dist/Encode/

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


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Encode


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

2022-06-24 Thread Orion Poplawski


On 6/24/22 08:48, Florian Weimer wrote:

* Miro Hrončok:

Thanks. I was searching mostly for "error:" and could not find anything.


It also helps to invoke make with -O if building with -jN, which for
some reason does not happen for this build.


Because it uses %cmake_build instead of %make_build:

-13: cmake_build
  %__cmake --build "%{__cmake_builddir}" %{?_smp_mflags} --verbose

Now, you can pass build-tool flags with:

cmake --build  [] [-- ]

but the problem then becomes that cmake supports multiple build tools, 
most notably ninja which does not support the -O option, and that many 
people need to pass options to cmake.  But I might start calling:


%cmake_build -- -O

although I'm not entirely sure that it really is getting passed to make 
- I can't see it though I don't see -j getting passed in the output but 
I'm pretty sure that gets passed down.


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic 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

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

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 16/233 (x86_64), 14/163 (aarch64)

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

ID: 1305872 Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/1305872
ID: 1305890 Test: x86_64 KDE-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1305890
ID: 1305914 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1305914
ID: 1305935 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1305935
ID: 1305945 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1305945
ID: 1306003 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1306003
ID: 1306024 Test: x86_64 Workstation-upgrade 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1306024
ID: 1306030 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1306030
ID: 1306054 Test: aarch64 Workstation-upgrade desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/1306054
ID: 1306055 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1306055
ID: 1306060 Test: aarch64 Workstation-upgrade clocks@uefi
URL: https://openqa.fedoraproject.org/tests/1306060
ID: 1306191 Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/1306191
ID: 1306199 Test: x86_64 Workstation-live-iso clocks
URL: https://openqa.fedoraproject.org/tests/1306199

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

ID: 1305866 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1305866
ID: 1305882 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1305882
ID: 1305898 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1305898
ID: 1305902 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1305902
ID: 1305906 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1305906
ID: 1305911 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1305911
ID: 1305944 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1305944
ID: 1305948 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1305948
ID: 1305981 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1305981
ID: 1306008 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1306008
ID: 1306034 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1306034
ID: 1306039 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1306039
ID: 1306043 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1306043
ID: 1306053 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1306053
ID: 1306065 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1306065
ID: 1306159 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1306159
ID: 1306174 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1306174

Soft failed openQA tests: 87/233 (x86_64), 58/163 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 1305792 Test: x86_64 Server-dvd-iso install_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/1305792
ID: 1305793 Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1305793
ID: 1305794 Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/1305794
ID: 1305795 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1305795
ID: 1305797 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1305797
ID: 1305798 Test: x86_64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1305798
ID:

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

2022-06-24 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0dde709329   
chromium-102.0.5005.115-1.el7


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

copr-cli-1.101-1.el7
python-copr-1.120-1.el7
python-rosdep-0.22.1-1.el7

Details about builds:



 copr-cli-1.101-1.el7 (FEDORA-EPEL-2022-6d38336660)
 Command line interface for COPR

Update Information:

copr-cli  - removed a depraceted build method `copr-cli buildfedpkg'  python-
copr  - disable network in Python API by default, this mimics what is done in
copr-cli for a long time

ChangeLog:

* Tue Jun 21 2022 Jakub Kadlcik  1.101-1
- Remove depraceted method `copr-cli buildfedpkg'




 python-copr-1.120-1.el7 (FEDORA-EPEL-2022-6d38336660)
 Python interface for Copr

Update Information:

copr-cli  - removed a depraceted build method `copr-cli buildfedpkg'  python-
copr  - disable network in Python API by default, this mimics what is done in
copr-cli for a long time

ChangeLog:

* Tue Jun 21 2022 Jakub Kadlcik  1.120-1
- Disable network on builders by default




 python-rosdep-0.22.1-1.el7 (FEDORA-EPEL-2022-23ef5085cc)
 ROS System Dependency Installer

Update Information:

Update to `rosdep` 0.22.1

ChangeLog:

* Fri Jun 24 2022 Scott K Logan  - 0.22.1-1
- Update to 0.22.1 (rhbz#2100935)

References:

  [ 1 ] Bug #2100935 - python-rosdep-0.22.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2100935


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

[Bug 2097080] perl-libwww-perl-6.67 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-libwww-perl-6.67-1.fc3 |perl-libwww-perl-6.67-1.fc3
   |6   |6
   ||perl-libwww-perl-6.67-1.fc3
   ||5



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2097080
___
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 2097281] perl-Lingua-Translit-0.29 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Lingua-Translit-0.29-1 |perl-Lingua-Translit-0.29-1
   |.el9|.el9
   ||perl-Lingua-Translit-0.29-1
   ||.fc36



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


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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-libwww-perl-6.67-1.fc3
   ||6
Last Closed||2022-06-25 01:11:43



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


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

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

2022-06-24 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3a6675bd1a   
chromium-102.0.5005.115-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-59cdfb46c4   
glances-3.2.5-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ac75a8517c   
exim-4.95-1.el8


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

copr-cli-1.101-1.el8
copr-messaging-0.6-1.el8
golang-x-net-0-0.60.20200807gitab34263.el8
golang-x-text-0.3.7-1.el8
kiwi-9.24.44-1.el8
python-copr-1.120-1.el8
python-rosdep-0.22.1-1.el8
rebase-helper-0.27.0-1.el8
strongswan-5.9.6-1.el8
testcloud-0.8.0-1.el8

Details about builds:



 copr-cli-1.101-1.el8 (FEDORA-EPEL-2022-6fe6d98425)
 Command line interface for COPR

Update Information:

copr-cli  - removed a depraceted build method `copr-cli buildfedpkg'  python-
copr  - disable network in Python API by default, this mimics what is done in
copr-cli for a long time

ChangeLog:

* Tue Jun 21 2022 Jakub Kadlcik  1.101-1
- Remove depraceted method `copr-cli buildfedpkg'




 copr-messaging-0.6-1.el8 (FEDORA-EPEL-2022-dbf2a63e55)
 Abstraction for Copr messaging listeners/publishers

Update Information:

copr-backend  - Consolidate the two hitcounter scripts - Dump Resalloc ticket ID
and hostname to backend.log - Automatically restart services in %%post - Don't
count RPMs downloaded from Mock - Attempt to sign multiple times - Try multiple
attempts of creating GPG keys   copr-dist-git  - Don't setgid(apache) while
importing ("uploading") - More obvious "locking" importer proctitle   copr-
frontend  - Start logging important events - Change logging formatter to show
also flask.g.user - APIv3 support for chroot_denylist - Restrict the CoprDir
names to :custom: - Don't require trailing slash in APIv3
/package/list - Don't hide CoprDir buttons in Builds web-ui - New command 'copr-
frontend chroots-template' - More understandable Pagure badges - Detect
ClientDisconnected errors   copr-messaging  - Adapt to the changed stomppy API
copr-rpmbuild  - Fix make_srpm with new git - Define copr-specific macros also
for SRPM builds - SCM method to clone recursively   python-copr-common  - Allow
SafeRequest's timeout to be specified

ChangeLog:

* Tue Jun 21 2022 Jakub Kadlcik  0.6-1
- Adapt to the changed stomppy API




 golang-x-net-0-0.60.20200807gitab34263.el8 (FEDORA-EPEL-2022-46b9d78e30)
 Go supplementary network libraries

Update Information:

## golang-x-text - Update to 0.3.7. Fixes rhbz#1945761. - Mitigate
CVE-2021-38561 (rhbz#2100495).  ## golang-x-net - Rebuild to mitigate
CVE-2021-38561 (rhbz#2100495).

ChangeLog:

* Fri Jun 24 2022 Maxwell G  - 0-0.60.20200807gitab34263
- Rebuild to mitigate CVE-2021-38561 (rhbz#2100495).

References:

  [ 1 ] Bug #2100495 - CVE-2021-38561 golang: out-of-bounds read in 
golang.org/x/text/language leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=2100495




 golang-x-text-0.3.7-1.el8 (FEDORA-EPEL-2022-46b9d78e30)
 Go text processing support

Update Information:

## golang-x-text - Update to 0.3.7. Fixes rhbz#1945761. - Mitigate
CVE-2021-38561 (rhbz#2100495).  ## golang-x-net - Rebuild to mitigate
CVE-2021-38561 (rhbz#2100495).

ChangeLog:

* Fri Jun 24 2022 Maxwell G  - 0.3.7-1
- Update to 0.3.7. Fixes rhbz#1945761.
- Mitigate CVE-2021-38561 (rhbz#2100495).

References:

  [ 1 ] Bug #2100495 - CVE-2021-38561 golang: out-of-bounds read in 
golang.org/x/text/language leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=2100495

[Bug 2097281] perl-Lingua-Translit-0.29 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Lingua-Translit-0.29-1
   ||.el9
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-06-25 00:33:29



--- Comment #7 from Fedora Update System  ---
FEDORA-EPEL-2022-9023e0f577 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2097281
___
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] 2022-06-27 @ 15:00 UTC - Fedora QA Meeting

2022-06-24 Thread Adam Williamson

# Fedora Quality Assurance Meeting
# Date: 2022-06-27
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat

Greetings testers!

We didn't meet for a couple of weeks, so let's do a quick check in. I
don't really have anything major for the agenda, so if nobody else does
this might be short!

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 37 check-in
3. Test Day / community event status
4. Open floor
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: List active versions for a package from CLI

2022-06-24 Thread Maxwell G via devel

On Friday, June 24, 2022 3:47:54 PM CDT Artur Frenszek-Iwicki wrote:
> When you go to a package's repo on src.fedoraproject.org,
> on the top of the page, you get this nice table that lists
> active Fedora and EPEL releases, and for each of those,
> prints the package version currently in stable and in testing.

> So I guess my question is, does fedpkg/koji/bodhi have this feature
> and I just can't find it, or is there a separate program for this,
> or is it just my memory playing tricks on me?

@juhp's fbrnch[1,2] tool has a status subcommand that does this. I'm not sure 
about the other tools.

[1]: https://github.com/juhp/fbrnch
[2]: https://packages.fedoraproject.org/pkgs/fbrnch/fbrnch/

On Friday, June 24, 2022 4:07:09 PM CDT Artur Frenszek-Iwicki wrote:
> So it is quite possible that it was, indeed, my memory
> playing tricks on me, and I used to get that info
> by calling the API endpoint.

The API endpoint that src.fp.o uses is 
https://src.fedoraproject.org/_dg/bodhi_updates/rpms/[packagename] .

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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

Fedora rawhide compose report: 20220624.n.1 changes

2022-06-24 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20220623.n.0
NEW: Fedora-Rawhide-20220624.n.1

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

Size of added packages:  17.19 KiB
Size of dropped packages:0 B
Size of upgraded packages:   8.30 GiB
Size of downgraded packages: 15.89 MiB

Size change of upgraded packages:   12.72 MiB
Size change of downgraded packages: 802.94 KiB

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

= DROPPED IMAGES =
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220623.n.0.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220623.n.0.s390x.qcow2

= ADDED PACKAGES =
Package: python-sphinx-pytest-0.0.3-1.fc37
Summary: Helpful pytest fixtures for sphinx extensions
RPMs:python3-sphinx-pytest
Size:17.19 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  OpenImageIO-2.3.14.0-10.fc37
Old package:  OpenImageIO-2.3.14.0-9.fc37
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 21.54 MiB
Size change:  4.00 KiB
Changelog:
  * Fri Jun 24 2022 Jonathan Wakely  - 2.3.14.0-10
  - Remove obsolete boost-python3-devel build dependency (#2100748)


Package:  adobe-source-han-mono-fonts-1.002-10.fc37
Old package:  adobe-source-han-mono-fonts-1.002-9.fc36
Summary:  Adobe OpenType monospaced font for mixed Latin and CJK text
RPMs: adobe-source-han-mono-fonts
Size: 82.91 MiB
Size change:  1.10 KiB
Changelog:
  * Thu Jun 23 2022 Akira TAGOH  - 1.002-10
  - Revise spec file for new fonts packaging guidelines.


Package:  ansible-collection-community-general-5.2.0-1.fc37
Old package:  ansible-collection-community-general-5.1.1-1.fc37
Summary:  Modules and plugins supported by Ansible community
RPMs: ansible-collection-community-general
Size: 1.34 MiB
Size change:  3.98 KiB
Changelog:
  * Fri Jun 24 2022 Maxwell G  - 5.2.0-1
  - Update to 5.2.0. Fixes rhbz#2099904.


Package:  ansible-freeipa-1.8.0-1.fc37
Old package:  ansible-freeipa-1.7.0-1.fc37
Summary:  Roles and playbooks to deploy FreeIPA servers, replicas and 
clients
RPMs: ansible-freeipa ansible-freeipa-tests
Size: 400.84 KiB
Size change:  12.08 KiB
Changelog:
  * Fri Jun 24 2022 Thomas Woerner  - 1.8.0-1
  - Update to version 1.8.0
https://github.com/freeipa/ansible-freeipa/releases/tag/v1.8.0


Package:  aom-3.4.0-1.fc37
Old package:  aom-3.2.0-5.fc36
Summary:  Royalty-free next-generation video format
RPMs: aom libaom libaom-devel
Size: 51.49 MiB
Size change:  -6.98 MiB
Changelog:
  * Sun Jun 19 2022 Robert-Andr?? Mauchin  3.4.0-1
  - Update to 3.4.0 Close: rhbz#2049182, rhbz#2083009


Package:  ark-22.04.2-1.fc37
Old package:  ark-22.04.1-1.fc37
Summary:  Archive manager
RPMs: ark ark-libs
Size: 6.48 MiB
Size change:  2.39 KiB
Changelog:
  * Thu Jun 23 2022 Than Ngo  - 22.04.2-1
  - 22.04.2


Package:  asterisk-18.12.1-1.fc37
Old package:  asterisk-18.4.0-1.fc35.1
Summary:  The Open Source PBX
RPMs: asterisk asterisk-ael asterisk-alembic asterisk-alsa 
asterisk-calendar asterisk-corosync asterisk-curl asterisk-dahdi asterisk-devel 
asterisk-fax asterisk-festival asterisk-hep asterisk-iax2 asterisk-ldap 
asterisk-lua asterisk-mgcp asterisk-minivm asterisk-mobile 
asterisk-mwi-external asterisk-mysql asterisk-odbc asterisk-oss asterisk-pjsip 
asterisk-portaudio asterisk-postgresql asterisk-radius asterisk-sip 
asterisk-skinny asterisk-snmp asterisk-sqlite asterisk-tds asterisk-unistim 
asterisk-voicemail asterisk-voicemail-odbc asterisk-voicemail-plain
Size: 38.67 MiB
Size change:  3.28 MiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
18.4.0-1.2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Tue Sep 14 2021 Sahana Prasad  - 18.4.0-1.3
  - Rebuilt with OpenSSL 3.0.0

  * Wed Jan 19 2022 Fedora Release Engineering  - 
18.4.0-1.4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Wed Jun 01 2022 Jitka Plesnikova  - 18.4.0-1.5
  - Perl 5.36 rebuild

  * Wed Jun 15 2022 Michal Josef ??pa??ek  - 18.4.0-1.6
  - Fix build (#1977579)

  * Wed Jun 15 2022 Michal Josef ??pa??ek  - 18.5.1-1
  - Update to upstream 18.5.1 release.

  * Wed Jun 15 2022 Michal Josef ??pa??ek  - 18.6.0-1
  - Update to upstream 18.6.0 release.

  * Wed Jun 15 2022 Michal Josef ??pa??ek  - 18.7.1-1
  - Update to upstream 18.7.1 release.

  * Wed Jun 15 2022 Michal Josef ??pa??ek  - 18.8.0-1
  - Update to upstream 18.8.0 release.

  * Wed Jun 15 2022 Michal Josef ??pa??ek  - 18.9.0-1
  - Update to upstream 18.9.0 release.

  * Wed Jun 15 2022 Michal

Re: List active versions for a package from CLI

2022-06-24 Thread Artur Frenszek-Iwicki

Just after sending this message, it occurred to me
that I could just use the developer tools in the browser
to check the URL of the API endpoint being called
and then just send a similar request using curl.

So it is quite possible that it was, indeed, my memory
playing tricks on me, and I used to get that info
by calling the API endpoint.

A.FI.

A.FI.
___
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

List active versions for a package from CLI

2022-06-24 Thread Artur Frenszek-Iwicki

When you go to a package's repo on src.fedoraproject.org,
on the top of the page, you get this nice table that lists
active Fedora and EPEL releases, and for each of those,
prints the package version currently in stable and in testing.

Now, I could swear that fedpkg had a similar feature.
Yet, looking at the list of commands, it's not there.

One way to mimic this would be to call "fedpkg releases-info"
to get the list of releases, and then use "koji latest-build $TAG $PKG",
possibly cross-checking that info with "bodhi updates query --packages $PKG".

So I guess my question is, does fedpkg/koji/bodhi have this feature
and I just can't find it, or is there a separate program for this,
or is it just my memory playing tricks on me?

A.FI.
___
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

superlu_dist-8.0.0

2022-06-24 Thread Antonio T. sagitter


Hi all.

Next release of superlu_dist will be in Rawhide not before next seven 
days. All dependent packages will be rebuilt.


Changelog: https://github.com/xiaoyeli/superlu_dist/releases/tag/v8.0.0

Regards.
--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0xCC1CFEF30920C8AE
GPG key server: https://keyserver1.pgp.com/


OpenPGP_0xCC1CFEF30920C8AE.asc
Description: OpenPGP public key


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

[Bug 2100969] New: perl-Math-BigInt-1.999836 is available

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

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



Releases retrieved: 1.999836
Upstream release that is considered latest: 1.999836
Current version/release in rawhide: 1.9998.35-3.fc37
URL: http://search.cpan.org/dist/Math-BigInt/

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


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Math-BigInt


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2100969
___
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: Where does "redhat-linux-build" come from?

2022-06-24 Thread Artur Frenszek-Iwicki

$ rpmbuild --showrc

The definition for %cmake is quite long, but includes this line:
%{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} \

%__cmake_builddir is defined as:
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}

And then %_vpath_builddir is defined as:
%{_vendor}-%{_target_os}-build

So that's where "redhat-linux-build" comes from.

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Maxwell G via devel


Jun 24, 2022 1:59:40 PM Jason Tibbitts :

> When a package is deprecated, the intent is that no new dependencies on
> any deprecated package would appear in the distribution, either by new
> packages or from existing packages adding dependencies.  Of course, I
> don't know what actually checks this; it's not particularly common to
> deprecate packages.
FedoraReview checks for deprecated dependencies. I don't think there's any 
process to make sure that existing packages don't start depending on deprecated 
packages.
--
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


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: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Demi Marie Obenour

On 6/23/22 08:51, Miro Hrončok wrote:
> On 23. 06. 22 11:43, Richard W.M. Jones wrote:
>> I think this is the correct incantation ...
>>
>> # dnf repoquery --disablerepo=\* --enablerepo=rawhide-source --arch=src 
>> --whatrequires openssl1.1-devel
>> Last metadata expiration check: 0:01:31 ago on Thu 23 Jun 2022 10:37:46 BST.
>> botan2-0:2.19.1-2.fc37.src
>> chatty-0:0.6.3-1.fc37.src
>> erlang-0:24.3.4.1-1.fc37.src
>> pypy-0:7.3.9-1.fc37.src
>> pypy3.7-0:7.3.9-1.3.7.fc37.src
>> pypy3.8-0:7.3.9-1.3.8.fc37.src
>> python-uamqp-0:1.5.3-2.fc37.src
>> python2.7-0:2.7.18-22.fc37.src
>> python3.6-0:3.6.15-9.fc37.src
>> python3.7-0:3.7.13-2.fc37.src
> 
> Not quite the right incantation, because it leaves out anything that does not 
> BuildRequire explicitly the string openssl1.1-devel but rather some of its 
> virtual provides. Here you go:
> 
> $ repoquery -q --repo=rawhide{,-source} --whatrequires openssl1.1-devel | 
> grep src$
> GoldenCheetah-1:3.6-0.16.20220520gita5d6468.fc37.src
> R-websocket-0:1.4.0-5.fc36.src
> argyllcms-0:2.3.0-2.fc36.src
> axel-0:2.17.11-2.fc37.src
> bigloo-0:4.4c-4.4.fc37.src
> blender-1:3.2.0-3.fc37.src
> boinc-client-0:7.18.1-3.fc37.src
> botan2-0:2.19.1-2.fc37.src
> cairo-dock-plug-ins-0:3.4.1-41.20210730gitf24f769.fc37.3.src
> casync-0:2-17.gitb3337dd.fc36.src
> chatty-0:0.6.3-1.fc37.src
> cpprest-0:2.10.18-5.fc36.src
> cryfs-0:0.11.2-3.fc37.src
> ddnet-0:15.9.1-1.fc37.src
> dmg2img-0:1.6.7-14.20170502.git.f16f247.fc36.src
> efitools-0:1.9.2-7.fc36.src
> eiskaltdcpp-0:2.4.2-6.fc37.src
> erlang-0:24.3.4.1-1.fc37.src
> fragments-0:1.5-4.fc36.src
> freerdp-2:2.7.0-1.fc37.src
> fuse-encfs-0:1.9.5-13.fc37.src
> gnupg-pkcs11-scd-0:0.10.0-1.fc37.src
> grpc-0:1.46.3-7.fc37.src
> guacamole-server-0:1.4.0-3.fc37.src
> hexchat-0:2.16.0-5.fc37.src
> jimtcl-0:0.81-3.fc36.src
> kcov-0:39-3.fc36.src
> kde-runtime-0:17.08.3-24.fc36.src
> kf5-kitinerary-0:22.04.1-2.fc37.src
> lgogdownloader-0:3.8-4.fc37.src
> libdigidocpp-0:3.14.7-1.fc36.src
> libfido2-0:1.11.0-1.fc37.src
> liboauth2-0:1.4.4-1.fc36.src
> libpreludedb-0:5.2.0-9.fc37.src
> libquentier-0:0.5.0-11.fc36.src
> librepo-0:1.14.3-2.fc37.src
> librhsm-0:0.0.3-7.fc36.src
> libshout-0:2.4.3-6.fc36.src
> libvncserver-0:0.9.13-12.fc36.src
> libzypp-0:17.25.6-5.fc36.src
> megatools-0:1.11.0-6.fc37.src
> mtxclient-0:0.7.0-2.fc37.src
> mumble-0:1.3.4-8.fc36.src
> newsboat-0:2.27-2.fc37.src
> nheko-0:0.9.3-2.fc37.src
> normaliz-0:3.9.3-1.fc37.src
> openarc-0:1.0.0-0.13.Beta3.fc37.src
> openfortivpn-0:1.17.0-4.fc36.src
> opensips-0:3.2.6-2.fc37.src
> osslsigncode-0:2.3-2.fc37.src
> p11-remote-0:0.3-13.fc36.src
> perl-Crypt-OpenSSL-EC-0:1.32-9.fc37.src
> perl-Crypt-SSLeay-0:0.72-36.fc37.src
> pl-0:8.4.3-1.fc37.src
> psi-plus-1:1.5.1625-1.fc37.src
> pypy-0:7.3.9-1.fc37.src
> pypy3.7-0:7.3.9-1.3.7.fc37.src
> pypy3.8-0:7.3.9-1.3.8.fc37.src
> python-uamqp-0:1.5.3-2.fc37.src
> python2.7-0:2.7.18-22.fc37.src
> python3.6-0:3.6.15-9.fc37.src
> python3.7-0:3.7.13-2.fc37.src
> qca-0:2.3.4-2.fc36.src
> qca-qt4-0:2.2.1-18.fc37.src
> qdigidoc-0:4.2.9-2.fc36.src
> qt5-qtlocation-0:5.15.4-1.fc37.src
> qt6-qtpositioning-0:6.3.0-2.fc37.src
> quentier-0:0.5.0-6.fc35.src
> radare2-0:5.6.8-1.fc37.src
> retroarch-0:1.10.3-1.fc37.src
> rizin-0:0.3.4-1.fc36.1.src
> rstudio-0:2022.02.3+492-1.fc37.src
> rust-0:1.61.0-2.fc37.src
> rust-openssl-sys-0:0.9.72-2.fc36.src
> rust-zincati-0:0.0.24-4.fc37.src
> s3fs-fuse-0:1.91-1.fc37.src
> sagemath-0:9.6-1.fc37.src
> scribus-0:1.5.8-3.fc37.src
> seadrive-daemon-0:2.0.16-4.fc37.src
> seadrive-gui-0:2.0.16-2.fc36.src
> seafile-0:8.0.6-2.fc37.src
> seafile-client-0:8.0.6-1.fc37.src
> shairport-sync-0:3.3.9-2.fc36.src
> sipp-0:3.6.0-9.fc36.src
> sleef-0:3.5.1-16.fc36.src
> sqlcipher-0:4.4.3-4.fc36.src
> srain-0:1.4.0-2.fc37.src
> the_foundation-0:1.4.0-1.fc37.src
> tpm2-tools-0:5.2-2.fc36.src
> webextension-token-signing-0:1.1.5-1.fc36.src
> websocketpp-0:0.8.2-7.fc36.src
> wimlib-0:1.13.5-1.fc36.src
> xmlrpc-c-0:1.51.0-14.fc36.src
> xmlsec1-0:1.2.34-1.fc37.src
> xorg-x11-server-Xwayland-0:22.1.2-1.fc37.src
> xrdp-1:0.9.19-1.fc37.src
> zchunk-0:1.2.2-1.fc37.src

PyPy at least is self-hosting and can be built using an existing PyPy
installation instead of relying on CPython.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Jason Tibbitts

> Felix Schwarz  writes:

> imho removing the devel packages is basically the same as removing
> openssl1.1 entirely. To me the idea of "deprecation" is to warn users
> that something is going away WITHOUT removing functionality
> immediately.

I just wanted to note, since I haven't noticed it elsewhere in this
thread, that "deprecation" for a Fedora package has a specific meaning
as described in
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/

When a package is deprecated, the intent is that no new dependencies on
any deprecated package would appear in the distribution, either by new
packages or from existing packages adding dependencies.  Of course, I
don't know what actually checks this; it's not particularly common to
deprecate packages.

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Ben Beasley

I support deprecating openssl1.1. We definitely shouldn’t be adding any 
new packages that depend on it.


However, dropping the -devel package is almost as drastic as simply 
retiring the OpenSSL 1.1 package altogether. Grepping spec files for 
'BuildRequires:.*openssl1' turns up the following packages that would 
immediately FTBFS:


- anope
- baresip
- botan2
- ceph
- chatty
- dotnet3.1
- dsniff
- eggdrop
- erlang
- kf5-kdelibs4support
- libasr
- libqxt-qt5
- libre
- libretls
- lua-sec
- nginx
- nodejs
- opensmtpd
- partclone
- pypy3.8
- pypy
- python2.7
- python3.6
- python3.7
- python-uamqp
- qt
- radsecproxy
- rpki-client
- ssldump
- tcltls
- thc-ipv6
- unrealircd
- w3m
- znc

Some of these have pretty large trees of dependent packages. I don’t 
think we’re ready for all of these packages to go FTBFS, preventing them 
from rebuilding or providing updates, until somebody figures out how to 
port them to OpenSSL 3.0. In a lot of cases, the maintainers of these 
packages in Fedora won’t be able to develop the necessary patches alone, 
so dropping the -devel packages would be playing hardball with the wrong 
people.


I’m sympathetic to the importance of retaining momentum toward 
openssl1.1 retirement rather than letting the compatibility package 
linger indefinitely, but I think right now—nine months after OpenSSL 3.0 
was released—this momentum should be in the form of *assisting* these 
maintainers and upstreams in porting their packages, rather than in the 
form of forcing them to figure out an emergency patch.


In general, omitting -devel packages as an intermediate step between 
deprecation and retirement is not a practice I would like to see 
proliferate in Fedora. Packages that can be used but not built from 
source are defects in an open distribution, and we should avoid creating 
them intentionally.


– Ben Beasley

On 6/24/22 05:19, Daniel P. Berrangé wrote:

On Fri, Jun 24, 2022 at 11:13:13AM +0200, Dmitry Belyavskiy wrote:

On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok  wrote:


On 22. 06. 22 21:05, Vipul Siddharth wrote:

We are going to deprecate openssl1.1 package, stop shipping the
corresponding devel package, and stop respecting crypto policies in
openssl1.1 package itself.

+1 to deprecating it


Great!

-1 to stop shipping the devel package, this would mean we cannot build at

least:

- Python 2.7
despite our long term efforts, many things still need that, e.g. gimp,
firefox (some builds do, then some don't), thunderbird etc., see
https://fedora.portingdb.xyz/

Or Python 3.6 (shipped for developers targeting RHEL 7/8).

As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please
leave the
devel package?


I'm not sure that if we don't remove the devel package, we will provide
strong enough motivation to get rid of the deprecating packages.

If the openssl maintainers really strongly want to remove the
devel pacakge, then don't call this deprecation because that
is misleading. Call this purging openssl1.1 from the entire
distro, such that it can only be used by 3rd party apps who
have previously compiled against older Fedora openssl-devel.
Be open about fact that this will cause FTBFS for any Fedora
packages that stil uses openssl1 and their removal from the
distro if they can't port to openssl3 very quickly.

With 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: Where does "redhat-linux-build" come from?

2022-06-24 Thread Steven A. Falco


On 6/24/22 11:51 AM, Dan Horák wrote:

On Fri, 24 Jun 2022 11:36:18 -0400
"Steven A. Falco"  wrote:


I'm trying to debug a package that uses cmake to build "out of tree".  It looks like the 
build happens in a directory called "redhat-linux-build".  Is there a macro that contains 
that string?


[dan@talos linux]$ rpmbuild --eval %cmake

...
   /usr/bin/cmake \
 -S "." \
 -B "redhat-linux-build" \
 -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
 -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
 -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
 -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF \
 -DCMAKE_INSTALL_PREFIX:PATH=/usr \
 -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
 -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
 -DSYSCONF_INSTALL_DIR:PATH=/etc \
 -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
%if "lib64" == "lib64"
 -DLIB_SUFFIX=64 \
%endif
 -DBUILD_SHARED_LIBS:BOOL=ON


Perfect.  Thanks.

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On 24. 06. 22 17:39, Simo Sorce wrote:

Not forever, just until Python 2.7 is removed :D

Seriously thou, my proposal is:

- deprecate it now
- announce it goes away when RHEL 8 maintenance support ends

Following the guidelines for deprecated packages:
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/

# This is when RHEL 8 maintenance support is expected to end
#https://access.redhat.com/support/policy/updates/errata
# The life-cycle time spans and dates are subject to adjustment
Provides: deprecated() = 20290531

You are going to support OpenSSL 1.1 in RHEL 8 until that day anyway.

This is also when we plan to remove Python 3.6:
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/W74WYEVGYAE57KVLCG73I75LZYKKUMXS/

And if Python 2.7 isn't removed by then, we can rip it out together with
OpenSSL 1.1 in Fedora 50.

Are you going to maintain it till Fedora 50 in the meantime?

That is a very good question. No I won't. I am a member of a Red Hat team that
maintains Python in RHEL and Fedora Linux, including a very old legacy Python
version without upstream support. I merely expect the same treatment from the
OpenSSL maintainers who proposed this change proposal (I assumed they are the
RHEL OpenSSL maintainers, correct me if they are not).

I understand that I cannot *make* anybody maintain what they don't want. I am
merely suggesting a solution that I consider good for the distro. I believe the
RHEL OpenSSL maintainers who already need to maintain 1.1 at least until RHEL 8
goes EOL are much better equipped to maintain it in Fedora than I am.

But as said elsewhere, when it comes to that, we would be either forced to
bundle OpenSSL 1.1 (and well, maintain it) or to get rid of Python 2.

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Nico Kadel-Garcia

On Fri, Jun 24, 2022 at 5:14 AM Dmitry Belyavskiy  wrote:
>
>
>
> On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok  wrote:
>>
>> On 22. 06. 22 21:05, Vipul Siddharth wrote:
>> > We are going to deprecate openssl1.1 package, stop shipping the
>> > corresponding devel package, and stop respecting crypto policies in
>> > openssl1.1 package itself.
>>
>> +1 to deprecating it
>
>
> Great!

Please don't stop shipping the devel package while still shipping the
old library package. RHEL has been doing that with python3-ldb-devel,
and python3-talloc-devel, and used to do that with lmdb-devel, and
it's been... infuriating, especially since Red Hat and CentOS kept
them around for internal use in their build environments, they just
neglected to include them in the published operating. It wasn't
*exactly* a GPL violation, since they continued to provide SRPMs, but
it was quite irksome.
___
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: [Container-sig] About Fedora containers

2022-06-24 Thread Blaise Pabon

Sorry, I read this as becoming dependent on GitHub actions for CI and for
CD.

On Thu, Jun 23, 2022, 4:24 PM Maxwell G via devel <
devel@lists.fedoraproject.org> wrote:

> On Thursday, June 23, 2022 1:50:09 PM CDT Kevin Fenzi wrote:
> > Not sure what github has to do with things here?
>
> Lumír said:
>
> > With quay.io, we are able to produce new container images directly from
> > Github CI and rebuild them regularly without complicated update process
> > and without any need to maintain sources for in the dedicated dist git.
>
> However, it doesn't sound to me like Github Actions is related to this
> proposal; that's just how the Python SIG happens to publish their
> container
> images to quay.io.
>
> --
> Thanks,
>
> Maxwell G (@gotmax23)
> Pronouns: He/Him/His___
> 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: Where does "redhat-linux-build" come from?

2022-06-24 Thread Dan Horák

On Fri, 24 Jun 2022 11:36:18 -0400
"Steven A. Falco"  wrote:

> I'm trying to debug a package that uses cmake to build "out of tree".  It 
> looks like the build happens in a directory called "redhat-linux-build".  Is 
> there a macro that contains that string?

[dan@talos linux]$ rpmbuild --eval %cmake

...
  /usr/bin/cmake \
-S "." \
-B "redhat-linux-build" \
-DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
-DCMAKE_INSTALL_DO_STRIP:BOOL=OFF \
-DCMAKE_INSTALL_PREFIX:PATH=/usr \
-DINCLUDE_INSTALL_DIR:PATH=/usr/include \
-DLIB_INSTALL_DIR:PATH=/usr/lib64 \
-DSYSCONF_INSTALL_DIR:PATH=/etc \
-DSHARE_INSTALL_PREFIX:PATH=/usr/share \
%if "lib64" == "lib64" 
-DLIB_SUFFIX=64 \
%endif 
-DBUILD_SHARED_LIBS:BOOL=ON
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Simo Sorce

On Fri, 2022-06-24 at 11:42 +0200, Miro Hrončok wrote:
> On 24. 06. 22 11:23, Dmitry Belyavskiy wrote:
> > 
> > 
> > On Fri, Jun 24, 2022 at 11:20 AM Daniel P. Berrangé  > > wrote:
> > 
> > On Fri, Jun 24, 2022 at 11:13:13AM +0200, Dmitry Belyavskiy wrote:
> >  > On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok  > > wrote:
> >  >
> >  > > On 22. 06. 22 21:05, Vipul Siddharth wrote:
> >  > > > We are going to deprecate openssl1.1 package, stop shipping the
> >  > > > corresponding devel package, and stop respecting crypto policies 
> > in
> >  > > > openssl1.1 package itself.
> >  > >
> >  > > +1 to deprecating it
> >  > >
> >  >
> >  > Great!
> >  >
> >  > -1 to stop shipping the devel package, this would mean we cannot 
> > build at
> >  > > least:
> >  > >
> >  > > - Python 2.7
> >  > >    despite our long term efforts, many things still need that, 
> > e.g. gimp,
> >  > > firefox (some builds do, then some don't), thunderbird etc., see
> >  > > https://fedora.portingdb.xyz/ 
> >  > >
> >  > > Or Python 3.6 (shipped for developers targeting RHEL 7/8).
> >  > >
> >  > > As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we 
> > please
> >  > > leave the
> >  > > devel package?
> >  > >
> >  >
> >  > I'm not sure that if we don't remove the devel package, we will 
> > provide
> >  > strong enough motivation to get rid of the deprecating packages.
> > 
> > If the openssl maintainers really strongly want to remove the
> > devel pacakge, then don't call this deprecation because that
> > is misleading. Call this purging openssl1.1 from the entire
> > distro, such that it can only be used by 3rd party apps who
> > have previously compiled against older Fedora openssl-devel.
> > Be open about fact that this will cause FTBFS for any Fedora
> > packages that stil uses openssl1 and their removal from the
> > distro if they can't port to openssl3 very quickly.
> > 
> > Do I correctly understand that the situation with Python is the most 
> > problematic?
> > Are we able to solve it somehow?
> > 
> > What I'm afraid of is that if we just declare the deprecation, we will stay 
> > with this package forever.
> 
> Not forever, just until Python 2.7 is removed :D
> 
> Seriously thou, my proposal is:
> 
>   - deprecate it now
>   - announce it goes away when RHEL 8 maintenance support ends
> 
> Following the guidelines for deprecated packages:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
> 
># This is when RHEL 8 maintenance support is expected to end
># https://access.redhat.com/support/policy/updates/errata
># The life-cycle time spans and dates are subject to adjustment
>Provides: deprecated() = 20290531
> 
> You are going to support OpenSSL 1.1 in RHEL 8 until that day anyway.
> 
> This is also when we plan to remove Python 3.6:
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/W74WYEVGYAE57KVLCG73I75LZYKKUMXS/
> 
> And if Python 2.7 isn't removed by then, we can rip it out together with 
> OpenSSL 1.1 in Fedora 50.
> 

Are you going to maintain it till Fedora 50 in the meantime?

Simo.

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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, 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

Where does "redhat-linux-build" come from?

2022-06-24 Thread Steven A. Falco


I'm trying to debug a package that uses cmake to build "out of tree".  It looks like the 
build happens in a directory called "redhat-linux-build".  Is there a macro that contains 
that string?

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

[Reminder] CfP open for Nest with Fedora

2022-06-24 Thread Marie Nordin

Hi there Fedorans,

It's time to submit your proposals for Nest with Fedora! The event will be
held virtually on August 4th, 5th, and 6th. This is a great opportunity to
share what you have been doing in the project and connect with your fellow
Fedorans :)

*The final deadline for the CfP is July 8th. *

*Submit your proposals on the Flock pagure repo:*
https://pagure.io/flock/issues

*More info about the CfP:*
https://communityblog.fedoraproject.org/nest-2022-cfp/

*More info about Nest: *
https://communityblog.fedoraproject.org/nest-with-fedora-fedora-hatch-announcing-dates-call-for-volunteers/

Can't wait to see your proposals!
Best,

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

IRC/Element: riecatnor



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

[Reminder] CfP open for Nest with Fedora

2022-06-24 Thread Marie Nordin

Hi there Fedorans,

It's time to submit your proposals for Nest with Fedora! The event will be
held virtually on August 4th, 5th, and 6th. This is a great opportunity to
share what you have been doing in the project and connect with your fellow
Fedorans :)

*The final deadline for the CfP is July 8th. *

*Submit your proposals on the Flock pagure repo:*
https://pagure.io/flock/issues

*More info about the CfP:*
https://communityblog.fedoraproject.org/nest-2022-cfp/

*More info about Nest: *
https://communityblog.fedoraproject.org/nest-with-fedora-fedora-hatch-announcing-dates-call-for-volunteers/

Can't wait to see your proposals!
Best,

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

IRC/Element: riecatnor



___
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

Re: Help needed: Where's the error?

* Miro Hrončok:

> On 24. 06. 22 16:30, Florian Weimer wrote:
>> * Miro Hrončok:
>> 
>>> Hello.
>>>
>>> Could you help me find the error in the build.log?
>>>
>>> Here in this PR's CI build:
>>>
>>> https://src.fedoraproject.org/rpms/python-pyside2/pull-request/9
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=88664870
>>>
>>> Anything but ppc64le.
>>>
>>> The build ends with:
>>>
>>> gmake[2]: Leaving directory
>>> '/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
>>> [ 48%] Built target QtGui
>>> gmake[1]: Leaving directory
>>> '/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
>>> gmake: *** [Makefile:139: all] Error 2
>>> RPM build errors:
>>> error: Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
>>>  Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
>>>
>>> But why? Where is the error?
>> It's here:
>> INFO:generate_pyi:Generated:
>> /builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build/sources/pyside2/PySide2/QtCore.pyi
>> free(): invalid pointer
>> gmake[2]: Leaving directory 
>> '/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
>> Subprocess aborted
>> gmake[2]: *** 
>> [sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi.dir/build.make:73: 
>> sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi] Error 1
>> As a rule of thumb, if you see an “Error 2” line from make, look for
>> an
>> “Error 1” line preceding it.
>
> Thanks. I was searching mostly for "error:" and could not find anything.

It also helps to invoke make with -O if building with -jN, which for
some reason does not happen for this build.

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

Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

2022-06-24 Thread Tom Stellard


On 6/24/22 01:32, Florian Weimer wrote:

* Tom Stellard:


On 6/7/22 02:18, Florian Weimer wrote:

* Ben Cotton:


This change will add new macros which will make it easier for packages
to add and remove their own compiler flags.  This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.

The proposed macros for adding new flags are:

  %_pkg_extra_cflags
  %_pkg_extra_cxxflags
  %_pkg_extra_fflags
  %_pkg_extra_ldflags

Why isn't it possible to use the environment variables for this?



Environment variables won't cover all cases.  For example, some packages
need the flags passed as arguments to make or configure or some other
build system.


But then you can stick the extra flags into that argument.  I don't see
why this additional hook is needed.


This is very misleading because in several cases, clearing the those
flags will not affect toolchain behavior because the flag in question
merely restates the toolchain default.  In particular, this applies to
-fasynchronous-unwind-tables, and it would apply to -march= and -mcpu=
if those were in the list.  Likewise to -Wl,-z,relro.
Is the goal of this proposal just to achieve a textual flags change
(disregarding any change in behavior), or to actually change toolchain



The goal is to make it easy to remove individual flags so packages can
get the toolchain behavior they want.


Sorry, this does not answer my question.  What if removing the flag does
not actually change toolchain behavior?



This was not something I had considered.  We could update the macro so
that if a macro was set to %{nil} then the flag to turn off the feature
is used so something like:

%build_cflags %[ "%{_flag_asynchronous_unwind_tables}" == "" ? 
"-fno-asynchronous-unwind-tables" : "%{_flag_asynchronous_unwind_tables}"] ...


Or we could just leave it as is and document that the default complier
behavior takes precedence over compiler flags.  The proposed change doesn't 
actually
make the problem worse, because the current method for removing compiler flags
has the same problem: e.g.

%global optflags %(echo %{optflags} | sed 's/-fasynchronous-unwind-tables//

will remove the flag but not change the behavior.

- Tom


If the former, I'm not sure if the actual _flag names are useful.  Maybe
we can add an RPM macro to suppress or replace flags based on the flags
as they are used instead.  This could also add additional error checking
because a name typo in the macro definition will not be immediately
obvious.



Can you give an example of what you mean by this?


You could write:

%build_cxxflags_remove -Wp,-D_GLIBCXX_ASSERTIONS

or some similar construct, and -Wp,-D_GLIBCXX_ASSERTIONS would be
removed from the build flags.


With these new macros, the examples from above could be re-written as:

  compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
  julia:   %global _flag_glibcxx_assertions %{nil}

Do you have some background why -D_DEFAULT_SOURCE is needed?  Why
doesn't upstream detect this?



It was added to workaround this bug: 
https://sourceware.org/bugzilla/show_bug.cgi?id=25271


This has long since been fixed, so the workaround is no longer needed.

-D_GLIBCXX_ASSERTIONS has zero false positives.  Removing it does not
make the code that triggers the asserts well-defined.  Only the explicit
assertion failure is gone.  So it is probably another example of a flag
where removal does not result in the hoped-for change in toolchain
behavior.

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

[Bug 2100791] Add perl-Perl4-CoreLibs to EPEL9

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Michal Josef Spacek  ---
Branch requested: https://pagure.io/releng/fedora-scm-requests/issue/45222


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


On 24. 06. 22 16:30, Florian Weimer wrote:

* Miro Hrončok:


Hello.

Could you help me find the error in the build.log?

Here in this PR's CI build:

https://src.fedoraproject.org/rpms/python-pyside2/pull-request/9
https://koji.fedoraproject.org/koji/taskinfo?taskID=88664870

Anything but ppc64le.

The build ends with:

gmake[2]: Leaving directory
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
[ 48%] Built target QtGui
gmake[1]: Leaving directory
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
gmake: *** [Makefile:139: all] Error 2
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
 Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)

But why? Where is the error?


It's here:

INFO:generate_pyi:Generated: 
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build/sources/pyside2/PySide2/QtCore.pyi
free(): invalid pointer
gmake[2]: Leaving directory 
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
Subprocess aborted
gmake[2]: *** 
[sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi.dir/build.make:73: 
sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi] Error 1

As a rule of thumb, if you see an “Error 2” line from make, look for an
“Error 1” line preceding it.


Thanks. I was searching mostly for "error:" and could not find anything.

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

Re: Help needed: Where's the error?

* Miro Hrončok:

> Hello.
>
> Could you help me find the error in the build.log?
>
> Here in this PR's CI build:
>
> https://src.fedoraproject.org/rpms/python-pyside2/pull-request/9
> https://koji.fedoraproject.org/koji/taskinfo?taskID=88664870
>
> Anything but ppc64le.
>
> The build ends with:
>
> gmake[2]: Leaving directory
> '/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
> [ 48%] Built target QtGui
> gmake[1]: Leaving directory
> '/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
> gmake: *** [Makefile:139: all] Error 2
> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
> Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
>
> But why? Where is the error?

It's here:

INFO:generate_pyi:Generated: 
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build/sources/pyside2/PySide2/QtCore.pyi
free(): invalid pointer
gmake[2]: Leaving directory 
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
Subprocess aborted
gmake[2]: *** 
[sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi.dir/build.make:73: 
sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi] Error 1

As a rule of thumb, if you see an “Error 2” line from make, look for an
“Error 1” line preceding it.

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

Re: Help needed: Where's the error?


On 24. 06. 22 16:14, Daniel P. Berrangé wrote:

On Fri, Jun 24, 2022 at 04:06:05PM +0200, Miro Hrončok wrote:

Hello.

Could you help me find the error in the build.log?

Here in this PR's CI build:

https://src.fedoraproject.org/rpms/python-pyside2/pull-request/9
https://koji.fedoraproject.org/koji/taskinfo?taskID=88664870

Anything but ppc64le.

The build ends with:

gmake[2]: Leaving directory
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
[ 48%] Built target QtGui
gmake[1]: Leaving directory
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
gmake: *** [Makefile:139: all] Error 2
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
 Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)

But why? Where is the error?


It is much earlier in the logfile

INFO:generate_pyi:Generated: 
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build/sources/pyside2/PySide2/QtCore.pyi
free(): invalid pointer
gmake[2]: Leaving directory 
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
Subprocess aborted
gmake[2]: *** 
[sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi.dir/build.make:73: 
sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:4978: 
sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs


To find it, 'grep gmake build.log' to cull all the compiler command
lines that obscure it.


Awesome, thank you!

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

Re: Help needed: Where's the error?

2022-06-24 Thread Daniel P . Berrangé

On Fri, Jun 24, 2022 at 04:06:05PM +0200, Miro Hrončok wrote:
> Hello.
> 
> Could you help me find the error in the build.log?
> 
> Here in this PR's CI build:
> 
> https://src.fedoraproject.org/rpms/python-pyside2/pull-request/9
> https://koji.fedoraproject.org/koji/taskinfo?taskID=88664870
> 
> Anything but ppc64le.
> 
> The build ends with:
> 
> gmake[2]: Leaving directory
> '/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
> [ 48%] Built target QtGui
> gmake[1]: Leaving directory
> '/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
> gmake: *** [Makefile:139: all] Error 2
> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
> Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
> 
> But why? Where is the error?

It is much earlier in the logfile

INFO:generate_pyi:Generated: 
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build/sources/pyside2/PySide2/QtCore.pyi
free(): invalid pointer
gmake[2]: Leaving directory 
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'
Subprocess aborted
gmake[2]: *** 
[sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi.dir/build.make:73: 
sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:4978: 
sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_pyi.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs


To find it, 'grep gmake build.log' to cull all the compiler command
lines that obscure it.

With 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

Help needed: Where's the error?


Hello.

Could you help me find the error in the build.log?

Here in this PR's CI build:

https://src.fedoraproject.org/rpms/python-pyside2/pull-request/9
https://koji.fedoraproject.org/koji/taskinfo?taskID=88664870

Anything but ppc64le.

The build ends with:

gmake[2]: Leaving directory 
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'

[ 48%] Built target QtGui
gmake[1]: Leaving directory 
'/builddir/build/BUILD/pyside-setup-opensource-src-5.15.2/redhat-linux-build'

gmake: *** [Makefile:139: all] Error 2
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)
Bad exit status from /var/tmp/rpm-tmp.8E2Rni (%build)

But why? Where is the error?

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

[rpms/slic3r] PR #10: Do not BuildRequire non-existing boost-nowide-devel


churchyard merged a pull-request against the project: `slic3r` that you are 
following.

Merged pull-request:

``
Do not BuildRequire non-existing boost-nowide-devel
``

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Daniel P . Berrangé

On Fri, Jun 24, 2022 at 02:06:14PM +0200, Tomáš Orsava wrote:
> Hi Richard,
> porting Python 2.7 to openssl 3.0 doesn't really make sense to me.
> 
> We ship Python 2.7 so that developers can test code that needs to work on
> Python 2.7 in various deployments like old CentOS/RHEL/etc. Fedora aims to
> be a developer-friendly distro and so we want to provide the tools to do
> that. Even if it's possible to port Python 2.7 to openssl 3.0 safely with
> reasonable effort, which I doubt, it would lead to a different Python 2.7,
> which would no longer work as a testing ground for people developing for old
> deployments.

IMHO that's not a very compelling use case. Python 2.7 on Fedora
is already quite different from RHEL in terms of crypto, simply by
virtue of Fedora having quite different crypto-policies applied.

If people want to test compatibility with older RHEL/CentOS from
their Fedora dev machine, then containers are the answer and will
give much higher confidence level. Containers already dominate in
cases where people want to test software against different OS,
without having the burden of maintaining a full VM.

With 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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Tomáš Orsava


Hi Richard,
porting Python 2.7 to openssl 3.0 doesn't really make sense to me.

We ship Python 2.7 so that developers can test code that needs to work 
on Python 2.7 in various deployments like old CentOS/RHEL/etc. Fedora 
aims to be a developer-friendly distro and so we want to provide the 
tools to do that. Even if it's possible to port Python 2.7 to openssl 
3.0 safely with reasonable effort, which I doubt, it would lead to a 
different Python 2.7, which would no longer work as a testing ground for 
people developing for old deployments.


Tomáš

On 6/24/22 13:11, Richard W.M. Jones wrote:

On Thu, Jun 23, 2022 at 10:43:45AM +0100, Richard W.M. Jones wrote:

python2.7-0:2.7.18-22.fc37.src

Vaguely seeing if it's feasible to backport the OpenSSL 3 support to
Python 2.7.  This branch gets quite far:

https://github.com/rwmjones/cpython/tree/python-2.7-openssl-3

Only one test fails, test_ssl (obviously), but it does only appear to
fail where it tests obsolete ciphers.  I looked into fixing the test,
but the upstream version of this test has changed a great deal, with a
whole mechanism for skipping unsupported ciphers.

Remaining test failures in detail below.

Rich.

--

running build
running build_ext
warning: openssl 0x is too old for _hashlib
building dbm using ndbm

Python build finished, but the necessary bits to build these modules were not 
found:
_hashlib   bsddb185   dl
imageopsunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.

running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -v test_ssl
== CPython 2.7.18 (tags/2.7-3-g1efbb6fd52:1efbb6fd52, Jun 24 2022, 12:05:45) 
[GCC 12.1.1 20220507 (Red Hat 12.1.1-1)]
==   
Linux-5.14.0-0.rc4.20210804gitd5ad8ec3cfb5.36.fc35.x86_64-x86_64-with-fedora-37-Rawhide
 little-endian
==   /home/rjones/d/cpython-2.7/build/test_python_641493
== CPU count: 24
Run tests sequentially
0:00:00 load avg: 0.09 [1/1] test_ssl
test_ssl: testing with 'OpenSSL 3.0.3 3 May 2022' (3, 0, 0, 3, 0)
   under Linux ('Fedora', '37', 'Rawhide')
   HAS_SNI = True
   OP_ALL = 0x8050
   OP_NO_TLSv1_1 = 0x1000
test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
test__https_verify_certificates (test.test_ssl.ContextTests) ... ok
test__https_verify_envvar (test.test_ssl.ContextTests) ... ok
test_cert_store_stats (test.test_ssl.ContextTests) ... ok
test_check_hostname (test.test_ssl.ContextTests) ... ok
test_ciphers (test.test_ssl.ContextTests) ... ok
test_constructor (test.test_ssl.ContextTests) ... ok
test_create_default_context (test.test_ssl.ContextTests) ... ok
test_get_ca_certs (test.test_ssl.ContextTests) ... ok
test_load_cert_chain (test.test_ssl.ContextTests) ... ok
test_load_default_certs (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env_windows (test.test_ssl.ContextTests) ... skipped 
'Windows specific'
test_load_dh_params (test.test_ssl.ContextTests) ... ok
test_load_verify_cadata (test.test_ssl.ContextTests) ... ERROR
test_load_verify_locations (test.test_ssl.ContextTests) ... ok
test_options (test.test_ssl.ContextTests) ... ok
test_protocol (test.test_ssl.ContextTests) ... ok
test_session_stats (test.test_ssl.ContextTests) ... ok
test_set_default_verify_paths (test.test_ssl.ContextTests) ... ok
test_set_ecdh_curve (test.test_ssl.ContextTests) ... ok
test_sni_callback (test.test_ssl.ContextTests) ... ok
test_sni_callback_refcycle (test.test_ssl.ContextTests) ... ok
test_verify_flags (test.test_ssl.ContextTests) ... ok
test_verify_mode (test.test_ssl.ContextTests) ... ok
test_sslwrap_simple (test.test_ssl.BasicTests) ... ok
test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok
test_asn1object (test.test_ssl.BasicSocketTests) ... ok
test_cert_time_to_seconds (test.test_ssl.BasicSocketTests) ... ok
test_cert_time_to_seconds_locale (test.test_ssl.BasicSocketTests) ... skipped 
'locale-specific month name needs to be different from C locale'
test_cert_time_to_seconds_timezone (test.test_ssl.BasicSocketTests) ... ok
test_constants (test.test_ssl.BasicSocketTests) ... ok
test_empty_cert (test.test_ssl.BasicSocketTests)
Wrapping with an empty cert file ... ok
test_enum_certificates (test.test_ssl.BasicSocketTests) ... skipped 'Windows 
specific'
test_enum_crls (test.test_ssl.BasicSocketTests) ... skipped 'Windows specific'
test_errors (test.test_ssl.BasicSocketTests) ... ok
test_get_default_verify_paths (test.test_ssl.BasicSocketTests) ... ok
test_malformed_cert (test.test_ssl.BasicSocketTests)
Wrapping with a badly formatted certificate (syntax error) ... ok
test_malformed_key (test.test_ssl.BasicSocketTests)
Wrapping with a badly formatted key (syntax error) ... ok
test_match_hostname (test.test_ssl.BasicSocketTests) ... ok

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Richard W.M. Jones

On Fri, Jun 24, 2022 at 01:37:16PM +0200, Miro Hrončok wrote:
> On 24. 06. 22 13:11, Richard W.M. Jones wrote:
> >On Thu, Jun 23, 2022 at 10:43:45AM +0100, Richard W.M. Jones wrote:
> >>python2.7-0:2.7.18-22.fc37.src
> >
> >Vaguely seeing if it's feasible to backport the OpenSSL 3 support to
> >Python 2.7.  This branch gets quite far:
> >
> >https://github.com/rwmjones/cpython/tree/python-2.7-openssl-3
> >
> >Only one test fails, test_ssl (obviously), but it does only appear to
> >fail where it tests obsolete ciphers.  I looked into fixing the test,
> >but the upstream version of this test has changed a great deal, with a
> >whole mechanism for skipping unsupported ciphers.
> 
> Richard, have you seen the list of PRs and dependencies in
> https://github.com/python/cpython/issues/83001 ?

I did!  It was very long so I went with cherry picking patches and
hoping for the best, with mixed results ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)


On 24. 06. 22 13:11, Richard W.M. Jones wrote:

On Thu, Jun 23, 2022 at 10:43:45AM +0100, Richard W.M. Jones wrote:

python2.7-0:2.7.18-22.fc37.src


Vaguely seeing if it's feasible to backport the OpenSSL 3 support to
Python 2.7.  This branch gets quite far:

https://github.com/rwmjones/cpython/tree/python-2.7-openssl-3

Only one test fails, test_ssl (obviously), but it does only appear to
fail where it tests obsolete ciphers.  I looked into fixing the test,
but the upstream version of this test has changed a great deal, with a
whole mechanism for skipping unsupported ciphers.


Richard, have you seen the list of PRs and dependencies in 
https://github.com/python/cpython/issues/83001 ?


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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Dmitry Belyavskiy

Dear Richard,

If the only problem is legacy (and unsafe) ciphersuites, loading the legacy
provider will solve this problem.

On Fri, Jun 24, 2022 at 1:11 PM Richard W.M. Jones 
wrote:

> On Thu, Jun 23, 2022 at 10:43:45AM +0100, Richard W.M. Jones wrote:
> > python2.7-0:2.7.18-22.fc37.src
>
> Vaguely seeing if it's feasible to backport the OpenSSL 3 support to
> Python 2.7.  This branch gets quite far:
>
> https://github.com/rwmjones/cpython/tree/python-2.7-openssl-3
>
> Only one test fails, test_ssl (obviously), but it does only appear to
> fail where it tests obsolete ciphers.  I looked into fixing the test,
> but the upstream version of this test has changed a great deal, with a
> whole mechanism for skipping unsupported ciphers.
>
> Remaining test failures in detail below.
>
> Rich.
>
> --
>
> running build
> running build_ext
> warning: openssl 0x is too old for _hashlib
> building dbm using ndbm
>
> Python build finished, but the necessary bits to build these modules were
> not found:
> _hashlib   bsddb185   dl
> imageopsunaudiodev
> To find the necessary bits, look in setup.py in detect_modules() for the
> module's name.
>
> running build_scripts
> find ./Lib -name '*.py[co]' -print | xargs rm -f
> ./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -v test_ssl
> == CPython 2.7.18 (tags/2.7-3-g1efbb6fd52:1efbb6fd52, Jun 24 2022,
> 12:05:45) [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)]
> ==
>  
> Linux-5.14.0-0.rc4.20210804gitd5ad8ec3cfb5.36.fc35.x86_64-x86_64-with-fedora-37-Rawhide
> little-endian
> ==   /home/rjones/d/cpython-2.7/build/test_python_641493
> == CPU count: 24
> Run tests sequentially
> 0:00:00 load avg: 0.09 [1/1] test_ssl
> test_ssl: testing with 'OpenSSL 3.0.3 3 May 2022' (3, 0, 0, 3, 0)
>   under Linux ('Fedora', '37', 'Rawhide')
>   HAS_SNI = True
>   OP_ALL = 0x8050
>   OP_NO_TLSv1_1 = 0x1000
> test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
> test__https_verify_certificates (test.test_ssl.ContextTests) ... ok
> test__https_verify_envvar (test.test_ssl.ContextTests) ... ok
> test_cert_store_stats (test.test_ssl.ContextTests) ... ok
> test_check_hostname (test.test_ssl.ContextTests) ... ok
> test_ciphers (test.test_ssl.ContextTests) ... ok
> test_constructor (test.test_ssl.ContextTests) ... ok
> test_create_default_context (test.test_ssl.ContextTests) ... ok
> test_get_ca_certs (test.test_ssl.ContextTests) ... ok
> test_load_cert_chain (test.test_ssl.ContextTests) ... ok
> test_load_default_certs (test.test_ssl.ContextTests) ... ok
> test_load_default_certs_env (test.test_ssl.ContextTests) ... ok
> test_load_default_certs_env_windows (test.test_ssl.ContextTests) ...
> skipped 'Windows specific'
> test_load_dh_params (test.test_ssl.ContextTests) ... ok
> test_load_verify_cadata (test.test_ssl.ContextTests) ... ERROR
> test_load_verify_locations (test.test_ssl.ContextTests) ... ok
> test_options (test.test_ssl.ContextTests) ... ok
> test_protocol (test.test_ssl.ContextTests) ... ok
> test_session_stats (test.test_ssl.ContextTests) ... ok
> test_set_default_verify_paths (test.test_ssl.ContextTests) ... ok
> test_set_ecdh_curve (test.test_ssl.ContextTests) ... ok
> test_sni_callback (test.test_ssl.ContextTests) ... ok
> test_sni_callback_refcycle (test.test_ssl.ContextTests) ... ok
> test_verify_flags (test.test_ssl.ContextTests) ... ok
> test_verify_mode (test.test_ssl.ContextTests) ... ok
> test_sslwrap_simple (test.test_ssl.BasicTests) ... ok
> test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok
> test_asn1object (test.test_ssl.BasicSocketTests) ... ok
> test_cert_time_to_seconds (test.test_ssl.BasicSocketTests) ... ok
> test_cert_time_to_seconds_locale (test.test_ssl.BasicSocketTests) ...
> skipped 'locale-specific month name needs to be different from C locale'
> test_cert_time_to_seconds_timezone (test.test_ssl.BasicSocketTests) ... ok
> test_constants (test.test_ssl.BasicSocketTests) ... ok
> test_empty_cert (test.test_ssl.BasicSocketTests)
> Wrapping with an empty cert file ... ok
> test_enum_certificates (test.test_ssl.BasicSocketTests) ... skipped
> 'Windows specific'
> test_enum_crls (test.test_ssl.BasicSocketTests) ... skipped 'Windows
> specific'
> test_errors (test.test_ssl.BasicSocketTests) ... ok
> test_get_default_verify_paths (test.test_ssl.BasicSocketTests) ... ok
> test_malformed_cert (test.test_ssl.BasicSocketTests)
> Wrapping with a badly formatted certificate (syntax error) ... ok
> test_malformed_key (test.test_ssl.BasicSocketTests)
> Wrapping with a badly formatted key (syntax error) ... ok
> test_match_hostname (test.test_ssl.BasicSocketTests) ... ok
> test_openssl_version (test.test_ssl.BasicSocketTests) ... FAIL
> test_parse_all_sans (test.test_ssl.BasicSocketTests) ... ok
> test_parse_cert (test.test_ssl.BasicSocketTests) ...
> {'issuer': ((('countryName', u'XY'),),
> (('localityName',

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Richard W.M. Jones

On Thu, Jun 23, 2022 at 10:43:45AM +0100, Richard W.M. Jones wrote:
> python2.7-0:2.7.18-22.fc37.src

Vaguely seeing if it's feasible to backport the OpenSSL 3 support to
Python 2.7.  This branch gets quite far:

https://github.com/rwmjones/cpython/tree/python-2.7-openssl-3

Only one test fails, test_ssl (obviously), but it does only appear to
fail where it tests obsolete ciphers.  I looked into fixing the test,
but the upstream version of this test has changed a great deal, with a
whole mechanism for skipping unsupported ciphers.

Remaining test failures in detail below.

Rich.

--

running build
running build_ext
warning: openssl 0x is too old for _hashlib
building dbm using ndbm

Python build finished, but the necessary bits to build these modules were not 
found:
_hashlib   bsddb185   dl  
imageopsunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.

running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -v test_ssl
== CPython 2.7.18 (tags/2.7-3-g1efbb6fd52:1efbb6fd52, Jun 24 2022, 12:05:45) 
[GCC 12.1.1 20220507 (Red Hat 12.1.1-1)]
==   
Linux-5.14.0-0.rc4.20210804gitd5ad8ec3cfb5.36.fc35.x86_64-x86_64-with-fedora-37-Rawhide
 little-endian
==   /home/rjones/d/cpython-2.7/build/test_python_641493
== CPU count: 24
Run tests sequentially
0:00:00 load avg: 0.09 [1/1] test_ssl
test_ssl: testing with 'OpenSSL 3.0.3 3 May 2022' (3, 0, 0, 3, 0)
  under Linux ('Fedora', '37', 'Rawhide')
  HAS_SNI = True
  OP_ALL = 0x8050
  OP_NO_TLSv1_1 = 0x1000
test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
test__https_verify_certificates (test.test_ssl.ContextTests) ... ok
test__https_verify_envvar (test.test_ssl.ContextTests) ... ok
test_cert_store_stats (test.test_ssl.ContextTests) ... ok
test_check_hostname (test.test_ssl.ContextTests) ... ok
test_ciphers (test.test_ssl.ContextTests) ... ok
test_constructor (test.test_ssl.ContextTests) ... ok
test_create_default_context (test.test_ssl.ContextTests) ... ok
test_get_ca_certs (test.test_ssl.ContextTests) ... ok
test_load_cert_chain (test.test_ssl.ContextTests) ... ok
test_load_default_certs (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env_windows (test.test_ssl.ContextTests) ... skipped 
'Windows specific'
test_load_dh_params (test.test_ssl.ContextTests) ... ok
test_load_verify_cadata (test.test_ssl.ContextTests) ... ERROR
test_load_verify_locations (test.test_ssl.ContextTests) ... ok
test_options (test.test_ssl.ContextTests) ... ok
test_protocol (test.test_ssl.ContextTests) ... ok
test_session_stats (test.test_ssl.ContextTests) ... ok
test_set_default_verify_paths (test.test_ssl.ContextTests) ... ok
test_set_ecdh_curve (test.test_ssl.ContextTests) ... ok
test_sni_callback (test.test_ssl.ContextTests) ... ok
test_sni_callback_refcycle (test.test_ssl.ContextTests) ... ok
test_verify_flags (test.test_ssl.ContextTests) ... ok
test_verify_mode (test.test_ssl.ContextTests) ... ok
test_sslwrap_simple (test.test_ssl.BasicTests) ... ok
test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok
test_asn1object (test.test_ssl.BasicSocketTests) ... ok
test_cert_time_to_seconds (test.test_ssl.BasicSocketTests) ... ok
test_cert_time_to_seconds_locale (test.test_ssl.BasicSocketTests) ... skipped 
'locale-specific month name needs to be different from C locale'
test_cert_time_to_seconds_timezone (test.test_ssl.BasicSocketTests) ... ok
test_constants (test.test_ssl.BasicSocketTests) ... ok
test_empty_cert (test.test_ssl.BasicSocketTests)
Wrapping with an empty cert file ... ok
test_enum_certificates (test.test_ssl.BasicSocketTests) ... skipped 'Windows 
specific'
test_enum_crls (test.test_ssl.BasicSocketTests) ... skipped 'Windows specific'
test_errors (test.test_ssl.BasicSocketTests) ... ok
test_get_default_verify_paths (test.test_ssl.BasicSocketTests) ... ok
test_malformed_cert (test.test_ssl.BasicSocketTests)
Wrapping with a badly formatted certificate (syntax error) ... ok
test_malformed_key (test.test_ssl.BasicSocketTests)
Wrapping with a badly formatted key (syntax error) ... ok
test_match_hostname (test.test_ssl.BasicSocketTests) ... ok
test_openssl_version (test.test_ssl.BasicSocketTests) ... FAIL
test_parse_all_sans (test.test_ssl.BasicSocketTests) ... ok
test_parse_cert (test.test_ssl.BasicSocketTests) ... 
{'issuer': ((('countryName', u'XY'),),
(('localityName', u'Castle Anthrax'),),
(('organizationName', u'Python Software Foundation'),),
(('commonName', u'localhost'),)),
 'notAfter': 'Aug 26 14:23:15 2028 GMT',
 'notBefore': u'Aug 29 14:23:15 2018 GMT',
 'serialNumber': u'98A7CF88C74A32ED',
 'subject': ((('countryName', u'XY'),),
 (('localityName',

CPE Weekly Update – Week 25 2022

2022-06-24 Thread Akashdeep Dhar

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
If you have any questions or feedback, please respond to this report or
contact us on #redhat-cpe channel on libera.chat (https://libera.chat/).

Week: 20th - 24th June 2022

If you wish to read this in form of a blog post, check the post on the
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update-week-25-2022/
Highlights of the week Infrastructure & Release Engineering Goal of this
Initiative

The purpose of this team is to take care of day-to-day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure
and preparing things for the new Fedora release (mirrors, mass branching,
new namespaces etc.).
The ARC (which is a subset of the team) investigates possible initiatives
that CPE might take on.
Link to planning board: https://zlopez.fedorapeople.org/I
Link to docs: https://docs.fedoraproject.org/en-US/infra/
Update Fedora Infra

   - Most apps have moved over to the OpenShift4 cluster. Hopefully, the
   transition should be finishing up this week.
   - Wiki: All upgraded in production and working (thanks Ryan!)
   - Resultsdb: All moved over to OpenShift 4 in prod and working (thanks
   Leo!)
   - Business proceeding as usual

CentOS Infra including CentOS CI

   - Kerberos settings switch for git.centos.org (kcm on el8 vs keyring on
   el7) for lookaside upload CGI 
   [1]
   - Issue on iad2 hosted reference mirror
   [2] (epel.next and
   mirrormanager), all fixed now
   - Duffy CI ongoing tasks and deployments (all announced)
   - Equinix nodes migration [3]
   (on their request)
   - Business proceeding as usual

Release Engineering

   - Compose-tracker updated to f36 in staging, production happening
   tomorrow
   - Python 3.11 merged to rawhide
   - MBS randomly fails to process builds
   - Rawhide compose failures recently (syslinux retirement, then python
   3.11 merge) all fixed now
   - Business proceeding as usual

CentOS Stream Goal of this Initiative

This initiative is working on CentOS Stream/Emerging RHEL to make this new
distribution a reality. The goal of this initiative is to prepare the
ecosystem for the new CentOS Stream.
Updates

   - CentOS Stream 8: Manually keeping regular RPMs and module RPMs updated
   on the koji.stream server as current updates are composed and released.

CentOS Duffy CI Goal of this Initiative

Duffy is a system within CentOS CI infrastructure allowing tenants to
provision and access machines (physical and/or virtual, of different
architectures and configurations) for the purposes of CI testing.
Development of Duffy is largely finished, we're currently planning and
testing deployment scenarios.
Updates

   - Release version 3.2.1
   - Docs, docs, docs and a Dojo

Package Automation (Packit Service) Goal of this initiative

Automate RPM packaging of infra apps/packages
Updates

   - Mostly business as usual
   - Thanks again to all who are reviewing our PRs
   - Most of our GitHub critical apps are enabled now or close to being
   enabled

Flask-oidc: oauth2client replacement Goal of this initiative

Flask-oidc is a library used across the Fedora infrastructure and is the
client for ipsilon for its authentication. flask-oidc uses oauth2client.
This library is now deprecated and no longer maintained. This will need to
be replaced with authlib.
Updates:

   - POC working using authlib, tidying up code to prepare to submit a PR
   back to upstream

EPEL Goal of this initiative

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest
Group that creates, maintains, and manages a high-quality set of additional
packages for Enterprise Linux, including, but not limited to, Red Hat
Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux
(OL).

EPEL packages are usually based on their Fedora counterparts and will never
conflict with or replace packages in the base Enterprise Linux
distributions. EPEL uses much of the same infrastructure as Fedora,
including a build system, Bugzilla instance, updates manager, mirror
manager and more.
Updates

   - This week we have 6442 (+127)  packages, from 2882 (+76) source
   packages
   - Containerd and puppet retired from EPEL7 because of upstream EOL and
   multiple CVEs.
   - Caddy was updated, fixing 4 CVEs in EPEL9

*Index*
[1] https://pagure.io/centos-infra/issue/811
[2] https://pagure.io/centos-infra/issue/812
[3] https://pagure.io/centos-infra/issue/816

Thanks and Regards,
Akashdeep Dhar (he/him),

Objective Representative, Fedora Council

Red Hat Community Platform Engineering

t0xic0...@fedoraproject.org

akashd...@redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send

Re: Fedora Hatch Cork, Ireland - July 13th & 14th

2022-06-24 Thread Aoife Moloney

Happy Friday Fedora Friends! :)

There is still time to submit a talk to speak at Fedora Hatch Cork on July
13th in our repo  and get
your free ticket if you want to attend and not speak on our eventbrite site
. Speaker accommodation costs for
Wednesday night is covered and all attendee lunch, refreshments and casual
dinner on the Wednesday night as part of the social event afterwards costs
are covered too but this event is capped at max 30 people so if you want to
come along, make sure you get your ticket asap!
Fedora Hatch Cork is being hosted in the Red Hat office in Cork which is
super handy to get to from Cork Airport (~10 mins walk) and the hotel is
less than a 5 minute walk from the office building too. If you're hoping to
attend the event and not give a talk but still want to stay overnight(s),
please reach out to me directly and I can work with you to arrange hotel
accommodation at an event rate to pay directly to the hotel.

We're just under 3 weeks away from the event so make sure you get your
talks in, tickets registered and reach out to me if you have any questions
at all!

Have a lovely weekend and hope to see some of you in person very soon!
Aoife

On Mon, Jun 20, 2022 at 2:44 PM Aoife Moloney  wrote:

> Hi all!
>
> If you would like to attend the Fedora Hatch event in Cork, Ireland on
> July 13th & 14th, you can register your attendance here
> https://www.eventbrite.ie/e/fedora-hatch-cork-ireland-tickets-365808792947
>
> If you would like to attend and give a talk at the event, please submit
> your talk topic here https://pagure.io/cpe/Fedora_Hatch_Cork/issues. We
> are hoping to finalize a talk schedule over the next week so if you are
> interested in speaking at this event, please dont hesitate to submit your
> idea so we can add you to the speaker list.
>
> We really hope to see as many of you there as possible in ~3 weeks and if
> you are travelling from the UK or Europe, Cork airport
>  is within walking distance from the Red
> Hat office and hotel accommodation
> 
>  is
> available at a specific rate so please reach out to me directly if you need
> help with travel arrangements.
>
>
> Any other questions, you know where I am :)
>
>
> Kindest regards,
> Aoife
>
> On Wed, Jun 15, 2022 at 11:25 AM Aoife Moloney 
> wrote:
>
>> Hi Fedora friends!
>>
>> In case you missed it, the Fedora Project has granted some funding for a
>> Hatch event in Cork, Ireland on Wednesday July 13th & Thursday July 14th
>> 2022 - very exciting! For more details on how to attend, some terms and
>> conditions and what the mini-conference is about, check out the mail that
>> hit the announce list yesterday here
>> https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/thread/YWJJ5FOUZCTL3AARGXDHNRRRA4GN2UJQ/?sort=date
>>
>> Feel free to reach out to me too if you have any other questions and it
>> would be great to see some Fedora-faces in person in Cork next month!
>>
>>
>> Kindest regards,
>> Aoife
>>
>> --
>>
>> Aoife Moloney
>>
>> Product Owner
>>
>> Community Platform Engineering Team
>>
>> Red Hat EMEA 
>>
>> Communications House
>>
>> Cork Road
>>
>> Waterford
>> 
>>
>
>
> --
>
> Aoife Moloney
>
> Product Owner
>
> Community Platform Engineering Team
>
> Red Hat EMEA 
>
> Communications House
>
> Cork Road
>
> Waterford
> 
>

-- 

Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
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 2100760] perl-JSON-4.07 is available

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

Paul Howarth  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-JSON-4.07-1.fc37
 Resolution|--- |RAWHIDE
Last Closed||2022-06-24 10:12:51



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=88683847


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2100760
___
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 2100791] New: Add perl-Perl4-CoreLibs to EPEL9

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

Bug ID: 2100791
   Summary: Add perl-Perl4-CoreLibs to EPEL9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Perl4-CoreLibs
  Assignee: mspa...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2100770
  Target Milestone: ---
Classification: Fedora



Could you please add perl-Perl4-CoreLibs to EPEL9? I need it for cvs.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2100770
[Bug 2100770] please provide cvs for EPEL-9
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2100791
___
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 2100760] perl-JSON-4.07 is available

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

Paul Howarth  changed:

   What|Removed |Added

   Assignee|emman...@seyman.fr  |p...@city-fan.org
   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED




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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)


On 24. 06. 22 11:23, Dmitry Belyavskiy wrote:



On Fri, Jun 24, 2022 at 11:20 AM Daniel P. Berrangé > wrote:


On Fri, Jun 24, 2022 at 11:13:13AM +0200, Dmitry Belyavskiy wrote:
 > On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok mailto:mhron...@redhat.com>> wrote:
 >
 > > On 22. 06. 22 21:05, Vipul Siddharth wrote:
 > > > We are going to deprecate openssl1.1 package, stop shipping the
 > > > corresponding devel package, and stop respecting crypto policies in
 > > > openssl1.1 package itself.
 > >
 > > +1 to deprecating it
 > >
 >
 > Great!
 >
 > -1 to stop shipping the devel package, this would mean we cannot build at
 > > least:
 > >
 > > - Python 2.7
 > >    despite our long term efforts, many things still need that, e.g. 
gimp,
 > > firefox (some builds do, then some don't), thunderbird etc., see
 > > https://fedora.portingdb.xyz/ 
 > >
 > > Or Python 3.6 (shipped for developers targeting RHEL 7/8).
 > >
 > > As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please
 > > leave the
 > > devel package?
 > >
 >
 > I'm not sure that if we don't remove the devel package, we will provide
 > strong enough motivation to get rid of the deprecating packages.

If the openssl maintainers really strongly want to remove the
devel pacakge, then don't call this deprecation because that
is misleading. Call this purging openssl1.1 from the entire
distro, such that it can only be used by 3rd party apps who
have previously compiled against older Fedora openssl-devel.
Be open about fact that this will cause FTBFS for any Fedora
packages that stil uses openssl1 and their removal from the
distro if they can't port to openssl3 very quickly.

Do I correctly understand that the situation with Python is the most 
problematic?
Are we able to solve it somehow?

What I'm afraid of is that if we just declare the deprecation, we will stay 
with this package forever.


Not forever, just until Python 2.7 is removed :D

Seriously thou, my proposal is:

 - deprecate it now
 - announce it goes away when RHEL 8 maintenance support ends

Following the guidelines for deprecated packages:
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/

  # This is when RHEL 8 maintenance support is expected to end
  # https://access.redhat.com/support/policy/updates/errata
  # The life-cycle time spans and dates are subject to adjustment
  Provides: deprecated() = 20290531

You are going to support OpenSSL 1.1 in RHEL 8 until that day anyway.

This is also when we plan to remove Python 3.6:
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/W74WYEVGYAE57KVLCG73I75LZYKKUMXS/

And if Python 2.7 isn't removed by then, we can rip it out together with 
OpenSSL 1.1 in Fedora 50.


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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Felix Schwarz


Am 24.06.22 um 11:27 schrieb Florian Weimer:

* Felix Schwarz:


Are these Python 2.7 dependencies only used at build time? In that
case Fedora could maybe announce that openssl1.1 might not get the
full security suport so the burden for openssl1.1 packagers is lower
without removing the functionality?


I'm pretty sure it's used for Python's own HTTPS implementation, among
other things, so it's not really an optional feature (although Python
can be built without it, I believe).


What I meant is: Is Python 2.7 only used as a build dependency? If so, I think 
we might be able to state that Python 2.7 + openssl might get reduced security 
support. At build time we don't have any network access anyway.


I guess it is clear that removing openssl1.1 is not really feasible unless we 
remove Python 2.7.


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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Felix Schwarz


Am 24.06.22 um 11:23 schrieb Dmitry Belyavskiy:
What I'm afraid of is that if we just declare the deprecation, we will stay with 
this package forever.


Well, RHEL 7 maintenance support 2 phase ends in June 2024. I'd expect that we 
should be able to drop Python 2.7 from Fedora at that point at least (probably 
even before).


And yes, I think removing really important packages like OpenSSL 1 or Python 2.7 
is not an easy task for a general-purpose Linux distribution.


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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)


On 24. 06. 22 11:27, Florian Weimer wrote:

* Felix Schwarz:


Are these Python 2.7 dependencies only used at build time? In that
case Fedora could maybe announce that openssl1.1 might not get the
full security suport so the burden for openssl1.1 packagers is lower
without removing the functionality?


I'm pretty sure it's used for Python's own HTTPS implementation, among
other things, so it's not really an optional feature (although Python
can be built without it, I believe).


It is possible to build Python 2 without the ssl module. HTTPS would indeed not 
work and hence pip would not work. In return, the package would be useless for 
Python developers using virtualenv to test their code that still needs to 
support Python 2.


If openssl1.1-devel goes away, we would likely need to either bundle openssl 
entirely (which is worse than having openssl1.1-devel in Fedora IMHO), or just 
bundle the headers somehow, which just creates a room for breakage with every 
openssl 1.1 update for no added benefit.


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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

* Felix Schwarz:

> Are these Python 2.7 dependencies only used at build time? In that
> case Fedora could maybe announce that openssl1.1 might not get the
> full security suport so the burden for openssl1.1 packagers is lower
> without removing the functionality?

I'm pretty sure it's used for Python's own HTTPS implementation, among
other things, so it's not really an optional feature (although Python
can be built without it, I believe).

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Dmitry Belyavskiy

On Fri, Jun 24, 2022 at 11:20 AM Daniel P. Berrangé 
wrote:

> On Fri, Jun 24, 2022 at 11:13:13AM +0200, Dmitry Belyavskiy wrote:
> > On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok 
> wrote:
> >
> > > On 22. 06. 22 21:05, Vipul Siddharth wrote:
> > > > We are going to deprecate openssl1.1 package, stop shipping the
> > > > corresponding devel package, and stop respecting crypto policies in
> > > > openssl1.1 package itself.
> > >
> > > +1 to deprecating it
> > >
> >
> > Great!
> >
> > -1 to stop shipping the devel package, this would mean we cannot build at
> > > least:
> > >
> > > - Python 2.7
> > >despite our long term efforts, many things still need that, e.g.
> gimp,
> > > firefox (some builds do, then some don't), thunderbird etc., see
> > > https://fedora.portingdb.xyz/
> > >
> > > Or Python 3.6 (shipped for developers targeting RHEL 7/8).
> > >
> > > As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please
> > > leave the
> > > devel package?
> > >
> >
> > I'm not sure that if we don't remove the devel package, we will provide
> > strong enough motivation to get rid of the deprecating packages.
>
> If the openssl maintainers really strongly want to remove the
> devel pacakge, then don't call this deprecation because that
> is misleading. Call this purging openssl1.1 from the entire
> distro, such that it can only be used by 3rd party apps who
> have previously compiled against older Fedora openssl-devel.
> Be open about fact that this will cause FTBFS for any Fedora
> packages that stil uses openssl1 and their removal from the
> distro if they can't port to openssl3 very quickly.
>
> Do I correctly understand that the situation with Python is the most
problematic?
Are we able to solve it somehow?

What I'm afraid of is that if we just declare the deprecation, we will stay
with this package forever.

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Daniel P . Berrangé

On Fri, Jun 24, 2022 at 11:13:13AM +0200, Dmitry Belyavskiy wrote:
> On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok  wrote:
> 
> > On 22. 06. 22 21:05, Vipul Siddharth wrote:
> > > We are going to deprecate openssl1.1 package, stop shipping the
> > > corresponding devel package, and stop respecting crypto policies in
> > > openssl1.1 package itself.
> >
> > +1 to deprecating it
> >
> 
> Great!
> 
> -1 to stop shipping the devel package, this would mean we cannot build at
> > least:
> >
> > - Python 2.7
> >despite our long term efforts, many things still need that, e.g. gimp,
> > firefox (some builds do, then some don't), thunderbird etc., see
> > https://fedora.portingdb.xyz/
> >
> > Or Python 3.6 (shipped for developers targeting RHEL 7/8).
> >
> > As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please
> > leave the
> > devel package?
> >
> 
> I'm not sure that if we don't remove the devel package, we will provide
> strong enough motivation to get rid of the deprecating packages.

If the openssl maintainers really strongly want to remove the
devel pacakge, then don't call this deprecation because that
is misleading. Call this purging openssl1.1 from the entire
distro, such that it can only be used by 3rd party apps who
have previously compiled against older Fedora openssl-devel.
Be open about fact that this will cause FTBFS for any Fedora
packages that stil uses openssl1 and their removal from the
distro if they can't port to openssl3 very quickly.

With 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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Felix Schwarz


Am 24.06.22 um 11:13 schrieb Dmitry Belyavskiy:
I'm not sure that if we don't remove the devel package, we will provide strong 
enough motivation to get rid of the deprecating packages.


imho removing the devel packages is basically the same as removing openssl1.1 
entirely. To me the idea of "deprecation" is to warn users that something is 
going away WITHOUT removing functionality immediately.


And yes, Python 2.7 might be a pain point for packagers but fact is that 
important packages still rely on it. Removing openssl just shifts the burden to 
(many more) packagers who just need Python 2.7 for their packages.


Are these Python 2.7 dependencies only used at build time? In that case Fedora 
could maybe announce that openssl1.1 might not get the full security suport so 
the burden for openssl1.1 packagers is lower without removing the functionality?


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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)


On 24. 06. 22 11:13, Dmitry Belyavskiy wrote:



On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok > wrote:


On 22. 06. 22 21:05, Vipul Siddharth wrote:
 > We are going to deprecate openssl1.1 package, stop shipping the
 > corresponding devel package, and stop respecting crypto policies in
 > openssl1.1 package itself.

+1 to deprecating it


Great!

-1 to stop shipping the devel package, this would mean we cannot build at
least:

- Python 2.7
    despite our long term efforts, many things still need that, e.g. gimp,
firefox (some builds do, then some don't), thunderbird etc., see
https://fedora.portingdb.xyz/ 

Or Python 3.6 (shipped for developers targeting RHEL 7/8).

As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please leave
the
devel package?


I'm not sure that if we don't remove the devel package, we will provide strong 
enough motivation to get rid of the deprecating packages.


You probably won't. But by breaking it intentionally, you are just shifting the 
problem somewhere else.


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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-24 Thread Dmitry Belyavskiy

On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok  wrote:

> On 22. 06. 22 21:05, Vipul Siddharth wrote:
> > We are going to deprecate openssl1.1 package, stop shipping the
> > corresponding devel package, and stop respecting crypto policies in
> > openssl1.1 package itself.
>
> +1 to deprecating it
>

Great!

-1 to stop shipping the devel package, this would mean we cannot build at
> least:
>
> - Python 2.7
>despite our long term efforts, many things still need that, e.g. gimp,
> firefox (some builds do, then some don't), thunderbird etc., see
> https://fedora.portingdb.xyz/
>
> Or Python 3.6 (shipped for developers targeting RHEL 7/8).
>
> As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please
> leave the
> devel package?
>

I'm not sure that if we don't remove the devel package, we will provide
strong enough motivation to get rid of the deprecating packages.

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

Fedora-IoT-36-20220624.0 compose check report

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-36-20220618.0):

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

Passed openQA tests: 14/15 (aarch64), 15/15 (x86_64)

New passes (same test not passed in Fedora-IoT-36-20220618.0):

ID: 1305757 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1305757
ID: 1305759 Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/1305759
ID: 1305760 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/1305760
ID: 1305763 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1305763

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.22 to 0.37
Previous test data: https://openqa.fedoraproject.org/tests/1302489#downloads
Current test data: https://openqa.fedoraproject.org/tests/1305751#downloads
-- 
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: Review request: sfsexp - Small Fast S-Expression Library

2022-06-24 Thread Michael J Gruber

So, thanks to the good and fast review sfsexp is in rawhide now. Hooray!

It turns out that bodhi applies the same boundary conditions to "newpackage" 
updates (no karma for your own update, 7 days minimum to stable by time). I 
don't think a new leave package can disturb current systems much ... A library, 
in particular, will not receive any testing while in testing.

So, since the new package certainly resolves the "new package" bug, and if 
someone thinks this is enough I'd be happy to receive +1 karma for the 
following updates:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-8e53be2fb9
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-57dfeeb304

Once they are in stable, I'll rebuild notmuch against sfsexp for the real test 
(which was successful in copr already).

I could have built the new sfsexp and an update for notmuch in a side-tag, of 
course, but that would have lead to a "mixed update" (new package/enhancement) 
which didn't seem optimal either.

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

Fedora-Cloud-35-20220624.0 compose check report

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-35-20220623.0):

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

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

[Bug 2100760] New: perl-JSON-4.07 is available

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

Bug ID: 2100760
   Summary: perl-JSON-4.07 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-JSON
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, jonstan...@gmail.com,
mspa...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 4.07
Upstream release that is considered latest: 4.07
Current version/release in rawhide: 4.06-2.fc37
URL: http://search.cpan.org/dist/JSON/

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


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-JSON


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

Meld directory compare still broken in f36

2022-06-24 Thread Andrea Musuruane

Hi,
meld directory compare in f36 is broken.

I opened a bug report last month:
https://bugzilla.redhat.com/show_bug.cgi?id=2091377

Some days later, kiilerix provided a PR to fix this issue:
https://src.fedoraproject.org/rpms/meld/pull-request/6

The PR has been accepted but a new package hasn't been build.

Can the packager or a proven packager please do this?

Thanks,

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

Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

* Tom Stellard:

> On 6/7/22 02:18, Florian Weimer wrote:
>> * Ben Cotton:
>> 
>>> This change will add new macros which will make it easier for packages
>>> to add and remove their own compiler flags.  This strategy is already
>>> used to some extent with feature macros like %{_lto_cflags},
>>> %{_hardening_cflags}, etc, but these new macros will give packagers
>>> even more fine-grained control over the options.
>>>
>>> The proposed macros for adding new flags are:
>>>
>>>  %_pkg_extra_cflags
>>>  %_pkg_extra_cxxflags
>>>  %_pkg_extra_fflags
>>>  %_pkg_extra_ldflags
>> Why isn't it possible to use the environment variables for this?
>> 
>
> Environment variables won't cover all cases.  For example, some packages
> need the flags passed as arguments to make or configure or some other
> build system.

But then you can stick the extra flags into that argument.  I don't see
why this additional hook is needed.

>> This is very misleading because in several cases, clearing the those
>> flags will not affect toolchain behavior because the flag in question
>> merely restates the toolchain default.  In particular, this applies to
>> -fasynchronous-unwind-tables, and it would apply to -march= and -mcpu=
>> if those were in the list.  Likewise to -Wl,-z,relro.
>> Is the goal of this proposal just to achieve a textual flags change
>> (disregarding any change in behavior), or to actually change toolchain

> The goal is to make it easy to remove individual flags so packages can
> get the toolchain behavior they want.

Sorry, this does not answer my question.  What if removing the flag does
not actually change toolchain behavior?

>> If the former, I'm not sure if the actual _flag names are useful.  Maybe
>> we can add an RPM macro to suppress or replace flags based on the flags
>> as they are used instead.  This could also add additional error checking
>> because a name typo in the macro definition will not be immediately
>> obvious.
>> 
>
> Can you give an example of what you mean by this?

You could write:

%build_cxxflags_remove -Wp,-D_GLIBCXX_ASSERTIONS

or some similar construct, and -Wp,-D_GLIBCXX_ASSERTIONS would be
removed from the build flags.

>>> With these new macros, the examples from above could be re-written as:
>>>
>>>  compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
>>>  julia:   %global _flag_glibcxx_assertions %{nil}
>> Do you have some background why -D_DEFAULT_SOURCE is needed?  Why
>> doesn't upstream detect this?
>> 
>
> It was added to workaround this bug: 
> https://sourceware.org/bugzilla/show_bug.cgi?id=25271

This has long since been fixed, so the workaround is no longer needed.

-D_GLIBCXX_ASSERTIONS has zero false positives.  Removing it does not
make the code that triggers the asserts well-defined.  Only the explicit
assertion failure is gone.  So it is probably another example of a flag
where removal does not result in the hoped-for change in toolchain
behavior.

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

Re: [Fedora-packaging] Re: [RFC] Build tag in RPM: from NVR to NVRB


On 24. 06. 22 9:30, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 23 June 2022 at 15:01, Miro Hrončok wrote:

On 23. 06. 22 14:24, Aleksandra Fedorova wrote:

2) A packager rebuilds packages from Fedora dist-git in a Copr repo, what will
be the value of the build tag? How will the Copr build sort over the official
Fedora builds? (This is essentially the same question but the answer might 
differ.)

Similar as above, the questions would be how does it work now, do we
want a change or do we want to keep the current setup?


Examples from before the Python 3.11 side tag was merged.


Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10)
Python 3.11 copr: python3-tomli-2.0.1-2.fc37 (built with Python 3.11)

The NEVRs are identical. Other builds in the Python 3.11 copr install the
3.11 build.


Now when we managed to not pick up a certain bump:

Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10)
Python 3.11 copr: python3-tomli-2.0.1-1.fc37 (built with Python 3.11)

The rawhide's NEVR is higher. Other builds in the Python 3.11 copr install
try to install the 3.10 build and that conflicts with other stuff in the
copr and the dependency resolution fails.

We certainly don't want to regress in that regard.


You can build almost anything in COPR and with random NEVRA.
Accommodating what you described above would be nice to have, but should
definitely not be a requirement. Adding build ID would not help here,
either, as they will be different between different build systems.


No, adding build ID would break this.


COPR builds have different buildhost and are signed with a different
signature. You cannot expect two packages with identical NEVRA but
different buildhost and signature to have identical dependencies and
contents.


I don't.

--
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-36-20220624.0 compose check report