[Test-Announce] Fedora 39 Candidate RC-1.5 Available Now!

[rawhide]

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

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.5_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.5_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.5_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.5_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.5_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.5_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.5_Security_Lab

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

Help is available on #fedora-qa on libera.chat [4], or on the
test list [5].

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

[1] http://fedorapeople.org/groups/schedule/f-39/f-39-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_39_RC_Release_Criteria
[4] https://web.libera.chat/?channels=#fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b4ff3ac6b0   
stb-0-0.39.20231011gitbeebb24.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-7d5cd32373   
chromium-118.0.5993.117-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b951076a0f   
golang-1.19.13-1.el7


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

zabbix6.0-6.0.22-2.el7.1

Details about builds:



 zabbix6.0-6.0.22-2.el7.1 (FEDORA-EPEL-2023-7a61154589)
 Open-source monitoring solution for your IT infrastructure

Update Information:

* Update to 6.0.22 * Add dontaudit SELinux rules for spurious AVC denial
messages (bz#2170630)

ChangeLog:

* Mon Oct 30 2023 Orion Poplawski  - 6.0.22-2.1
- Fix SELinux policy
* Mon Oct 30 2023 Orion Poplawski  - 6.0.22-2
- Add dontaudit SELinux rules for spurious AVC denial messages (bz#2170630)
* Mon Oct 30 2023 Orion Poplawski  - 6.0.22-1
- Update to 6.0.22


___
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

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

[Kevin Fenzi]

FWIW, from what I can recall, yum used to check all packages, but this
resulted in tons of people complaining because they did not want it to
check their local packages. So, a localpkg_gpgcheck option was added and
set to false. dnf4 still has this option.

It's also worth noting that if you pass yum/dnf/dnf5 urls for the
package(s) you want to install, it's not using a repo at all, it's
downloading those packages and treating them as local packages.

kevin


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

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

[Michael J Gruber]

Am Di., 31. Okt. 2023 um 19:31 Uhr schrieb Christopher <
ctubb...@fedoraproject.org>:

> On Tue, Oct 31, 2023 at 1:38 PM Vít Ondruch  wrote:
> >
> >
> > Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
> > > Hello,
> > >
> > > DNF5 got a complaint
> > >  that
> "dnf update
> > > https://...; skips verifying package signatures:
> > >
> > >  $ sudo dnf update
> https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> > >  [...]
> > >  Warning: skipped PGP checks for 2 package(s).
> > >
> > > A DNF5 developer confirmed that old DNF4 does not verify signatures
> too.
> > > The verification happens only for packages comming from a repository.
> Why DNF5
> > > looks bad is because it actually prints the warning and thus keeps the
> user
> > > better informed.
> > >
> > > The nonchecking behavior probably exists to make installing local
> packages
> > > easy. If DNF5 would insist on checking the signatures, Fedora users
> would have
> > > to pass --no-gpgchecks option to their "dnf5" commands to override the
> new
> > > default, or start signing their packages. As always security is not
> easy.
> > >
> > > Because this an old behavior and some users probably depend on it,
> enabling
> > > the verification for all cases looks like an abrupt change.
> > >
> > > I would would like to hear your opinion: Should DNF5 start verifying
> all
> > > packages? Should DNF5 keep ignoring signatures for out-of-repository
> packages?
> > > Or should rather narrow the verification skip to packages from a local
> file
> > > system? Any other options?
> >
> >
> > Or maybe verify what it can and report the packages which can't be
> > verified? You can notice that I was actually installing singed packages.
> >
> > But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I
> > still would swear this used to be needed, that is why I try to install
> > the signed packages.
>
> I could have sworn the same thing. I think that it should be an error
> if any package (it doesn't matter if it is local or not) cannot be
> verified, unless `--nogpgcheck` is specified. This seems like the only
> secure-by-default option. No RPM should be allowed to be installed if
> it can't be verified, unless the user explicitly allows it. If less
> secure options are provided (such as only providing a warning message
> or skipping verification of local RPMs), then an option must be
> provided to force the secure-behavior to prevent the installation of
> any RPMs that haven't been verified (something like
> `--requiregpgcheck`). But my strong preference is that it require GPG
> checks by default. That is the behavior that is implied by the
> existence of the `--nogpgcheck` flag and the non-existence of any
> other related flags.
>

Note that there are few differences between local and repo files here:
- A repo comes with a key specification, i.e. an expected signer; a local
package does not. What signature do you expect? What is the value of "any"
signature?
- A package installed via a repo comes "from the internet" without your
control over the exact download location; a local package has been
downloaded or built specifically by you, with you in control.
Therefore, it does make sense that one has its signature checked and the
other hasn't.

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?

[stan via devel]

On Tue, 31 Oct 2023 16:23:41 +0100
Petr Pisar  wrote:

> I would would like to hear your opinion: Should DNF5 start verifying
> all packages? Should DNF5 keep ignoring signatures for
> out-of-repository packages? Or should rather narrow the verification
> skip to packages from a local file system? Any other options?

I build a local kernel from the src.rpm, and install it with 

dnf -C install [etc.]

I never see this warning (dnf4).  Would I start
seeing it with dnf5?  It is easy enough to add the --no-gpgchecks
option if it is required, and it seems like a good reminder that the
package being installed might be a security risk.  Though, in my
specific case, that isn't true if the fedora src.rpm is valid.  A
pretty safe bet.
___
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?

[Christopher]

On Tue, Oct 31, 2023 at 1:38 PM Vít Ondruch  wrote:
>
>
> Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
> > Hello,
> >
> > DNF5 got a complaint
> >  that "dnf 
> > update
> > https://...; skips verifying package signatures:
> >
> >  $ sudo dnf update 
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> >  
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> >  [...]
> >  Warning: skipped PGP checks for 2 package(s).
> >
> > A DNF5 developer confirmed that old DNF4 does not verify signatures too.
> > The verification happens only for packages comming from a repository. Why 
> > DNF5
> > looks bad is because it actually prints the warning and thus keeps the user
> > better informed.
> >
> > The nonchecking behavior probably exists to make installing local packages
> > easy. If DNF5 would insist on checking the signatures, Fedora users would 
> > have
> > to pass --no-gpgchecks option to their "dnf5" commands to override the new
> > default, or start signing their packages. As always security is not easy.
> >
> > Because this an old behavior and some users probably depend on it, enabling
> > the verification for all cases looks like an abrupt change.
> >
> > I would would like to hear your opinion: Should DNF5 start verifying all
> > packages? Should DNF5 keep ignoring signatures for out-of-repository 
> > packages?
> > Or should rather narrow the verification skip to packages from a local file
> > system? Any other options?
>
>
> Or maybe verify what it can and report the packages which can't be
> verified? You can notice that I was actually installing singed packages.
>
> But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I
> still would swear this used to be needed, that is why I try to install
> the signed packages.

I could have sworn the same thing. I think that it should be an error
if any package (it doesn't matter if it is local or not) cannot be
verified, unless `--nogpgcheck` is specified. This seems like the only
secure-by-default option. No RPM should be allowed to be installed if
it can't be verified, unless the user explicitly allows it. If less
secure options are provided (such as only providing a warning message
or skipping verification of local RPMs), then an option must be
provided to force the secure-behavior to prevent the installation of
any RPMs that haven't been verified (something like
`--requiregpgcheck`). But my strong preference is that it require GPG
checks by default. That is the behavior that is implied by the
existence of the `--nogpgcheck` flag and the non-existence of any
other related flags.
___
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?

[Vít Ondruch]

Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):

Hello,

DNF5 got a complaint
 that "dnf update
https://...; skips verifying package signatures:

 $ sudo dnf update 
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
 
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
 [...]
 Warning: skipped PGP checks for 2 package(s).

A DNF5 developer confirmed that old DNF4 does not verify signatures too.
The verification happens only for packages comming from a repository. Why DNF5
looks bad is because it actually prints the warning and thus keeps the user
better informed.

The nonchecking behavior probably exists to make installing local packages
easy. If DNF5 would insist on checking the signatures, Fedora users would have
to pass --no-gpgchecks option to their "dnf5" commands to override the new
default, or start signing their packages. As always security is not easy.

Because this an old behavior and some users probably depend on it, enabling
the verification for all cases looks like an abrupt change.

I would would like to hear your opinion: Should DNF5 start verifying all
packages? Should DNF5 keep ignoring signatures for out-of-repository packages?
Or should rather narrow the verification skip to packages from a local file
system? Any other options?



Or maybe verify what it can and report the packages which can't be 
verified? You can notice that I was actually installing singed packages.


But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I 
still would swear this used to be needed, that is why I try to install 
the signed packages.



Vít



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

Re: OK to have same license file in multiple sub-packages?

[Kalev Lember]

On Tue, Oct 31, 2023 at 5:47 PM Miroslav Suchý  wrote:

> How it conflicts?
>
> %files
>
> %license LICENSE
>
> %files doc
>
> %license LICENSE
>
> should not create any conflicts. And this is recomended way to do it.
>

I guess the conflicts happen when the LICENSE file changes between builds
and individual subpackages that ship it aren't updated in lock step. Often
there is a full NVR version requirement that locks individual subpackages
together, but not in this case. If people for example download just one of
the subpackages from koji (and not the other), it can lead to only one of
them getting updated.

Neal's idea was to make the conflict explicit so that rpm wouldn't allow
installing the subpackages if they differ in NVR.

-- 
Kalev
___
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 2247279] New: perl-Math-BigInt-2.000000 is available

[bugzilla]

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

Bug ID: 2247279
   Summary: perl-Math-BigInt-2.00 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: 2.00
Upstream release that is considered latest: 2.00
Current version/release in rawhide: 1.9998.42-1.fc40
URL: https://metacpan.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://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/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=2247279

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247279%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, Oct 31, 2023 at 11:57 AM Petr Pisar  wrote:
>
> V Tue, Oct 31, 2023 at 04:32:09PM +0100, Fabio Valentini napsal(a):
> > On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar  wrote:
> > >
> > > Hello,
> > >
> > > DNF5 got a complaint
> > >  that "dnf 
> > > update
> > > https://...; skips verifying package signatures:
> > >
> > > $ sudo dnf update 
> > > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> > >  
> > > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> > > [...]
> > > Warning: skipped PGP checks for 2 package(s).
> > >
> > > A DNF5 developer confirmed that old DNF4 does not verify signatures too.
> > > The verification happens only for packages comming from a repository. Why 
> > > DNF5
> > > looks bad is because it actually prints the warning and thus keeps the 
> > > user
> > > better informed.
> > >
> > > The nonchecking behavior probably exists to make installing local packages
> > > easy. If DNF5 would insist on checking the signatures, Fedora users would 
> > > have
> > > to pass --no-gpgchecks option to their "dnf5" commands to override the new
> > > default, or start signing their packages. As always security is not easy.
> > >
> > > Because this an old behavior and some users probably depend on it, 
> > > enabling
> > > the verification for all cases looks like an abrupt change.
> > >
> > > I would would like to hear your opinion: Should DNF5 start verifying all
> > > packages? Should DNF5 keep ignoring signatures for out-of-repository 
> > > packages?
> > > Or should rather narrow the verification skip to packages from a local 
> > > file
> > > system? Any other options?
> >
> > I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at 
> > all?
> > I mean, if the package isn't associated with a repository (like
> > installing an RPM directly), which GPG key should it even be checked
> > against?
> >
> Against any key already existing in an RPM database (rpm -qa | grep 
> gpg-pubkey).

Does DNF use the repository to verify GPG sigs now? If so, that seems
weird. I would assume they just check against the existing keys in the
RPM database, like Petr said.

I'm actually a bit concerned about this thread, because I assumed DNF4
and DNF5 would check signatures by default today, and that it would
only skip if `--nogpgcheck` was passed as an option. If it sometimes
skips the GPG check without that flag, that seems like a serious
security bug to me. I would expect the same level of signature
verification for both `dnf install mypackage` and `wget mypackage.rpm
&& dnf localinstall mypackage.rpm`.

After all, there is no documented flag to force a GPG signature check,
only the flag to omit the check (`--nogpgcheck`). So, users really
have to rely on the default behavior of always checking GPG signatures
if they want DNF to check them. If DNF is not doing that, that's
really bad, because there's no way for users to force it to check
them.

>
> -- Petr
___
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 2247270] perl-Business-ISBN-Data-20231031.001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Business-ISBN-Data-202
   ||31031.001-1.fc40
Last Closed||2023-10-31 16:46:11



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-7c4625cf10 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=2247270

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247270%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

Re: OK to have same license file in multiple sub-packages?

[Miroslav Suchý]

Dne 31. 10. 23 v 16:10 Tom Stellard napsal(a):

Hi,

I've run into a problem with the cmake package, and I'm trying to figure out how
to solve it.  This issue is that the cmake license files are included in both
the cmake and cmake-doc packages.  This creates a conflict when up trying to
update cmake while an older version of cmake-doc is installed on the system.

What's the best way to fix this?  Should I remove the license file from 
cmake-doc
or should I have cmake-doc Require (or Conflict?) with the cmake package? 


How it conflicts?

%files

%license LICENSE

%files doc

%license LICENSE

should not create any conflicts. And this is recomended way to do it.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
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 2247270] perl-Business-ISBN-Data-20231031.001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247270%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-01 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 2247270] New: perl-Business-ISBN-Data-20231031.001 is available

[bugzilla]

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

Bug ID: 2247270
   Summary: perl-Business-ISBN-Data-20231031.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: 20231031.001
Upstream release that is considered latest: 20231031.001
Current version/release in rawhide: 20231020.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=2247270

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202247270%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?

[Petr Pisar]

V Tue, Oct 31, 2023 at 04:32:09PM +0100, Fabio Valentini napsal(a):
> On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar  wrote:
> >
> > Hello,
> >
> > DNF5 got a complaint
> >  that "dnf 
> > update
> > https://...; skips verifying package signatures:
> >
> > $ sudo dnf update 
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> >  
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> > [...]
> > Warning: skipped PGP checks for 2 package(s).
> >
> > A DNF5 developer confirmed that old DNF4 does not verify signatures too.
> > The verification happens only for packages comming from a repository. Why 
> > DNF5
> > looks bad is because it actually prints the warning and thus keeps the user
> > better informed.
> >
> > The nonchecking behavior probably exists to make installing local packages
> > easy. If DNF5 would insist on checking the signatures, Fedora users would 
> > have
> > to pass --no-gpgchecks option to their "dnf5" commands to override the new
> > default, or start signing their packages. As always security is not easy.
> >
> > Because this an old behavior and some users probably depend on it, enabling
> > the verification for all cases looks like an abrupt change.
> >
> > I would would like to hear your opinion: Should DNF5 start verifying all
> > packages? Should DNF5 keep ignoring signatures for out-of-repository 
> > packages?
> > Or should rather narrow the verification skip to packages from a local file
> > system? Any other options?
> 
> I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at 
> all?
> I mean, if the package isn't associated with a repository (like
> installing an RPM directly), which GPG key should it even be checked
> against?
> 
Against any key already existing in an RPM database (rpm -qa | grep gpg-pubkey).

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

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

[Fabio Valentini]

On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar  wrote:
>
> Hello,
>
> DNF5 got a complaint
>  that "dnf update
> https://...; skips verifying package signatures:
>
> $ sudo dnf update 
> https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
>  
> https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> [...]
> Warning: skipped PGP checks for 2 package(s).
>
> A DNF5 developer confirmed that old DNF4 does not verify signatures too.
> The verification happens only for packages comming from a repository. Why DNF5
> looks bad is because it actually prints the warning and thus keeps the user
> better informed.
>
> The nonchecking behavior probably exists to make installing local packages
> easy. If DNF5 would insist on checking the signatures, Fedora users would have
> to pass --no-gpgchecks option to their "dnf5" commands to override the new
> default, or start signing their packages. As always security is not easy.
>
> Because this an old behavior and some users probably depend on it, enabling
> the verification for all cases looks like an abrupt change.
>
> I would would like to hear your opinion: Should DNF5 start verifying all
> packages? Should DNF5 keep ignoring signatures for out-of-repository packages?
> Or should rather narrow the verification skip to packages from a local file
> system? Any other options?

I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at all?
I mean, if the package isn't associated with a repository (like
installing an RPM directly), which GPG key should it even be checked
against?

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

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

[Petr Pisar]

Hello,

DNF5 got a complaint
 that "dnf update
https://...; skips verifying package signatures:

$ sudo dnf update 
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
 
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
[...]
Warning: skipped PGP checks for 2 package(s).

A DNF5 developer confirmed that old DNF4 does not verify signatures too.
The verification happens only for packages comming from a repository. Why DNF5
looks bad is because it actually prints the warning and thus keeps the user
better informed.

The nonchecking behavior probably exists to make installing local packages
easy. If DNF5 would insist on checking the signatures, Fedora users would have
to pass --no-gpgchecks option to their "dnf5" commands to override the new
default, or start signing their packages. As always security is not easy.

Because this an old behavior and some users probably depend on it, enabling
the verification for all cases looks like an abrupt change.

I would would like to hear your opinion: Should DNF5 start verifying all
packages? Should DNF5 keep ignoring signatures for out-of-repository packages?
Or should rather narrow the verification skip to packages from a local file
system? Any other options?

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

Re: OK to have same license file in multiple sub-packages?

[Neal Gompa]

On Tue, Oct 31, 2023 at 11:10 AM Tom Stellard  wrote:
>
> Hi,
>
> I've run into a problem with the cmake package, and I'm trying to figure out 
> how
> to solve it.  This issue is that the cmake license files are included in both
> the cmake and cmake-doc packages.  This creates a conflict when up trying to
> update cmake while an older version of cmake-doc is installed on the system.
>
> What's the best way to fix this?  Should I remove the license file from 
> cmake-doc
> or should I have cmake-doc Require (or Conflict?) with the cmake package?
>

Add "Conflicts: cmake < %{version}-%{release}" to the doc subpackage and
"Conflicts: cmake-doc < %{version}-%{release}" to the main package.




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

OK to have same license file in multiple sub-packages?

[Tom Stellard]

Hi,

I've run into a problem with the cmake package, and I'm trying to figure out how
to solve it.  This issue is that the cmake license files are included in both
the cmake and cmake-doc packages.  This creates a conflict when up trying to
update cmake while an older version of cmake-doc is installed on the system.

What's the best way to fix this?  Should I remove the license file from 
cmake-doc
or should I have cmake-doc Require (or Conflict?) with the cmake package?

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

Re: Does a change approved for f39 need reapproval for f40?

[Aoife Moloney]

Hi Jonathan,

Sorry this (among other things Im sure) fell through the cracks while we
were without a Fedora Program Manager :(

I will re-announce this on discourse as this is how the process for a
change targeting F40 goes, and open a new ticket to FESCo after about a
week or so, and thank you for cleaning up the wiki, it makes it much easier
to see the discussion surrounding the change from its initial proposal for
F39 by separating it out in the Current Status section. I'll remove the
discussion links, tracker bug and fesco ticket for the F40 section and
re-add with F40 links.


Kindest regards,
Aoife

On Mon, Oct 30, 2023 at 3:16 PM Neal Gompa  wrote:

> On Mon, Oct 30, 2023 at 10:55 AM Jonathan Wakely 
> wrote:
> >
> > On Mon, 30 Oct 2023 at 14:24, Ian McInerney via devel
> >  wrote:
> > >
> > >
> > >
> > > On Mon, Oct 30, 2023 at 2:06 PM Jonathan Wakely 
> wrote:
> > >>
> > >> Well it looks like I took too long to do the deferral to F40, and so
> > >> FESCO dropped the change:
> > >> https://pagure.io/fesco/issue/3059#comment-875144
> > >>
> > >> So now do I need to re-submit as a fresh change for F40?
> > >
> > >
> > > My reading of the email replies to the FESCO minutes when they
> announced this (
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E3M624WQFJV4L5NCJBA3UC746Z7BWNO5/#TMIPXR25CJR72BUMXHKTVICUKVUU5REM)
> is that they want an entirely new change proposal for it... since they
> apparently didn't think anyone was working on it and that it was completely
> abandoned even though you had emailed that you were working on it.
> >
> > Drat. I finally have some time to pick up the work on it (having
> > inherited the change from trodgers after he left) and now I can't do
> > it! That's kinda annoying, as I had mailed the list about it. I
> > probably should have updated the change to make myself the owner.
> >
> > Fingers crossed I'll still be able to make time for it after it gets
> > re-approved. I'll submit a new change.
>
> If it's substantially the same, just update the wiki page and ask
> Aoife to create the FESCo ticket so we can approve it again.
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>

-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
___
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

[EPEL-devel] Re: Upgrade of mlpack in epel-7

[Troy Dawson]

On Mon, Oct 30, 2023 at 11:10 PM Benson Muite 
wrote:

> On 10/30/23 16:37, Troy Dawson wrote:
> > On Sun, Oct 29, 2023 at 10:35 AM Benson Muite
> > mailto:benson_mu...@emailplus.org>> wrote:
> >
> > Would like to upgrade mlpack from 3.4.2 to 4.2.1
> > Version 3 is no longer maintained, and there do not seem to be
> > dependencies on mlpack, at least in Fedora. This is prompted by
> > CVE-2021-28021, CVE-2021-42715, CVE-2021-42716, and CVE-2022-28041
> > https://src.fedoraproject.org/rpms/mlpack/pull-request/12
> > 
> >
> >
> > Since this is for a CVE, that is good.
> > Also, it looks like nothing depends on it, so that also makes things
> easier.
> >
> > Do you know of any features that were removed between version 3.x and
> 4.x?
> > In short, if someone were actively using version 3.x of mlpack, do you
> > know what they would need to change (if anything) to use the version 4.x?
> >
> The biggest change is that for development it became a header only
> library that requires C++14.  Had not realized non breaking changes
> should not be made, so the spec file is for version 4, but it does not
> build and so version 3.4.2 is still shipped.  Can revert changes in git
> history so that 3.4.2 is used, and update requirements on included stb
> header files if that is allowed.
>

If that is possible, and it fixes the CVE's, that would be best.

If you find that it isn't possible, or it doesn't fix the CVE's, then an
exception can be made.
Part of the exception process is to say what changes between the versions,
so people are prepared.
Having the list of things that change is also good when bugs get opened, we
can point them to that list.

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

Fedora rawhide compose report: 20231031.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20231030.n.0
NEW: Fedora-Rawhide-20231031.n.0

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  6
Dropped packages:0
Upgraded packages:   96
Downgraded packages: 0

Size of added packages:  1.01 MiB
Size of dropped packages:0 B
Size of upgraded packages:   4.69 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20231031.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20231031.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20231031.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231031.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: ls-qpack-2.5.3-1.fc40
Summary: QPACK compression library for use with HTTP/3
RPMs:ls-qpack ls-qpack-devel
Size:624.98 KiB

Package: rust-colored_json2-2.1.0-1.fc40
Summary: Colorize JSON, for printing it out on the command line
RPMs:rust-colored_json2+default-devel rust-colored_json2-devel
Size:26.39 KiB

Package: rust-h3-0.0.2-1.fc40
Summary: Async HTTP/3 implementation
RPMs:rust-h3+default-devel rust-h3-devel
Size:103.62 KiB

Package: rust-jql-parser-7.0.4-1.fc40
Summary: Parser for jql - the JSON Query Language tool
RPMs:rust-jql-parser+default-devel rust-jql-parser-devel
Size:27.39 KiB

Package: rust-quinn-proto-0.10.5-1.fc40
Summary: State machine for the QUIC transport protocol
RPMs:rust-quinn-proto+arbitrary-devel rust-quinn-proto+default-devel 
rust-quinn-proto+log-devel rust-quinn-proto+native-certs-devel 
rust-quinn-proto+ring-devel rust-quinn-proto+rustls-devel 
rust-quinn-proto+rustls-native-certs-devel rust-quinn-proto+tls-rustls-devel 
rust-quinn-proto-devel
Size:217.35 KiB

Package: rust-quinn-udp-0.4.1-1.fc40
Summary: UDP sockets with ECN information for the QUIC transport protocol
RPMs:rust-quinn-udp+default-devel rust-quinn-udp+log-devel 
rust-quinn-udp-devel
Size:38.40 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  annobin-12.29-1.fc40
Old package:  annobin-12.28-1.fc40
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-libannocheck 
annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm
Size: 5.41 MiB
Size change:  -22.90 KiB
Changelog:
  * Mon Oct 30 2023 Nick Clifron   - 12.29-1
  - Fix atexit test failure.
  - Notes: Add support for string format notes.


Package:  bcftools-1.15.1-6.fc40
Old package:  bcftools-1.15.1-5.fc39
Summary:  Tools for genomic variant calling and manipulating VCF/BCF files
RPMs: bcftools
Size: 2.56 MiB
Size change:  -2.03 KiB
Changelog:
  * Sat Oct 28 2023 Benson Muite  - 1.15.1-6
  - Use SPDX license identifier


Package:  buildah-1.32.1-1.fc40
Old package:  buildah-1.32.0-1.fc40
Summary:  A command line tool used for creating OCI Images
RPMs: buildah buildah-tests
Size: 147.91 MiB
Size change:  54.70 KiB
Changelog:
  * Tue Oct 24 2023 Packit  - 1.32.1-1
  - [packit] 1.32.1 upstream release


Package:  c4core-0.1.11-14.fc40
Old package:  c4core-0.1.11-13.fc39
Summary:  C++ core utilities
RPMs: c4core c4core-devel
Size: 645.27 KiB
Size change:  1.18 KiB
Changelog:
  * Mon Oct 30 2023 Benjamin A. Beasley  - 0.1.11-14
  - Break a long line in the spec file


Package:  caddy-2.7.5-1.fc40
Old package:  caddy-2.7.4-1.fc40
Summary:  Web server with automatic HTTPS
RPMs: caddy
Size: 44.90 MiB
Size change:  339.62 KiB
Changelog:
  * Mon Oct 30 2023 Carl George  - 2.7.5-1
  - Update to version 2.7.5
  - Update poweredby logos
  - Add symlink for system_noindex_logo.png on EL9
  - Symlink directly to fedora-testpage directory on Fedora


Package:  cereal-1.3.2-4.fc40
Old package:  cereal-1.3.2-4.fc39
Summary:  A header-only C++11 serialization library
RPMs: cereal-devel
Size: 1.09 MiB
Size change:  508 B

Package:  cldr-emoji-annotation-1:44-1.fc40
Old package:  cldr-emoji-annotation-1:44~beta2-1.fc40
Summary:  Emoji annotation files in CLDR
RPMs: cldr-emoji-annotation cldr-emoji-annotation-devel 
cldr-emoji-annotation-dtd
Size: 7.73 MiB
Size change:  -3.87 KiB
Changelog:
  * Tue Oct 31 2023 Takao Fujiwara  - 1:44
  - Bump to release-44


Package:  community-mysql-8.0.35-1.fc40
Old package:  community-mysql-8.0.34-2.fc40
Summary:  MySQL client programs and shared libraries
RPMs: community-mysql community-mysql-common community-mysql-devel 
community-mysql-errmsg community-mysql-libs community-mysql-server 
community-mysql-test
Size: 1.45 GiB
Size change:  -6.34 MiB
Changelog

Re: Forester project - Anaconda kickstart with Redfish

[Lukas Zapletal]

> Could you do some compare and contrast with cobbler?

Sure, Forester is focused on image-based provisioning it does not (and probably 
never will) support traditional RPM installation like Cobbler. This is an 
experiment targeted on those who would like to apply cloud provisioning 
workflow in their own bare-metal (or virtualized) datacenter. It currently 
supports "liveimg" Anaconda provisioning and support for 
"ostreesetup/ostreecontainer" is planned. Instead of managing repositories of 
any kind, you just upload an image into Forester and deploy it, similarly to 
IaaS clouds.

Now, it might not be clear what these features of Anaconda do so let me 
explain. With various tools (for example osbuilder or lorax), you can create a 
Fedora OS image that is in various formats (AMI, qcow2, raw and ISO). The last 
mentioned is actually a bootable Anaconda-based installer that contains a 
tarball with the OS, Anaconda in this case partitions disks and copy the files. 
In case of OSTree it is similar but the content is not a tarball but a OSTree 
repository.

> Because what I would really like to see is more people helping out with 
> cobbler development.

I spent over a decade maintaining Satellite 6 provisioning capabilities which 
take similar approach as Cobbler (PXE, DHCP and repositories management), 
however, I want to explore a different workflow which is not based on DHCP 
management (which does not work with IPv6), not based on PXE (UEFI HTTP Boot 
leverages TCP/HTTP/TLS stack in modern firmware) and not based on any kind of 
repository management.

Forester is different, it has no ambitions to replace Cobbler or Satellite 6 it 
is purely just an Anaconda image deployer over network. One of the main theme 
is that Forester is easy to configure - no need to set up PXE, DHCP is optional 
and thanks to Redfish and UEFI HTTP Boot feature, it is extremely simple to use.

Thanks for the feedback! 

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

Heads-up: python-probeinterface 0.2.18 coming to Rawhide

[Ben Beasley]

In one week, 2023-11-07, or slightly later, I plan to update 
python-probeinterface to 0.2.18 in Rawhide[1]. This release contains 
some small breaking API changes[2]; in particular, the 
with_channel_index argument is removed from plot_probe. Since 
python-probeinterface is currently a leaf package, this will have no 
impact on other packages.


[1] https://src.fedoraproject.org/rpms/python-probeinterface/pull-request/3

[2] 
https://github.com/SpikeInterface/probeinterface/blob/0.2.18/doc/releases/0.2.18.rst


___
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

Fedora 39 compose report: 20231031.n.0 changes

[Fedora Branched Report]

OLD: Fedora-39-20231030.n.0
NEW: Fedora-39-20231031.n.0

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

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

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

= ADDED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-39-20231031.n.0.iso
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-39-20231031.n.0.iso

= DROPPED IMAGES =
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-39-20231030.n.0.ppc64le.qcow2
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-39-20231030.n.0.ppc64le.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  golang-github-altree-bigfloat-0.2.0-1.fc39
Old package:  golang-github-altree-bigfloat-0-0.2.20230330git38c8b72.fc39
Summary:  Additional operations for the standard library big.Float type
RPMs: golang-github-altree-bigfloat-devel
Size: 21.38 KiB
Size change:  -3.01 KiB
Changelog:
  * Mon Sep 25 2023 Pavel Solovev  - 0.2.0-1
  - update to 0.2.0


Package:  golang-github-seancfoley-bintree-1.2.3-1.fc39
Old package:  golang-github-seancfoley-bintree-1.2.1-2.fc39
Summary:  Binary trees and tries
RPMs: golang-github-seancfoley-bintree-devel
Size: 37.63 KiB
Size change:  1.11 KiB
Changelog:
  * Mon Sep 25 2023 Pavel Solovev  - 1.2.3-1
  - update to 1.2.3


Package:  golang-github-seancfoley-ipaddress-1.5.5-1.fc39
Old package:  golang-github-seancfoley-ipaddress-1.5.4-3.fc39
Summary:  Go library for handling IP addresses and subnets, both IPv4 and 
IPv6
RPMs: golang-github-seancfoley-ipaddress-devel
Size: 413.71 KiB
Size change:  7.00 KiB
Changelog:
  * Mon Sep 25 2023 Pavel Solovev  - 1.5.5-1
  - update to 1.5.5


Package:  kitty-0.30.1-2.fc39
Old package:  kitty-0.30.0-1.fc39
Summary:  Cross-platform, fast, feature full, GPU based terminal emulator
RPMs: kitty kitty-doc kitty-kitten kitty-shell-integration 
kitty-terminfo
Added RPMs:   kitty-kitten
Size: 30.46 MiB
Size change:  146.81 KiB
Changelog:
  * Mon Oct 02 2023 Pavel Solovev  - 0.30.0-2
  - split out kitten
  - clarify licenses for subpackages

  * Tue Oct 03 2023 Pavel Solovev  - 0.30.0-3
  - fix overflow when GLFW_IM_MODULE=ibus is set

  * Thu Oct 05 2023 Pavel Solovev  - 0.30.1-1
  - version 0.30.1



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

[Bug 2246640] perl-Data-TreeDumper-Renderer-GTK-0.03 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2246640
___
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 2241707] perl-Apache-DBI-Cache-0.08-46.fc40 FTBFS: DBI connect('f_dir=tmp1','',...) failed: No such directory 'tmp1 at /builddir/build/BUILD/Apache-DBI-Cache-0.08/blib/lib/Apache/DBI/Cache.pm lin

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Apache-DBI-Cache-0.08-
   ||47.fc40
Last Closed||2023-10-31 08:49:12



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-edf79a6dca 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=2241707

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202241707%23c3
___
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 2241707] perl-Apache-DBI-Cache-0.08-46.fc40 FTBFS: DBI connect('f_dir=tmp1','',...) failed: No such directory 'tmp1 at /builddir/build/BUILD/Apache-DBI-Cache-0.08/blib/lib/Apache/DBI/Cache.pm lin

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202241707%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

[EPEL-devel] Re: Upgrade of mlpack in epel-7

[Benson Muite]

On 10/30/23 16:37, Troy Dawson wrote:
> On Sun, Oct 29, 2023 at 10:35 AM Benson Muite
> mailto:benson_mu...@emailplus.org>> wrote:
> 
> Would like to upgrade mlpack from 3.4.2 to 4.2.1
> Version 3 is no longer maintained, and there do not seem to be
> dependencies on mlpack, at least in Fedora. This is prompted by
> CVE-2021-28021, CVE-2021-42715, CVE-2021-42716, and CVE-2022-28041
> https://src.fedoraproject.org/rpms/mlpack/pull-request/12
> 
> 
> 
> Since this is for a CVE, that is good.
> Also, it looks like nothing depends on it, so that also makes things easier.
> 
> Do you know of any features that were removed between version 3.x and 4.x?
> In short, if someone were actively using version 3.x of mlpack, do you
> know what they would need to change (if anything) to use the version 4.x?
> 
The biggest change is that for development it became a header only
library that requires C++14.  Had not realized non breaking changes
should not be made, so the spec file is for version 4, but it does not
build and so version 3.4.2 is still shipped.  Can revert changes in git
history so that 3.4.2 is used, and update requirements on included stb
header files if that is allowed.
> Troy
> 
> 
> ___
> 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