Re: Automate your Fedora package maintenance using Packit

[Laura Barcziova]

Hi Sergio,

we have a full example in our docs:
https://packit.dev/docs/fedora-releases-guide#full-example or you can check
the configuration of packages that have Packit set up, e.g.
https://src.fedoraproject.org/rpms/qownnotes/blob/rawhide/f/.packit.yaml or
https://src.fedoraproject.org/rpms/micropipenv/blob/rawhide/f/.packit.yaml
(you can find more usages from our dashboard:
https://dashboard.packit.dev/jobs/pull-from-upstreams).

You could try a similar setup and test it from a dist-git pull request as
described here: https://packit.dev/docs/fedora-releases-guide#first-setup.

If you would like to further discuss your setup or you need more help, feel
free to ask or reach out directly on #packit:fedora.im
.

Laura

On Wed, Nov 15, 2023 at 12:02 AM Sérgio Basto  wrote:

> Hi,
>
> have we an example working ?
>
>  I'd like had packit
> for https://src.fedoraproject.org/rpms/libphonenumber
>
> Upstream Release Monitoring report here:
> https://bugzilla.redhat.com/show_bug.cgi?id=2237976
>
>
> I'd like have the pull request , koji_build   and bohi update
>
>
> Thank you,
>
>
>
>
> On Fri, 2023-09-15 at 09:22 +0200, Laura Barcziova wrote:
> > If you're a Fedora package maintainer, we've got an exciting
> > automation solution for you!
> >
> > At the beginning of the year, we announced a new feature called
> > pull_from_upstream that eases the process of bringing upstream
> > releases into Fedora. This feature can be easily configured directly
> > in the dist-git repository without access to the upstream (as opposed
> > to our previously introduced automation). It is most suitable for
> > simple packages with straightforward update processes (e.g. without
> > patches, or need to build in side tags).
> >
> > Our automation works on top of the Upstream Release Monitoring [1],
> > and here's how to set it up:
> >
> >1. Enable Upstream Release Monitoring for your Fedora package: set
> > the mapping of the project in Anitya and in the left column in
> > https://src.fedoraproject.org/rpms/$YourPackage, change Monitoring
> > status to Monitoring.
> >2. Add the Packit configuration with the pull_from_upstream job to
> > your dist-git repository (see example
> > https://packit.dev/docs/configuration/downstream/pull_from_upstream#e
> > xample).
> > Once set up, here's how it works:
> >  * Upstream Release Monitoring creates a Bugzilla bug when new
> > upstream versions are detected.
> >  * As a reaction to that, Packit:
> > - automatically uploads the upstream archive to the lookaside
> > cache,
> > - creates dist-git pull request(s) at
> > https://src.fedoraproject.org/ with all the necessary changes, like
> > updates to the specfile and sources.
> > If you are interested in this, read the previously published full
> > post with the details of the setup here:
> > https://packit.dev/posts/pull-from-upstream. Since the publication of
> > this post, many users have adopted this feature and provided valuable
> > feedback, allowing us to enhance the UX. We're now excited to assist
> > you in automating the process as well!
> >
> > In addition to creating pull requests in dist-git, Packit can also
> > automate Koji builds and Bodhi updates:
> >  * https://packit.dev/docs/configuration/downstream/koji_build
> >  * https://packit.dev/docs/configuration/downstream/bodhi_update
> >
> > For complete automation documentation, don't miss our comprehensive
> > Fedora release guide at: https://packit.dev/docs/fedora-releases-
> > guide. It contains all the essential information and setup tips.
> >
> > For any questions, feel free to contact us:
> > https://packit.dev/#contact.
> >
> > Best regards,
> >
> > Packit team!
> >
> > [1] https://docs.fedoraproject.org/en-US/package-
> > maintainers/Upstream_Release_Monitoring/
> > ___
> > 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.fedoraproje
> > ct.org
> > Do not reply to spam, report it: https://pagure.io/fedora-
> > infrastructure/new_issue
>
> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list 

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eca2daf875   
chromium-119.0.6045.123-1.el7


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

lemonldap-ng-2.17.2-1.el7
libre-3.6.2-1.el7
netcat-1.226-1.el7

Details about builds:



 lemonldap-ng-2.17.2-1.el7 (FEDORA-EPEL-2023-25d836d064)
 Web Single Sign On (SSO) and Access Management

Update Information:

Fix for : - Logout error with message "[error] Unknown Relying Party " in
logs - Userinfo sometimes does not return attributes

ChangeLog:

* Tue Nov 14 2023 Clement Oudot  - 2.17.2-1
- Update to 2.17.2
* Fri Oct 13 2023 Xavier Bachelot  - 2.17.1-4
- Enable GeoIP2 and HTTP::BrowserDetectfor EL8




 libre-3.6.2-1.el7 (FEDORA-EPEL-2023-0fa9cb88b3)
 Generic library for real-time communications

Update Information:

# libre v3.6.2 (2023-11-06)* sip/transp: add win32 local transport addr
fallback (fixes TCP/TLS register)

ChangeLog:

* Tue Nov  7 2023 Robert Scheck  3.6.2-1
- Upgrade to 3.6.2 (#2248185)

References:

  [ 1 ] Bug #2248185 - libre-3.6.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2248185




 netcat-1.226-1.el7 (FEDORA-EPEL-2023-558a801db2)
 OpenBSD netcat to read and write data across connections using TCP or UDP

Update Information:

# OpenBSD netcat 1.226   - Avoid issuing syscalls on fd -1

ChangeLog:

* Tue Nov 14 2023 Robert Scheck  1.226-1
- Upgrade to 1.226 (#2244540)

References:

  [ 1 ] Bug #2244540 - netcat-1.226 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2244540


___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249482] No perl-HTML-Scrubber for EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
FEDORA-EPEL-2023-99de16c447 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-99de16c447

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249482

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249482%23c8
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-6b5f919719   
tor-0.4.8.9-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f535d91d21   
chromium-119.0.6045.123-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-bdf128f5d3   
audiofile-0.3.6-36.el8


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

airinv-1.00.8-1.el8
caja-extensions-1.26.1-3.el8
lemonldap-ng-2.17.2-1.el8
libre-3.6.2-1.el8
netcat-1.226-1.el8
tvlsim-1.01.6-1.el8
wasmedge-0.13.5-1.el8

Details about builds:



 airinv-1.00.8-1.el8 (FEDORA-EPEL-2023-4209378285)
 C++ Simulated Airline Inventory Management System library

Update Information:

Fixed a build issue related to old ZeroMQ version on EPEL 8

ChangeLog:

* Tue Nov 14 2023 Denis Arnaud  - 1.00.8-11
- Fixed the build issue wrt Python
* Tue Nov 14 2023 Denis Arnaud  - 1.00.8-10
- Fixed missing python3-rmol
* Tue Nov 14 2023 Denis Arnaud  - 1.00.8-9
- Modernized the spec file
* Tue Nov 14 2023 Denis Arnaud  - 1.00.8-8
- Modernized the spec file
* Tue Nov 14 2023 Denis Arnaud  - 1.00.8-7
- Modernized the spec file
* Tue Nov 14 2023 Denis Arnaud  - 1.00.8-6
- RPMAUTOSPEC: unresolvable merge




 caja-extensions-1.26.1-3.el8 (FEDORA-EPEL-2023-a0beab3085)
 Set of extensions for caja file manager

Update Information:

- add upstream commits

ChangeLog:

* Tue Nov 14 2023 Wolfgang Ulbrich  - 1.26.1-3
- fix rhbz (#2249632)
- use upstream commit 
https://github.com/mate-desktop/caja-extensions/commit/91cc466

References:

  [ 1 ] Bug #2249632 - caja-image-converter Issue #107
https://bugzilla.redhat.com/show_bug.cgi?id=2249632




 lemonldap-ng-2.17.2-1.el8 (FEDORA-EPEL-2023-ba00760228)
 Web Single Sign On (SSO) and Access Management

Update Information:

Fix for : - Logout error with message "[error] Unknown Relying Party " in
logs - Userinfo sometimes does not return attributes

ChangeLog:

* Tue Nov 14 2023 Clement Oudot  - 2.17.2-1
- Update to 2.17.2
* Fri Oct 13 2023 Xavier Bachelot  - 2.17.1-4
- Enable GeoIP2 and HTTP::BrowserDetectfor EL8




 libre-3.6.2-1.el8 (FEDORA-EPEL-2023-96f8e64bed)
 Generic library for real-time communications

Update Information:

# libre v3.6.2 (2023-11-06)* sip/transp: add win32 local transport addr
fallback (fixes TCP/TLS register)

ChangeLog:

* Tue Nov  7 2023 Robert Scheck  3.6.2-1
- Upgrade to 3.6.2 (#2248185)

References:

  [ 1 ] Bug #2248185 - libre-3.6.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2248185




 netcat-1.226-1.el8 (FEDORA-EPEL-2023-6c1c58c698)
 OpenBSD netcat to read and write data across connections using TCP or UDP

Update Information:

# OpenBSD netcat 1.226   - Avoid issuing syscalls on fd -1

ChangeLog:

* Tue Nov 14 2023 Robert Scheck  1.226-1
- Upgrade to 1.226 (#2244540)

References:

  [ 1 ] Bug #2244540 - netcat-1.226 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2244540




 tvlsim-1.01.6-1.el8 

Fedora rawhide compose report: 20231114.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20231113.n.0
NEW: Fedora-Rawhide-20231114.n.1

= SUMMARY =
Added images:4
Dropped images:  3
Added packages:  13
Dropped packages:0
Upgraded packages:   163
Downgraded packages: 0

Size of added packages:  3.88 MiB
Size of dropped packages:0 B
Size of upgraded packages:   5.27 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20231114.n.1.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231114.n.1.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231114.n.1.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20231114.n.1.iso

= DROPPED IMAGES =
Image: Workstation live-osbuild x86_64
Path: 
Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20231113.n.0.x86_64.iso
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20231113.n.0.iso
Image: Workstation live-osbuild aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20231113.n.0.aarch64.iso

= ADDED PACKAGES =
Package: liblc3-1.0.4-2.fc40
Summary: Low Complexity Communication Codec (LC3)
RPMs:liblc3 liblc3-devel liblc3-utils
Size:554.33 KiB

Package: mat2-0.13.4-3.fc40
Summary: Metadata removal tool, supporting a wide range of commonly used file 
formats
RPMs:mat2 mat2-dolphin python3-libmat2
Size:129.73 KiB

Package: python-rpmautospec-core-0.1.0-1.fc40
Summary: Minimum functionality for rpmautospec
RPMs:python3-rpmautospec-core
Size:13.21 KiB

Package: rust-cargo-credential-0.3.0-1.fc40
Summary: Library to assist writing Cargo credential helpers
RPMs:rust-cargo-credential+default-devel rust-cargo-credential-devel
Size:29.81 KiB

Package: rust-cargo-credential-libsecret-0.3.1-1.fc40
Summary: Cargo credential process that stores tokens with GNOME libsecret
RPMs:rust-cargo-credential-libsecret+default-devel 
rust-cargo-credential-libsecret-devel
Size:22.48 KiB

Package: rust-cbindgen0.24-0.24.5-1.fc40
Summary: Tool for generating C bindings to Rust code
RPMs:rust-cbindgen0.24+clap-devel rust-cbindgen0.24+default-devel 
rust-cbindgen0.24-devel
Size:545.08 KiB

Package: rust-pyo3-build-config0.19-0.19.2-1.fc40
Summary: Build configuration for the PyO3 ecosystem
RPMs:rust-pyo3-build-config0.19+abi3-devel 
rust-pyo3-build-config0.19+abi3-py310-devel 
rust-pyo3-build-config0.19+abi3-py311-devel 
rust-pyo3-build-config0.19+abi3-py37-devel 
rust-pyo3-build-config0.19+abi3-py38-devel 
rust-pyo3-build-config0.19+abi3-py39-devel 
rust-pyo3-build-config0.19+default-devel 
rust-pyo3-build-config0.19+extension-module-devel 
rust-pyo3-build-config0.19+resolve-config-devel rust-pyo3-build-config0.19-devel
Size:100.52 KiB

Package: rust-pyo3-ffi0.19-0.19.2-1.fc40
Summary: Python-API bindings for the PyO3 ecosystem
RPMs:rust-pyo3-ffi0.19+abi3-devel rust-pyo3-ffi0.19+abi3-py310-devel 
rust-pyo3-ffi0.19+abi3-py311-devel rust-pyo3-ffi0.19+abi3-py37-devel 
rust-pyo3-ffi0.19+abi3-py38-devel rust-pyo3-ffi0.19+abi3-py39-devel 
rust-pyo3-ffi0.19+default-devel rust-pyo3-ffi0.19+extension-module-devel 
rust-pyo3-ffi0.19-devel
Size:145.86 KiB

Package: rust-pyo3-macros-backend0.19-0.19.2-1.fc40
Summary: Code generation for PyO3 package
RPMs:rust-pyo3-macros-backend0.19+abi3-devel 
rust-pyo3-macros-backend0.19+default-devel rust-pyo3-macros-backend0.19-devel
Size:66.86 KiB

Package: rust-pyo3-macros0.19-0.19.2-1.fc40
Summary: Proc macros for PyO3 package
RPMs:rust-pyo3-macros0.19+abi3-devel rust-pyo3-macros0.19+default-devel 
rust-pyo3-macros0.19+multiple-pymethods-devel rust-pyo3-macros0.19-devel
Size:36.71 KiB

Package: rust-pyo3_0.19-0.19.2-1.fc40
Summary: Bindings to Python interpreter
RPMs:rust-pyo3_0.19+abi3-devel rust-pyo3_0.19+abi3-py310-devel 
rust-pyo3_0.19+abi3-py311-devel rust-pyo3_0.19+abi3-py37-devel 
rust-pyo3_0.19+abi3-py38-devel rust-pyo3_0.19+abi3-py39-devel 
rust-pyo3_0.19+anyhow-devel rust-pyo3_0.19+auto-initialize-devel 
rust-pyo3_0.19+chrono-devel rust-pyo3_0.19+default-devel 
rust-pyo3_0.19+experimental-inspect-devel rust-pyo3_0.19+extension-module-devel 
rust-pyo3_0.19+eyre-devel rust-pyo3_0.19+full-devel 
rust-pyo3_0.19+hashbrown-devel rust-pyo3_0.19+indexmap-devel 
rust-pyo3_0.19+indoc-devel rust-pyo3_0.19+inventory-devel 
rust-pyo3_0.19+macros-devel rust-pyo3_0.19+multiple-pymethods-devel 
rust-pyo3_0.19+nightly-devel rust-pyo3_0.19+num-bigint-devel 
rust-pyo3_0.19+num-complex-devel rust-pyo3_0.19+pyo3-macros-devel 
rust-pyo3_0.19+rust_decimal-devel rust-pyo3_0.19+serde-devel 
rust-pyo3_0.19+unindent-devel rust-pyo3_0.19-devel
Size:574.63 KiB

Package: rust-snap-1.1.0-1.fc40
Summary: Pure Rust

[Bug 2247795] perl-Time-Out-0.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Out-0.20-1.fc40   |perl-Time-Out-0.20-1.fc40
   |perl-Time-Out-0.21-1.fc39   |perl-Time-Out-0.21-1.fc39
   |perl-Time-Out-0.21-1.fc37   |perl-Time-Out-0.21-1.fc37
   |perl-Time-Out-0.21-1.fc38   |perl-Time-Out-0.21-1.fc38
   ||perl-Time-Out-0.21-1.el8



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2247795

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247795%23c15
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2248029] perl-Time-Out-0.21 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Out-0.21-1.fc40   |perl-Time-Out-0.21-1.fc40
   |perl-Time-Out-0.21-1.fc39   |perl-Time-Out-0.21-1.fc39
   |perl-Time-Out-0.21-1.fc37   |perl-Time-Out-0.21-1.fc37
   |perl-Time-Out-0.21-1.fc38   |perl-Time-Out-0.21-1.fc38
   ||perl-Time-Out-0.21-1.el8



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2248029

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202248029%23c13
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2248029] perl-Time-Out-0.21 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Out-0.21-1.fc40   |perl-Time-Out-0.21-1.fc40
   |perl-Time-Out-0.21-1.fc39   |perl-Time-Out-0.21-1.fc39
   |perl-Time-Out-0.21-1.fc37   |perl-Time-Out-0.21-1.fc37
   ||perl-Time-Out-0.21-1.fc38



--- Comment #12 from Fedora Update System  ---
FEDORA-2023-7d731eb090 has been pushed to the Fedora 38 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=2248029

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202248029%23c12
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2247795] perl-Time-Out-0.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Out-0.20-1.fc40   |perl-Time-Out-0.20-1.fc40
   |perl-Time-Out-0.21-1.fc39   |perl-Time-Out-0.21-1.fc39
   |perl-Time-Out-0.21-1.fc37   |perl-Time-Out-0.21-1.fc37
   ||perl-Time-Out-0.21-1.fc38



--- Comment #14 from Fedora Update System  ---
FEDORA-2023-7d731eb090 has been pushed to the Fedora 38 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=2247795

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247795%23c14
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2247795] perl-Time-Out-0.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Out-0.20-1.fc40   |perl-Time-Out-0.20-1.fc40
   |perl-Time-Out-0.21-1.fc39   |perl-Time-Out-0.21-1.fc39
   ||perl-Time-Out-0.21-1.fc37



--- Comment #13 from Fedora Update System  ---
FEDORA-2023-19b05203f3 has been pushed to the Fedora 37 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=2247795

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247795%23c13
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2248029] perl-Time-Out-0.21 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Out-0.21-1.fc40   |perl-Time-Out-0.21-1.fc40
   |perl-Time-Out-0.21-1.fc39   |perl-Time-Out-0.21-1.fc39
   ||perl-Time-Out-0.21-1.fc37



--- Comment #11 from Fedora Update System  ---
FEDORA-2023-19b05203f3 has been pushed to the Fedora 37 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=2248029

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202248029%23c11
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2248029] perl-Time-Out-0.21 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Time-Out-0.21-1.fc40   |perl-Time-Out-0.21-1.fc40
   ||perl-Time-Out-0.21-1.fc39
 Resolution|--- |ERRATA
Last Closed||2023-11-15 01:42:12



--- Comment #10 from Fedora Update System  ---
FEDORA-2023-b314a12323 has been pushed to the Fedora 39 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=2248029

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202248029%23c10
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2247795] perl-Time-Out-0.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Out-0.20-1.fc40   |perl-Time-Out-0.20-1.fc40
   ||perl-Time-Out-0.21-1.fc39
 Resolution|RAWHIDE |ERRATA



--- Comment #12 from Fedora Update System  ---
FEDORA-2023-b314a12323 has been pushed to the Fedora 39 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=2247795

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247795%23c12
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Sérgio Basto]

Hi, 

have we an example working ? 

 I'd like had packit
for https://src.fedoraproject.org/rpms/libphonenumber 

Upstream Release Monitoring report here:
https://bugzilla.redhat.com/show_bug.cgi?id=2237976


I'd like have the pull request , koji_build   and bohi update 


Thank you,




On Fri, 2023-09-15 at 09:22 +0200, Laura Barcziova wrote:
> If you're a Fedora package maintainer, we've got an exciting
> automation solution for you!
> 
> At the beginning of the year, we announced a new feature called
> pull_from_upstream that eases the process of bringing upstream
> releases into Fedora. This feature can be easily configured directly
> in the dist-git repository without access to the upstream (as opposed
> to our previously introduced automation). It is most suitable for
> simple packages with straightforward update processes (e.g. without
> patches, or need to build in side tags).
> 
> Our automation works on top of the Upstream Release Monitoring [1],
> and here's how to set it up:
> 
>    1. Enable Upstream Release Monitoring for your Fedora package: set
> the mapping of the project in Anitya and in the left column in
> https://src.fedoraproject.org/rpms/$YourPackage, change Monitoring
> status to Monitoring.
>    2. Add the Packit configuration with the pull_from_upstream job to
> your dist-git repository (see example
> https://packit.dev/docs/configuration/downstream/pull_from_upstream#e
> xample).
> Once set up, here's how it works:
>  * Upstream Release Monitoring creates a Bugzilla bug when new
> upstream versions are detected.
>  * As a reaction to that, Packit:
> - automatically uploads the upstream archive to the lookaside
> cache,
> - creates dist-git pull request(s) at
> https://src.fedoraproject.org/ with all the necessary changes, like
> updates to the specfile and sources.
> If you are interested in this, read the previously published full
> post with the details of the setup here:
> https://packit.dev/posts/pull-from-upstream. Since the publication of
> this post, many users have adopted this feature and provided valuable
> feedback, allowing us to enhance the UX. We're now excited to assist
> you in automating the process as well! 
> 
> In addition to creating pull requests in dist-git, Packit can also
> automate Koji builds and Bodhi updates:
>  * https://packit.dev/docs/configuration/downstream/koji_build 
>  * https://packit.dev/docs/configuration/downstream/bodhi_update
> 
> For complete automation documentation, don't miss our comprehensive
> Fedora release guide at: https://packit.dev/docs/fedora-releases-
> guide. It contains all the essential information and setup tips.
> 
> For any questions, feel free to contact us:
> https://packit.dev/#contact.
> 
> Best regards,
> 
> Packit team!
> 
> [1] https://docs.fedoraproject.org/en-US/package-
> maintainers/Upstream_Release_Monitoring/
> ___
> 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.fedoraproje
> ct.org
> Do not reply to spam, report it: https://pagure.io/fedora-
> infrastructure/new_issue

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

Re: DNF5: Checking signatures of packages installed out of a repository?

[Florian Weimer]

* Michael Catanzaro:

> On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher
>  wrote:
>> I think for the sake of security, it'd be better if this were on by
>> default, and you just had to specify the --nogpgcheck
>> For convenience, the error message should probably say "Error: GPG
>> check FAILED (try again with '--nogpgcheck' to ignore)"
>> I don't think this use case is so important that everybody's security
>> should be lowered to avoid the minor inconvenience of passing a simple
>> flag.
>
> Thing is, when manually installing RPMs that don't come from a
> repository, 98% of the time they are not expected to be signed by a
> GPG key that you have installed, so the check is expected to fail. GPG
> check is just not the right thing to do in this case. If we enable GPG
> checking when not appropriate, ***we will train users to reflexively
> ignore GPG errors.***

We already trained them to use -y, which can automatically enroll new
keys.  I'm not sure if a trust boundary is crossed in that case, but if
there isn't, why is user confirmation even needed?

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Leon Fauster via devel]

Am 14.11.23 um 22:04 schrieb Christopher:

On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro  wrote:


On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher
 wrote:

I think for the sake of security, it'd be better if this were on by
default, and you just had to specify the --nogpgcheck
For convenience, the error message should probably say "Error: GPG
check FAILED (try again with '--nogpgcheck' to ignore)"
I don't think this use case is so important that everybody's security
should be lowered to avoid the minor inconvenience of passing a simple
flag.


Thing is, when manually installing RPMs that don't come from a
repository, 98% of the time they are not expected to be signed by a GPG
key that you have installed, so the check is expected to fail.


The failure indicates that the source and integrity of the RPM is
uncertain. The fact that the user is expected to make a conscious
decision to bypass it when they want to accept that risk, but to be
stopped if they don't want to accept that risk, is the whole point.
So, yes, the check is expected to fail under those circumstances.

As for how common those circumstances are, I just surveyed my Fedora
systems, and 100% of the RPMs I've manually installed, including some
pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as
my own that I've built, all are signed. In my personal experience,
it's rare to come across an unsigned RPM. You may have a different
experience, but the frequency isn't the point... the point is to
provide protection by default and user choice to override and accept
the risks. Right now, we have acceptance of risk by default instead of
protection.


GPG check is just not the right thing to do in this case.


I disagree. I think it *is* the right thing to do to check, and offer
the option to skip the check. That gives users the choice to be
insecure if they want, but leaves the default secure.


If we enable GPG checking when not appropriate,


I disagree that the failure implies that GPG checking isn't
appropriate. I think the fact that an un-bypassed check failed, in
response to an RPM from an unknown or untrusted source, is very
appropriate. The only time it would not be appropriate, in my opinion,
is if the user chose to bypass it.


***we will train users to reflexively ignore GPG errors.***


So, your position is: "don't train users to ignore GPG errors... we'll
ignore them for you" ?!?!

First, I don't agree that this will happen. I think it's more likely
that users who are lax with security will continue to be lax with
security, and users who aren't will pay attention to the failures and
use that as a signal to inform their acceptance of the risks. But
second, even if you're right, the worst case scenario here is the
scenario we already have as the default: the check being ignored by
the user is nearly the same as the check not being performed at all,
which is what's happening today. If you're concerned that GPG errors
will be ignored, I don't understand why you're not concerned with the
fact that the only reason why users aren't seeing those errors today
is because GPG checks aren't running at all! All the same security
risks are still there... including the risks for an invalid or
fraudulent signature when it is present on a local RPM, in addition to
the risks when the signature is missing... they're just being ignored
by default. You're worried about a situation where a user *might*
ignore security check errors... but I'm worried that they are
auto-ignored by the system, before the user even has a chance to take
them seriously.



(We have already trained users to approve importing new GPG keys as
long as they claim to be from Fedora, since this is required every
Fedora release. This is bad enough.)


I don't agree with that either. I verify the signatures of Fedora keys
using https://fedoraproject.org/security and the keys of other repos I
use, and other users who care about security can do the same. I think
Fedora has done as good a job as one can expect, for the most part, in
trying to provide good security to those who care. But, of course,
users have to care first and do their part as well.



GPG check makes sense when installing RPMs from a configured
repository, not when manually installing RPMs from a filesystem path or
URL.


Again, I completely disagree. The check protects against corrupt
and/or malicious software, and is one of the few steps the package
management system has to proactively prevent harm to the user's system
*before* the harm is done. Skipping these checks by default is bad for
software supply chain security, regardless of whether the supply chain
involves a repo or just an RPM. The signatures are in the RPM, and the
keys in the RPM database. The fact that it came from a repo or not is
completely irrelevant for good software supply chain security
defaults.




I completly agree with you. Just wanted to note (as mcatanzaro already 
pointed at). Even when all sec-checks are enabled, the 

Re: DNF5: Checking signatures of packages installed out of a repository?

[Christopher]

On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro  wrote:
>
> On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher
>  wrote:
> > I think for the sake of security, it'd be better if this were on by
> > default, and you just had to specify the --nogpgcheck
> > For convenience, the error message should probably say "Error: GPG
> > check FAILED (try again with '--nogpgcheck' to ignore)"
> > I don't think this use case is so important that everybody's security
> > should be lowered to avoid the minor inconvenience of passing a simple
> > flag.
>
> Thing is, when manually installing RPMs that don't come from a
> repository, 98% of the time they are not expected to be signed by a GPG
> key that you have installed, so the check is expected to fail.

The failure indicates that the source and integrity of the RPM is
uncertain. The fact that the user is expected to make a conscious
decision to bypass it when they want to accept that risk, but to be
stopped if they don't want to accept that risk, is the whole point.
So, yes, the check is expected to fail under those circumstances.

As for how common those circumstances are, I just surveyed my Fedora
systems, and 100% of the RPMs I've manually installed, including some
pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as
my own that I've built, all are signed. In my personal experience,
it's rare to come across an unsigned RPM. You may have a different
experience, but the frequency isn't the point... the point is to
provide protection by default and user choice to override and accept
the risks. Right now, we have acceptance of risk by default instead of
protection.

> GPG check is just not the right thing to do in this case.

I disagree. I think it *is* the right thing to do to check, and offer
the option to skip the check. That gives users the choice to be
insecure if they want, but leaves the default secure.

> If we enable GPG checking when not appropriate,

I disagree that the failure implies that GPG checking isn't
appropriate. I think the fact that an un-bypassed check failed, in
response to an RPM from an unknown or untrusted source, is very
appropriate. The only time it would not be appropriate, in my opinion,
is if the user chose to bypass it.

> ***we will train users to reflexively ignore GPG errors.***

So, your position is: "don't train users to ignore GPG errors... we'll
ignore them for you" ?!?!

First, I don't agree that this will happen. I think it's more likely
that users who are lax with security will continue to be lax with
security, and users who aren't will pay attention to the failures and
use that as a signal to inform their acceptance of the risks. But
second, even if you're right, the worst case scenario here is the
scenario we already have as the default: the check being ignored by
the user is nearly the same as the check not being performed at all,
which is what's happening today. If you're concerned that GPG errors
will be ignored, I don't understand why you're not concerned with the
fact that the only reason why users aren't seeing those errors today
is because GPG checks aren't running at all! All the same security
risks are still there... including the risks for an invalid or
fraudulent signature when it is present on a local RPM, in addition to
the risks when the signature is missing... they're just being ignored
by default. You're worried about a situation where a user *might*
ignore security check errors... but I'm worried that they are
auto-ignored by the system, before the user even has a chance to take
them seriously.

>
> (We have already trained users to approve importing new GPG keys as
> long as they claim to be from Fedora, since this is required every
> Fedora release. This is bad enough.)

I don't agree with that either. I verify the signatures of Fedora keys
using https://fedoraproject.org/security and the keys of other repos I
use, and other users who care about security can do the same. I think
Fedora has done as good a job as one can expect, for the most part, in
trying to provide good security to those who care. But, of course,
users have to care first and do their part as well.

>
> GPG check makes sense when installing RPMs from a configured
> repository, not when manually installing RPMs from a filesystem path or
> URL.

Again, I completely disagree. The check protects against corrupt
and/or malicious software, and is one of the few steps the package
management system has to proactively prevent harm to the user's system
*before* the harm is done. Skipping these checks by default is bad for
software supply chain security, regardless of whether the supply chain
involves a repo or just an RPM. The signatures are in the RPM, and the
keys in the RPM database. The fact that it came from a repo or not is
completely irrelevant for good software supply chain security
defaults.

>
> Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 

[EPEL-devel] EPEL Steering Committee meeting moving to matrix

[Troy Dawson]

At last weeks EPEL Steering Committee meeting it was decided to move from
Libera IRC #fedora-meeting to Fedora Matrix #meeting.[1]

This week (November 15, 2023) will be our first meeting on the new Matrix
channel.

This is the link:
https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org

Documentation changes are still being worked on.

Thank You
EPEL Steering Committee

[1] - This channel was originally called #fedora-meeting, but the 'fedora'
was considered redundant and dropped.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Troy Dawson]

Sorry, I didn't get this updated before the email went out.

We will now be meeting on the Fedora Meeting room on Fedora Matrix

https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org

On Tue, Nov 14, 2023 at 8:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2023-11-15 from 16:00:00 to 17:00:00
> US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
> This is the weekly EPEL Steering Committee Meeting.
>
> A general agenda is the following:
>
> #topic aloha
>
> #topic EPEL Issues https://pagure.io/epel/issues
> * https://pagure.io/epel/issues?tags=meeting=Open
>
> #topic Old Business (if needed)
>
> #topic General Issues / Open Floor
>
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/9854/
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249482] No perl-HTML-Scrubber for EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #7 from Fedora Update System  ---
FEDORA-EPEL-2023-99de16c447 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-99de16c447


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249482

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249482%23c7
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Christopher]

On Tue, Nov 14, 2023 at 9:24 AM Petr Pisar  wrote:
>
> V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
> > On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek  wrote:
> > >
> > > I believe that one of the strong complains was related to not signed 
> > > packages. The use case is that when I build RPMs locally and then I 
> > > install them (see bellow).
> > >
> > > dnf install *.rpm --setopt=localpkg_gpgcheck=true
> > > ...
> > > Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > > signed
> > > Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > > signed
> > > Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > Error: GPG check FAILED
> > >
> > > Jaroslav
> >
> > I think for the sake of security, it'd be better if this were on by
> > default, and you just had to specify the --nogpgcheck
>
> Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of
> them operate independently. That's another painful property of the current
> code and documentation.
>
> -- Petr

Why wouldn't this apply? Both the documentation for 'dnf' and
'dnf.conf' use similar terminology "gpgcheck", and the man page says
"Skip checking GPG signatures on packages (if RPM policy allows)." If
it doesn't apply, it seems like it definitely *should*, for
intuitiveness-sake. At the very least, if it doesn't apply, then the
documentation is seriously deficient.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249633] perl-Time-Out-0.23 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2023-11-14 15:55:29




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249633
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249633] perl-Time-Out-0.23 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Time-Out-0.23-1.fc40



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 40.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249633

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249633%23c1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2023-11-15 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

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

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




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

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

[Bug 2249633] perl-Time-Out-0.23 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249633
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Steve Grubb]

Hello all,

On Tuesday, November 14, 2023 8:16:39 AM EST Christopher wrote:
> On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek 
> wrote:
> >
> > I believe that one of the strong complains was related to not signed
> > packages. The use case is that when I build RPMs locally and then I
> > install them (see bellow).
> >
> > dnf install *.rpm --setopt=localpkg_gpgcheck=true
> > ...
> > Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not
> > signed
 Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is
> > not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm
> > is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is
> > not signed Error: GPG check FAILED
> >
> I think for the sake of security, it'd be better if this were on by
> default, and you just had to specify the --nogpgcheck
> For convenience, the error message should probably say "Error: GPG
> check FAILED (try again with '--nogpgcheck' to ignore)"
> I don't think this use case is so important that everybody's security
> should be lowered to avoid the minor inconvenience of passing a simple
> flag.

It's not just for the sake of security, there are actual security 
requirements that are specified around this for all distributions - no matter 
what the package manager is.

https://commoncriteria.github.io/pp/operatingsystem/operatingsystem-release.html#FPT_TUD_EXT.1.1

There are 2 requirements, one on the metadata that dnf uses to decide if an 
update is available. The metadata must be signed and tested. Pass or fail 
needs to have an audit event that describes what was being done, what failed 
and if any checks are being overridden/bypassed.

The second requirements is on the update installation. It also requires 
auditing that describes what was being done, if the update was successful, 
what about it failed, and if any checks were being bypassed.

librpm has a module that can be installed that provides some of this 
auditing. But if dnf does it's own checks on metadata or the rpm before it 
passes it on to librpm, then it has to do the auditing itself. I would 
recommend making it an optional module so that people not wanting auditing 
are  not impacted by any slow down during upgrades.

But the fact that it requires auditing means there are actual security 
expectations that need to be factored in - such as secure by default. If the 
audit trail shows that the rpms are passing gpg check, but it's not being 
enforced, that will get the attention of the security team.

And while we are talking update security, minimum hash sizes since last year 
are SHA384 and signatures being RSA 3072 and higher (this includes secure 
boot). There is also an expectation of moving away from RSA to quantum 
resistant algorithms in the next couple years. (This also means secure boot, 
too.)

-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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Michael Catanzaro]

On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher 
 wrote:

I think for the sake of security, it'd be better if this were on by
default, and you just had to specify the --nogpgcheck
For convenience, the error message should probably say "Error: GPG
check FAILED (try again with '--nogpgcheck' to ignore)"
I don't think this use case is so important that everybody's security
should be lowered to avoid the minor inconvenience of passing a simple
flag.


Thing is, when manually installing RPMs that don't come from a 
repository, 98% of the time they are not expected to be signed by a GPG 
key that you have installed, so the check is expected to fail. GPG 
check is just not the right thing to do in this case. If we enable GPG 
checking when not appropriate, ***we will train users to reflexively 
ignore GPG errors.***


(We have already trained users to approve importing new GPG keys as 
long as they claim to be from Fedora, since this is required every 
Fedora release. This is bad enough.)


GPG check makes sense when installing RPMs from a configured 
repository, not when manually installing RPMs from a filesystem path or 
URL.


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Petr Pisar]

V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
> On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek  wrote:
> >
> > I believe that one of the strong complains was related to not signed 
> > packages. The use case is that when I build RPMs locally and then I install 
> > them (see bellow).
> >
> > dnf install *.rpm --setopt=localpkg_gpgcheck=true
> > ...
> > Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > signed
> > Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Error: GPG check FAILED
> >
> > Jaroslav
> 
> I think for the sake of security, it'd be better if this were on by
> default, and you just had to specify the --nogpgcheck

Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of
them operate independently. That's another painful property of the current
code and documentation.

-- Petr


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

[Bug 2249633] New: perl-Time-Out-0.23 is available

[bugzilla]

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

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



Releases retrieved: 0.23
Upstream release that is considered latest: 0.23
Current version/release in rawhide: 0.22-1.fc40
URL: http://search.cpan.org/dist/Time-Out/

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://docs.fedoraproject.org/en-US/package-maintainers/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/3468/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249633

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249633%23c0
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Christopher]

On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek  wrote:
>
> I believe that one of the strong complains was related to not signed 
> packages. The use case is that when I build RPMs locally and then I install 
> them (see bellow).
>
> dnf install *.rpm --setopt=localpkg_gpgcheck=true
> ...
> Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Error: GPG check FAILED
>
> Jaroslav

I think for the sake of security, it'd be better if this were on by
default, and you just had to specify the --nogpgcheck
For convenience, the error message should probably say "Error: GPG
check FAILED (try again with '--nogpgcheck' to ignore)"
I don't think this use case is so important that everybody's security
should be lowered to avoid the minor inconvenience of passing a simple
flag.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Nick Clifton]

The warnings mentioned in the blog were added to the 2.39 release of the GNU 
Binutils, so they should potentially be present in the build logs of any 
package built for f38 or later.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Jaroslav Mracek]

I would like to highlight a cool feature of DNF5 - drop-in directory for 
configuration overrides, where distribution may modify configuration of DNF5. 
Why I am mentioning it, because it allows to make a decision by distribution 
and the behavior might be modify outside of DNF5 package. Therefore the 
configuration option `localpkg_gpgcheck` might be modified by a Fedora 
distribution.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Nick Clifton]

You can test for problems by searching the build logs for warnings from the 
linker: 

  "has a LOAD segment with RWX permissions" 
  "has a TLS segment with execute permission"
  "missing .note.GNU-stack section implies executable stack"

There are also two related warning messages, although these would not be 
candidates for conversion into errors because they represent positive action by 
the compiler and/or builder:
 
  "requires executable stack (because the .note.GNU-stack section is 
executable)"
  "enabling an executable stack because of -z execstack command line option"

Alternatively a package builder could add "-Wl,--fatal-warnings" to their final 
compilation command line, which would force all linker warning messages to be 
treated as errors.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

[Jaroslav Mracek]

I believe that one of the strong complains was related to not signed packages. 
The use case is that when I build RPMs locally and then I install them (see 
bellow).

dnf install *.rpm --setopt=localpkg_gpgcheck=true
...
Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
Error: GPG check FAILED

Jaroslav
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249534] perl-Math-BigInt-2.001000 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-Math-BigInt-2.0010.00-
   ||1.fc40
 Status|MODIFIED|CLOSED
Last Closed||2023-11-14 12:15:35



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-770e07708a has been pushed to the Fedora 40 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=2249534

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249534%23c2
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249534] perl-Math-BigInt-2.001000 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-770e07708a has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-770e07708a


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249534

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249534%23c1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249602] perl-Business-ISBN-Data-20231114.001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Business-ISBN-Data-202
   ||31114.001-1.fc40
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2023-11-14 10:12:35



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-f85f4c45b1 has been pushed to the Fedora 40 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=2249602

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249602%23c2
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249602] perl-Business-ISBN-Data-20231114.001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-f85f4c45b1 has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-f85f4c45b1


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249602

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249602%23c1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249456] perl-CGI-Fast-2.17 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-CGI-Fast-2.17-1.fc40
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2023-11-14 09:18:35



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-37ea5f8ec5 has been pushed to the Fedora 40 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=2249456

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249456%23c2
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249456] perl-CGI-Fast-2.17 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-37ea5f8ec5 has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-37ea5f8ec5


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249456

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249456%23c1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249324] perl-Imager-1.020 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Imager-1.020-1.fc40
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2023-11-14 08:57:38



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-2ca68014cf has been pushed to the Fedora 40 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=2249324

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249324%23c2
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249324] perl-Imager-1.020 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-2ca68014cf has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-2ca68014cf


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249324

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249324%23c1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Richard W.M. Jones]

On Mon, Nov 13, 2023 at 07:26:04PM -0800, John Reiser wrote:
> >Also, under what circumstances would thread local storage segments be
> >executable?
> 
> When the assembly-language source contains a statement such as
> .section my_section_name,"atx"
> where the "atx" are the attributes of the ElfXX_Section.

Why would anyone do that?  TLS is used to store data in my experience.

Rich.

> See the key to the abbreviations in the output of
>readelf --sections a.elf
> Namely:
> -
> Key to Flags:
>   W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
>   L (link order), O (extra OS processing required), G (group), T (TLS),
>   C (compressed), x (unknown), o (OS specific), E (exclude),
>   D (mbind), l (large), p (processor specific)
> -
> ___
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2249602] New: perl-Business-ISBN-Data-20231114.001 is available

[bugzilla]

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

Bug ID: 2249602
   Summary: perl-Business-ISBN-Data-20231114.001 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Business-ISBN-Data
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 20231114.001
Upstream release that is considered latest: 20231114.001
Current version/release in rawhide: 20231110.001-1.fc40
URL: https://metacpan.org/dist/Business-ISBN-Data/

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://docs.fedoraproject.org/en-US/package-maintainers/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/2674/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2249602

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249602%23c0
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue