[Bug 2124507] Please branch and build perl-X11-Protocol in epel9.

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124507
___
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 2124460] Pleadse branch and build perl-Crypt-SSLeay in epel9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124460
___
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: Inactive packagers to be removed after the F37 release

[Tomasz Torcz]

On Tue, Sep 06, 2022 at 04:14:52PM -0500, Jonathan Wright via devel wrote:
> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel <
> devel@lists.fedoraproject.org> wrote:
> 
> > On 06/09/2022 19:49, Michael Catanzaro wrote:
> > > Of course, hardware authenticators would be even more secure, and it
> > > sure seems pretty reasonable to expect that people with commit access to
> > > Fedora packages are able to purchase a $25 or 30€ security key [1][2].
> >
> > Having to pay even $25 for a hobby project is not acceptable, IMO. If
> > you want to enforce such a policy, find sponsors and buy devices for all
> > Fedora contributors.
> >
> Fedora must be looked at as more than just a "hobby project" even though it
> is a hobby for some.
> 
> It's an OS that many rely on and $25 is a somewhat trivial cost for
> improved security.

  What more, this cost would be amortized over multiple projects.  One
hardware key can be used with any number of projects and personal
accounts.


-- 
Tomasz Torcz  “If you try to upissue this patchset I shall be 
seeking
to...@pipebreaker.pl   an IP-routable hand grenade.”  — Andrew Morton (LKML)
___
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: Inactive packagers to be removed after the F37 release

[Maxwell G via devel]

On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote:
> > mobile device
> 
> Requires proprietary Google services.

As has already been said, that's not true. Google Authenticator is far from 
the only software that supports the TOTP standard.

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

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

Re: Inactive packagers to be removed after the F37 release

[Maxwell G via devel]

On Tuesday, September 6, 2022 Michael Catanzaro wrote:
> Currently I do not have any 2FA enabled
> on my Fedora account

I have 2FA set up on my account and it works okay. You'd use `fkinit` instead 
of `kinit` that requires special setup[1] to work with 2FA. It doesn't work 
with the GOA kerberos integration. When authenticating with Fedora online 
services, there's a field for the token just like on any other site that 
supports 2FA.

> because there's no way to disable it once enabled,
> and I'm afraid something will break, so I'm not brave enough to opt in.
> I highly doubt I'm alone here.

I'd guess that Infrastructure could disable it for you if you enable it and 
then change your mind.

[1]: https://fedoraproject.org/wiki/Infrastructure/
Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure
-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

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

Re: Inactive packagers to be removed after the F37 release

[Maxwell G via devel]

On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote:
> If
> you want to enforce such a policy, find sponsors and buy devices for all
> Fedora contributors.

I kind of agree with this. See what PyPi is doing[1]. I don't think anyone who 
maintains one package should get one, but perhaps provenpackagers or those who 
maintain more than X packages should be required to have *some kind* of MFA 
enabled.

[1]: https://pypi.org/security-key-giveaway/

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

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

[EPEL-devel] Re: EPEL: packaging multiple versions and compat packages

[Carl George]

On Mon, Sep 5, 2022 at 2:22 PM Mark E. Fuller  wrote:
>
> Hi all,
>
> Can someone point me to a good resource on how (if permitted) I can make
> appropriate compat(?) packages to allow for two major versions of the
> same package to be available?
> Is this allowed for EPEL?
>
> Thanks
>
> --
> Mark E. Fuller, Ph.D.
> ful...@fedoraproject.org
> ful...@mefuller.dev
> @fuller:fedora.im
> @fuller:one.ems.host
> https://www.stossrohr.net
> PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

For naming of the package, please follow the Fedora guidelines for
"Multiple packages with the same base name".  You'll find many other
styles of naming these kind of packages, both in RHEL and EPEL, but
please stick with the current Fedora guidelines on this.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

Also make sure your package name and none of the files in your package
conflict with anything shipped in RHEL.  This may require manually
renaming some files.

https://docs.fedoraproject.org/en-US/epel/epel-policy/#package_maintenance_and_update_policy

Once you have a working spec file, you can request a dist-git repo
with the exception flag because it would fall under the second bullet
point for exceptions.

https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

If the package is intended to be EPEL-only, make sure to retire the
rawhide branch.

-- 
Carl George
___
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: EPEL: packaging multiple versions and compat packages

[Carl George]

On Mon, Sep 5, 2022 at 2:22 PM Mark E. Fuller  wrote:
>
> Hi all,
>
> Can someone point me to a good resource on how (if permitted) I can make
> appropriate compat(?) packages to allow for two major versions of the
> same package to be available?
> Is this allowed for EPEL?
>
> Thanks
>
> --
> Mark E. Fuller, Ph.D.
> ful...@fedoraproject.org
> ful...@mefuller.dev
> @fuller:fedora.im
> @fuller:one.ems.host
> https://www.stossrohr.net
> PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
> ___
> 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

For naming of the package, please follow the Fedora guidelines for
"Multiple packages with the same base name".  You'll find many other
styles of naming these kind of packages, both in RHEL and EPEL, but
please stick with the current Fedora guidelines on this.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

Also make sure your package name and none of the files in your package
conflict with anything shipped in RHEL.  This may require manually
renaming some files.

https://docs.fedoraproject.org/en-US/epel/epel-policy/#package_maintenance_and_update_policy

Once you have a working spec file, you can request a dist-git repo
with the exception flag because it would fall under the second bullet
point for exceptions.

https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

If the package is intended to be EPEL-only, make sure to retire the
rawhide branch.

-- 
Carl George
___
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

[Test-Announce] Fedora 37 Candidate Beta-1.5 Available Now!

[rawhide]

According to the schedule [1], Fedora 37 Candidate Beta-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/37

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_37_Beta_1.5_Summary

The individual test result pages are:

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

All Beta priority test cases for each of these test pages [2] must
pass in order to meet the Beta 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-37/f-37-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_37_Beta_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

Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Sep 06, 2022 at 02:28:39PM -0400, Ben Cotton wrote:

== Benefit to Fedora ==
=== Packager Benefits ===
* No more modules to maintain.
* Availability of multiple Node.js versions in the buildroot means
that other `nodejs-*` packages can test against multiple supported
options.

== Scope ==
* Other developers:
There should be no need to change any dependent packages, though
packagers of Node.js software may wish to take advantage of the
testing opportunities afforded.


How would I, as a packager, deal with this? Will RPM macros be changed? 
Should we start to build nodejs-XY-$package similar to how we have 
python3-$package (and previously python2-$package) from the source 
package python-$package?


What will the new RPM provides be? today it's simply npm($package) but I 
can imagine you want to change that to something versioned too.

___
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: Inactive packagers to be removed after the F37 release

[Alex Perez]

Jonathan,

Your perspective on costs seems extremely developed-country-centric, and
I'd like to suggest you check your (financial) privilege. I don't know
where you're from; I'm from the US, but I am well aware of the reality
of many open source contributors from countries where the exchange rate
against the US dollar is awful.

You may not see this sort of cost as a barrier to contribution, but I
can assure you that other casual contributors may, and likely would. You
have to realize that the cost of the token isn't necessarily the only
factor that contributes to the overall cost of obtaining such a device.
International shipping costs can easily triple this dollar amount, to
say nothing of other associated costs such as import duties, etc. There
are plenty of countries where such tokens are not domestically
available, and must be shipped from abroad.

This just isn't as simple or straightforward as you seem to want it to
be. Erecting financial barriers to contribution is dangerous, and has
unintended consequences.

Respectfully,
Alex Perez

Jonathan Wright via devel wrote on 9/6/22 2:14 PM:
>
>
> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel
> mailto:devel@lists.fedoraproject.org>>
> wrote:
>
> On 06/09/2022 19:49, Michael Catanzaro wrote:
> > Of course, hardware authenticators would be even more secure,
> and it
> > sure seems pretty reasonable to expect that people with commit
> access to
> > Fedora packages are able to purchase a $25 or 30€ security key
> [1][2].
>
> Having to pay even $25 for a hobby project is not acceptable, IMO. If
> you want to enforce such a policy, find sponsors and buy devices
> for all
> Fedora contributors.
>
> Fedora must be looked at as more than just a "hobby project" even
> though it is a hobby for some.
>
> It's an OS that many rely on and $25 is a somewhat trivial cost for
> improved security.
>
> With your suggestion of sponsors to cover such devices - how does that
> work for new packagers?  It seems pretty impossible to do such a thing
> and tons of money would simply be wasted on packagers that did very
> little to nothing after becoming a packager.
>
>
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.org
> )
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> -- 
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat 
>
>
> ___
> 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 -- 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: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Adam Williamson]

On Tue, 2022-09-06 at 14:28 -0400, Ben Cotton wrote:
> 
> == Scope ==
> * Proposal owners:
> 
> DNF5 is still in the development and some of the features or options
> are not yet available. We still have to finish the implementation of
> Modularity, storing internal data related to History and System State,
> and also documentation and man pages. DNF5 can be tested from
> repository with upstream nightly builds -
> https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/.
> The project's github repository is here -
> https://github.com/rpm-software-management/dnf5/
> 
> * Other developers:
> * Release engineering: [https://pagure.io/releng/issues #Releng issue number]

[snip]

> == Dependencies ==
> There is a long list of dependent packages
> 
> === dnf ===
> 
>  auter
>  calamares
>  copr-builder
>  cpanspec
>  dnf-plugin-diff
>  dnfdragora
>  etckeeper-dnf
>  fedora-review
>  fedora-upgrade
>  kiwi-systemdeps-core
>  libdnf-plugin-subscription-manager
>  lpf
>  mock
>  osbuild
>  perl-CPAN-Plugin-Sysdeps
>  policycoreutils-devel
>  rbm
>  subscription-manager
>  supermin
>  system-config-language
> 
> === python3-dnf ===
> 
>  anaconda-core
>  dnf-plugin-ovl
>  dnfdaemon
>  fedora-easy-karma
>  fedora-review
>  lorax
>  mock-core-configs
>  module-build-service
>  modulemd-tools
>  needrestart
>  pungi
>  python3-bodhi-client
>  python3-dnf-plugin-cow
>  python3-dnf-plugin-flunk_dependent_remove
>  python3-imgcreate
>  python3-libreport
>  retrace-server
>  system-config-language
> 
> === libdnf ===
> 
>  PackageKit
>  copr-builder
>  gnome-software-rpm-ostree
>  libdnf-plugin-subscription-manager
>  libdnf-plugin-swidtags
>  libdnf-plugin-txnupd
> 
> === python3-hawkey ===
> 
>  mock-core-configs
>  modulemd-tools
>  python3-rpmdeplint
>  retrace-server

So, I feel like it's an issue that we have this huge list of
dependencies of the current implementation, but up there under "Other
developers:" in the Scope section, there is nothing.

The list of dependencies implies a fairly considerable amount of work
is going to be necessary on the part of "other developers" to adapt all
of these dependencies to dnf5. A lot of those dependencies are very
important - they are core components of how we work on, build, and use
Fedora.

I think this Change needs explicit buy-in from the maintainers of
dependent packages, and a clear plan and timeline for how those
packages will be ported to dnf5 such that the Change can land smoothly
in F39 timeframe.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Inactive packagers to be removed after the F37 release

[Jonathan Wright via devel]

On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 06/09/2022 19:49, Michael Catanzaro wrote:
> > Of course, hardware authenticators would be even more secure, and it
> > sure seems pretty reasonable to expect that people with commit access to
> > Fedora packages are able to purchase a $25 or 30€ security key [1][2].
>
> Having to pay even $25 for a hobby project is not acceptable, IMO. If
> you want to enforce such a policy, find sponsors and buy devices for all
> Fedora contributors.
>
Fedora must be looked at as more than just a "hobby project" even though it
is a hobby for some.

It's an OS that many rely on and $25 is a somewhat trivial cost for
improved security.

With your suggestion of sponsors to cover such devices - how does that work
for new packagers?  It seems pretty impossible to do such a thing and tons
of money would simply be wasted on packagers that did very little to
nothing after becoming a packager.

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


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
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: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 06/09/2022 19:49, Michael Catanzaro wrote:
Of course, hardware authenticators would be even more secure, and it 
sure seems pretty reasonable to expect that people with commit access to 
Fedora packages are able to purchase a $25 or 30€ security key [1][2].


Having to pay even $25 for a hobby project is not acceptable, IMO. If 
you want to enforce such a policy, find sponsors and buy devices for all 
Fedora contributors.


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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 06/09/2022 20:28, Ben Cotton wrote:

The new DNF5 will provide a symlink to `/usr/bin/dnf` therefore users
will see the replacement as an upgrade of DNF with limited but
documented syntax changes. The DNF5 will provide some compatible
aliases of commands and options to improve adoption of the DNF5.


Why not just update existing dnf packages to version 5?

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

[Bug 2115214] perl-Database-DumpTruck-1.2-24.fc37 FTBFS: Failed test 'Proper data was retrieved from the database' with JSON::PP 4.11

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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=2115214
___
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: rpm with sequoia pgp

[Simo Sorce]

On Tue, 2022-09-06 at 11:09 +0300, Panu Matilainen wrote:
> On 9/2/22 17:31, Neal H. Walfield wrote:
> > Hi all,
> > 
> > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
> > Sequoia PGP.
> > 
> >https://rpm.org/wiki/Releases/4.18.0
> >https://sequoia-pgp.org/
> > 
> > Thanks to Fabio Valentini (decathorpe) for packaging not only
> > rpm-sequoia, but all of the Sequoia packages for Fedora.
> > 
> >
> > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/
> > 
> > 
> > With this note, I'd firstly like to make the Fedora community more
> > aware of this project.  (I don't think it has been mentioned here
> > yet.)
> > 
> > Second, although the internal OpenPGP backend is still the default
> > backend, it will be removed in rpm 4.19:
> > 
> >https://github.com/rpm-software-management/rpm/issues/1935
> 
> While that was the initial goal, I suspect we may have to stretch this a 
> bit. I think we'll first need a release where the upstream default is 
> something else, and then in the next release we can actually look at 
> axing it.
> 
> > 
> > It is probably best to start the transition as soon as possible to
> > work out any kinks.
> > 
> > In that vein, I'd like to offer my help.  Making this type of change
> > needs to be done carefully.  Perhaps these are questions or concerns.
> > I'd like to hear them and respond to them.  There is also technical
> > work that needs to be done.  I'm more of a developer than a packager,
> > but if Fedora decides to use the Sequoia backend, I'd like to offer my
> > help in any way I can.
> 
> Since rpm 4.18 gained the Sequoia support afterall, we can and should 
> look into swapping over in Fedora 38. That'll help sorting out any rough 
> edges and make it easier to eventually swap the default in upstream as 
> well. We probably need to do this with a change process as anything 
> rpm-related tends to be system/distro wide in a sense (see below)
> 
> Once the dust from 4.18 has settled (final is expected in a couple of 
> weeks) we can start digging into this, although nothing prevents 
> starting with other "paperwork" etc.
> 
> > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
> > work to port it to Sequoia to OpenSSL:
> > 
> >
> > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000
> 
> This may well be a blocker on Fedora level, in part to keep container 
> etc images small but also for distro crypto policies and FIPS (neither 
> of which nettle supports AIUI).

With my Crypto Team hat on I do not see this as a blocker for Fedora in
the short term, we can start with nettle and then move to OpenSSL
later.

For RHEL we may prefer OpenSSL for various reasons above, but I would
note that although we do not certify nettle directly under FIPS we do
indirectly as part of GnuTLS, so it is certainly tested cryptography.

In fact nettle might be a slightly better choice in some cases for
container images because it is much smaller than OpenSSL.

Finally nettle could even be statically built into sequoia (together
with gmp) if we need even smaller footprint or we are concerned about
potential rpm breakage during upgrades.
I am not saying we want to do this, but it is an option that OpenSSL 3
won't provide as easily.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


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

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Tue, Sep 06, 2022 at 07:37:19PM +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 18:36, Kevin Fenzi wrote:
> > For an OTP generating app? I don't see why it would...
> 
> No, for FIDO2 authentication.

https://github.com/ellerh/softfido

But not sure how usable it is. ;) 

Also:

https://blog.hansenpartnership.com/webauthn-in-linux-with-a-tpm-via-the-hid-gadget/

but I am not sure where the real code is...

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

F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Make DNF5 the new default packaging tool. The change will replace DNF,
LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.
It is a second step after
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.

== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
The new DNF5 will provide a significant improvement in user
experiences and performance. The replacement is the second step in
upgrade of Fedora Software Management stack. Without the change there
will be multiple software management tool (DNF5, old Microdnf,
PackageKit, and DNF) based on different libraries (libdnf, libdnf5),
providing a different behavior, and not sharing a history. We can also
expect that DNF will have only limited support from upstream. The DNF5
development was announced on
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/NWSURJRGZAIIMNZJT244DHDPOG2PBQXZ/
Fedora-Devel] list in 2020.

=== New DNF5 Features ===

* Fully featured package manager without requirement of Python
** Smaller system
** Faster
** Replace DNF and Microdnf

* Unified behavior of in the software management stack
** New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon
*** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g.
versionlock, subscription-manager), therefore PackageKit behaves
differently in comparison to DNF
** Shared configurations
*** In DNF4 not all configuration is honored by PackageKit and Microdnf
** DNF/YUM was developed for decades with impact of multiple styles
and naming conventions (options, configuration, options, commands)

* New Daemon
** The new daemon can provide an alternative to PackageKit for RPMs
(only one backend of PackageKit) if it will be integrated into Desktop
** Support of Modularity and Comps group
* Performance improvement
** Loading of repositories
** Advisory operations
** RPM queries
*** Name filters with a case-insensitive search (the `repoquery` command)
** Smart sharing of metadata between dnf5 and daemon
*** Reduce disk and downloads requirements
*** Currently, DNF, Microdnf, and PackageKit use their own cache
*** Optional, may be not available for Fedora 39

* Decrease of a maintenance cost in the long term
** Shared plugins
** Removal of functional duplicates

* Fully integrated Modularity in LIBDNF5 workflows
** The Modularity is supported in DNF and LIBDNF but it is not fully
integrated. Integration was not possible due to limitation of
compatibility with other tools (PackageKit)
** Fully integrated Modularity required changes in the library workflow

=== Major codebase improvements ===

*Reports in structure
** DNF reports a lot of important information only in logs

* Removal of duplicated implementation
** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF
library). The integration was never finished, therefore LIBDNF still
contains duplicated functionality.
** decrease of the code maintenance cost in future

* Unify Python bindings
** Formal Libdnf provides two types of Python bindings
*** CPython (hawkey)
*** SWIG (libdnf)
** Maintaining and communication between both bindings requires a lot
of resources
** Binding unification was not possible without breaking API compatibility

* SWIG bindings
** With SWIG we can generate additional bindings without spending huge resources
** Code in particular languages will be very similar to each other

* Separation of system state from history DB and `/etc/dnf/module.d`
** In dnf-4 the list of userinstalled packages and list of installed
groups along with the lists of packages installed from them is
computed as an aggregation of transaction history. In dnf5 it will be
stored separately, having multiple benefits, among them that the
history database will serve for informational purposes only and will
not define the state of the system (it gets corrupted occasionally
etc.).
** Data stored in `/etc/dnf/module.d` were not supposed to be user
modifiable and their format is not sufficient (missing information
about installed packages with installed profiles)
*** Content of `/etc/dnf/module.d` will be moved into the System State

== Feedback ==


== Benefit to Fedora ==


== Scope ==
* Proposal owners:

DNF5 is still in the development and some of the features or options
are not yet available. We still have to finish the implementation of
Modularity, storing internal data related to History and System State,
and also documentation and man pages. DNF5 can be tested from
repository with upstream nightly builds -
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/.
The project's 

F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We are reworking the Node.js packaging to make Node.js versions
available as parallel-installable packages.

== Owner ==
* Name: [[User:SGallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com


== Detailed Description ==
We will be creating the packages nodejs-16, nodejs-18 and (in April)
nodejs-20. These packages will be parallel-installable (with the
exception of the -devel subpackages) and provide
`/usr/bin/node-$MAJOR`. We will also take advantage of the
`alternatives` subsystem to populate `/usr/bin/node` from the default
Node.js version for that release, or if the default is not installed,
the highest currently-installed version.

Notes:

* The default in Fedora 38 will be Node.js 18. If a user was to
install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20
would provide `/usr/bin/node`
* The policy going forward will be to have the most recently-released
version of Node.js at the time of Fedora's expected Beta release date
be the default for that release throughout its lifetime.

== Feedback ==
[https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/
Mailing list thread]

Neal Gompa raised the question of using a subpackage to own
`/usr/bin/node` instead of using the `alternatives` subsystem, citing
python as an example. My response was that the problem with this is
that I want `/usr/bin/node` to always be available so long as any
`nodejs-$MAJOR` version is installed. It also ensures that the
`node(1)` manpage always matches the `/usr/bin/node` executable.

== Benefit to Fedora ==

=== User Benefits ===
* Provides a simple way to have a different (or multiple) Node.js
interpreters on their system. No dealing with Modularity.
* Enables multiple versions of Node.js on the system (can test code
against different versions without using containers)

=== Packager Benefits ===
* No more modules to maintain.
* Availability of multiple Node.js versions in the buildroot means
that other `nodejs-*` packages can test against multiple supported
options.

== Scope ==
* Proposal owners:
The packaging work is done and can be played with at
https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/
today.

* Other developers:
There should be no need to change any dependent packages, though
packagers of Node.js software may wish to take advantage of the
testing opportunities afforded.

* Release engineering:
* Policies and guidelines: We will be updating the Node.js Packaging
Guidelines with the new best practices.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
Systems using the existing nodejs RPM package will be upgraded to the
matching `nodejs-$MAJOR` version. Work is pending on how to migrate
users of Modular Node.js to the new packages.


== How To Test ==


== User Experience ==
Done correctly, this should be handled entirely without the user's
need to know about it.

== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==
https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/

== Release Notes ==
Multiple releases of Node.js may now be installed in parallel from the
Fedora repositories.


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

F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Make DNF5 the new default packaging tool. The change will replace DNF,
LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.
It is a second step after
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.

== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
The new DNF5 will provide a significant improvement in user
experiences and performance. The replacement is the second step in
upgrade of Fedora Software Management stack. Without the change there
will be multiple software management tool (DNF5, old Microdnf,
PackageKit, and DNF) based on different libraries (libdnf, libdnf5),
providing a different behavior, and not sharing a history. We can also
expect that DNF will have only limited support from upstream. The DNF5
development was announced on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NWSURJRGZAIIMNZJT244DHDPOG2PBQXZ/
Fedora-Devel] list in 2020.

=== New DNF5 Features ===

* Fully featured package manager without requirement of Python
** Smaller system
** Faster
** Replace DNF and Microdnf

* Unified behavior of in the software management stack
** New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon
*** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g.
versionlock, subscription-manager), therefore PackageKit behaves
differently in comparison to DNF
** Shared configurations
*** In DNF4 not all configuration is honored by PackageKit and Microdnf
** DNF/YUM was developed for decades with impact of multiple styles
and naming conventions (options, configuration, options, commands)

* New Daemon
** The new daemon can provide an alternative to PackageKit for RPMs
(only one backend of PackageKit) if it will be integrated into Desktop
** Support of Modularity and Comps group
* Performance improvement
** Loading of repositories
** Advisory operations
** RPM queries
*** Name filters with a case-insensitive search (the `repoquery` command)
** Smart sharing of metadata between dnf5 and daemon
*** Reduce disk and downloads requirements
*** Currently, DNF, Microdnf, and PackageKit use their own cache
*** Optional, may be not available for Fedora 39

* Decrease of a maintenance cost in the long term
** Shared plugins
** Removal of functional duplicates

* Fully integrated Modularity in LIBDNF5 workflows
** The Modularity is supported in DNF and LIBDNF but it is not fully
integrated. Integration was not possible due to limitation of
compatibility with other tools (PackageKit)
** Fully integrated Modularity required changes in the library workflow

=== Major codebase improvements ===

*Reports in structure
** DNF reports a lot of important information only in logs

* Removal of duplicated implementation
** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF
library). The integration was never finished, therefore LIBDNF still
contains duplicated functionality.
** decrease of the code maintenance cost in future

* Unify Python bindings
** Formal Libdnf provides two types of Python bindings
*** CPython (hawkey)
*** SWIG (libdnf)
** Maintaining and communication between both bindings requires a lot
of resources
** Binding unification was not possible without breaking API compatibility

* SWIG bindings
** With SWIG we can generate additional bindings without spending huge resources
** Code in particular languages will be very similar to each other

* Separation of system state from history DB and `/etc/dnf/module.d`
** In dnf-4 the list of userinstalled packages and list of installed
groups along with the lists of packages installed from them is
computed as an aggregation of transaction history. In dnf5 it will be
stored separately, having multiple benefits, among them that the
history database will serve for informational purposes only and will
not define the state of the system (it gets corrupted occasionally
etc.).
** Data stored in `/etc/dnf/module.d` were not supposed to be user
modifiable and their format is not sufficient (missing information
about installed packages with installed profiles)
*** Content of `/etc/dnf/module.d` will be moved into the System State

== Feedback ==


== Benefit to Fedora ==


== Scope ==
* Proposal owners:

DNF5 is still in the development and some of the features or options
are not yet available. We still have to finish the implementation of
Modularity, storing internal data related to History and System State,
and also documentation and man pages. DNF5 can be tested from
repository with upstream nightly builds -
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/.
The project's 

F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We are reworking the Node.js packaging to make Node.js versions
available as parallel-installable packages.

== Owner ==
* Name: [[User:SGallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com


== Detailed Description ==
We will be creating the packages nodejs-16, nodejs-18 and (in April)
nodejs-20. These packages will be parallel-installable (with the
exception of the -devel subpackages) and provide
`/usr/bin/node-$MAJOR`. We will also take advantage of the
`alternatives` subsystem to populate `/usr/bin/node` from the default
Node.js version for that release, or if the default is not installed,
the highest currently-installed version.

Notes:

* The default in Fedora 38 will be Node.js 18. If a user was to
install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20
would provide `/usr/bin/node`
* The policy going forward will be to have the most recently-released
version of Node.js at the time of Fedora's expected Beta release date
be the default for that release throughout its lifetime.

== Feedback ==
[https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/
Mailing list thread]

Neal Gompa raised the question of using a subpackage to own
`/usr/bin/node` instead of using the `alternatives` subsystem, citing
python as an example. My response was that the problem with this is
that I want `/usr/bin/node` to always be available so long as any
`nodejs-$MAJOR` version is installed. It also ensures that the
`node(1)` manpage always matches the `/usr/bin/node` executable.

== Benefit to Fedora ==

=== User Benefits ===
* Provides a simple way to have a different (or multiple) Node.js
interpreters on their system. No dealing with Modularity.
* Enables multiple versions of Node.js on the system (can test code
against different versions without using containers)

=== Packager Benefits ===
* No more modules to maintain.
* Availability of multiple Node.js versions in the buildroot means
that other `nodejs-*` packages can test against multiple supported
options.

== Scope ==
* Proposal owners:
The packaging work is done and can be played with at
https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/
today.

* Other developers:
There should be no need to change any dependent packages, though
packagers of Node.js software may wish to take advantage of the
testing opportunities afforded.

* Release engineering:
* Policies and guidelines: We will be updating the Node.js Packaging
Guidelines with the new best practices.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
Systems using the existing nodejs RPM package will be upgraded to the
matching `nodejs-$MAJOR` version. Work is pending on how to migrate
users of Modular Node.js to the new packages.


== How To Test ==


== User Experience ==
Done correctly, this should be handled entirely without the user's
need to know about it.

== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==
https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/

== Release Notes ==
Multiple releases of Node.js may now be installed in parallel from the
Fedora repositories.


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

Re: Inactive packagers to be removed after the F37 release

[Alexander Bokovoy]

On ti, 06 syys 2022, Adam Williamson wrote:

On Tue, 2022-09-06 at 16:47 +, Tommy Nguyen wrote:

On Tue, 2022-09-06 at 18:18 +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 17:00, Gary Buhrmaster wrote:
> > mobile device
>
> Requires proprietary Google services.
>
> > computer
>
> Requires proprietary TPM 2.0 chip.

Hi,

Neither of this is true. For example, I use Raivo on my iOS device
which isn't proprietary.

It seems that your concerns regarding 2FA are based on a number of
misconceptions.

1. That it will cost money

You can generate TOTP codes using password generators, desktop apps, or
even by hand in the command line. It's a simple algorithm that doesn't
even require an Internet connection. However, in order for it to truly
be 2FA, it should be on a separate device (i.e, your phone) though
generating it on the desktop is what people do if they have no external
device.

2. That the algorithm will pose problems in other countries

I'm aware of ITAR and munitions exports, but I'm not convinced SHA1 and
HMAC poses as much of a problem as you say it does, even in
Russia/China.

3. That it requires specialized hardware

Again, not true. See part 1. TOTP should work on any device regardless
of the underlying hardware so long as it supports basic cryptographic
primitives.


This section of the thread seems to be moving rather at cross-purposes.
This was mcatanzaro's original proposal:

"In the long run, we should be moving to require WebAuthn for all
Fedora authentication-related purposes, since it's unphishable. Last
year I entered my GitHub password into a phishing page that was
proxying the real GitHub... if the evil page had gone to just slightly
more effort, it could have easily intercepted a simple TOTP/HOTP
challenge. This is not possible with WebAuthn, which I would say
actually is pretty much equivalent to a security magic bullet."

i.e. it was specifically about moving away from allowing "simple
TOTP/HOTP" 2FA, as it is phishable, and requiring webauthn, of which
Vitaly's points are I believe accurate.


Yep. We are not there yet with regards to this use case being
implemented in Fedora AAA but our goal is to provide an infrastructure
in Fedora 38 for Kerberos and local system integration, hopefully.

Looking at hardware products, a cheapest FIDO2 authenticator I know
about is a Token2 T2F2 FIDO2 and U2F Security Key (10.00 EUR per key
plus shipping costs)[1]. I am in contact with Token2 to see if we can
test this hardware in our SSSD/FreeIPA development.

Google's OpenSK platform is something people already tried to turn into
a FIDO2 virtual authenticator -- see [2] for example of integrating with
QEMU. This is far from being complete and user-friendly.


[1] https://www.token2.eu/shop/product/token2-t2f2-fido2-and-u2f-security-key
[2] https://github.com/google/OpenSK/issues/485

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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: Inactive packagers to be removed after the F37 release

[Michael Catanzaro]

On Tue, Sep 6 2022 at 10:11:54 AM -0700, Adam Williamson 
 wrote:

i.e. it was specifically about moving away from allowing "simple
TOTP/HOTP" 2FA, as it is phishable, and requiring webauthn, of which
Vitaly's points are I believe accurate.


Yes indeed.

That said, I *think* it could be done entirely in software, as the 
browser doesn't actually know whether it's talking to real hardware or 
to software pretending to be real hardware, right? I don't know enough 
about FIDO2 to be sure, but I assume that it should be possible to do 
it. Using a hardware token is not actually the primary goal. The goal 
is to programatically enforce that the authentication token is keyed to 
the domain that is *actually* requesting authentication, as reported by 
the web browser, so the 2FA token that gets generated for the fake 
fedoraproject.org.evil would not be a valid 2FA token for the real 
fedoraproject.org.


Of course, hardware authenticators would be even more secure, and it 
sure seems pretty reasonable to expect that people with commit access 
to Fedora packages are able to purchase a $25 or 30€ security key 
[1][2]. You don't need to spend $50 for a simple security key. But this 
really only makes a difference if the packager's computer is 
compromised, and at that point we've probably already lost.


Any 2FA is better than no 2FA. Currently I do not have any 2FA enabled 
on my Fedora account because there's no way to disable it once enabled, 
and I'm afraid something will break, so I'm not brave enough to opt in. 
I highly doubt I'm alone here.


Michael

[1] https://www.yubico.com/product/security-key-nfc-by-yubico/
[2] https://shop.nitrokey.com/shop/product/nkfi2-nitrokey-fido2-55

___
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: Thunderbird 102 pushed to F36 stable

[Mattia Verga via devel]

Il 03/09/22 02:56, l...@fedoraproject.org ha scritto:
>
> On 2022-09-02 10:49 a.m., Mattia Verga via devel 
>  wrote:
>> Here we go again: thunderbird 102 update was submitted to F36.
>>
>> This new version was known to bring incompatible changes to several
>> addons, yet it has been submitted to a stable Fedora release with
>> autopush enable and just a karma threshold of 2. It took less than 5
>> hours from the time the update was submitted to the time the update was
>> pushed to stable.
>>
> Which addons are incompatible?

The only one I care of is TbSync, which I need to connect an Exchange
calendar from my company.

AFAIK, TbSync developer was hired by Mozilla, but I was surprised they
didn't gave them a task to try integrate Exchange/O365 into TB core...
and now the developer has no free time to maintain their plugin keep up
with TB.

Mattia

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

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 06/09/2022 18:36, Kevin Fenzi wrote:

For an OTP generating app? I don't see why it would...


No, for FIDO2 authentication.

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

Re: Help needed with Python fc36 build failing

[Miro Hrončok]

On 06. 09. 22 16:52, Michael J Gruber wrote:

On Mon, Sep 5, 2022 at 2:01 PM Sandro 

The current py packaging guidelines recommend the opt-in dependency generator 
(which uses pyproject.toml) unless EPEL 8 or non-current Fedoras are used. 
Should this caveat be extended to F36 and EPEL 9, or am I mis-understanding the 
role of pyproject.toml for the packaging macros?


This is explicitly about project metadata (name, version, etc.) in 
pyproject.toml a new feature of setuptools.


The macros use pyproject.toml for different purpose and don't need this feature 
unless upstream uses it.


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

Re: Conditional Patch line

[Miro Hrončok]

On 06. 09. 22 19:06, Adam Williamson wrote:

On Tue, 2022-09-06 at 09:04 +0100, Daniel P. Berrangé wrote:


Unrelated to your question, but FWIW PatchNNN is not required, all
patches can be merely  "Patch: filename" and they'll get applied
in the order they are listed in the spec.


勞勞勞



See 
https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/BG5SVFAKGNVDJFHGZARABWGW2RRHN22G/ 
and https://youtu.be/0bfA0441dxc?t=666

and https://pagure.io/packaging-committee/pull-request/1157


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

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Tue, 2022-09-06 at 16:47 +, Tommy Nguyen wrote:
> On Tue, 2022-09-06 at 18:18 +0200, Vitaly Zaitsev via devel wrote:
> > On 06/09/2022 17:00, Gary Buhrmaster wrote:
> > > mobile device
> > 
> > Requires proprietary Google services.
> > 
> > > computer
> > 
> > Requires proprietary TPM 2.0 chip.
> 
> Hi,
> 
> Neither of this is true. For example, I use Raivo on my iOS device
> which isn't proprietary.
> 
> It seems that your concerns regarding 2FA are based on a number of
> misconceptions.
> 
> 1. That it will cost money
> 
> You can generate TOTP codes using password generators, desktop apps, or
> even by hand in the command line. It's a simple algorithm that doesn't
> even require an Internet connection. However, in order for it to truly
> be 2FA, it should be on a separate device (i.e, your phone) though
> generating it on the desktop is what people do if they have no external
> device.
> 
> 2. That the algorithm will pose problems in other countries
> 
> I'm aware of ITAR and munitions exports, but I'm not convinced SHA1 and
> HMAC poses as much of a problem as you say it does, even in
> Russia/China.
> 
> 3. That it requires specialized hardware
> 
> Again, not true. See part 1. TOTP should work on any device regardless
> of the underlying hardware so long as it supports basic cryptographic
> primitives.

This section of the thread seems to be moving rather at cross-purposes.
This was mcatanzaro's original proposal:

"In the long run, we should be moving to require WebAuthn for all
Fedora authentication-related purposes, since it's unphishable. Last
year I entered my GitHub password into a phishing page that was
proxying the real GitHub... if the evil page had gone to just slightly
more effort, it could have easily intercepted a simple TOTP/HOTP
challenge. This is not possible with WebAuthn, which I would say
actually is pretty much equivalent to a security magic bullet."

i.e. it was specifically about moving away from allowing "simple
TOTP/HOTP" 2FA, as it is phishable, and requiring webauthn, of which
Vitaly's points are I believe accurate.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Conditional Patch line

[Adam Williamson]

On Tue, 2022-09-06 at 09:04 +0100, Daniel P. Berrangé wrote:
> 
> Unrelated to your question, but FWIW PatchNNN is not required, all
> patches can be merely  "Patch: filename" and they'll get applied
> in the order they are listed in the spec.

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

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

Re: Orphaned packages looking for new maintainers

[Christian Glombek]

I can take package `colm`

FAS id: lorbus
___
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: Inactive packagers to be removed after the F37 release

[Tommy Nguyen]

On Tue, 2022-09-06 at 18:18 +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 17:00, Gary Buhrmaster wrote:
> > mobile device
> 
> Requires proprietary Google services.
> 
> > computer
> 
> Requires proprietary TPM 2.0 chip.

Hi,

Neither of this is true. For example, I use Raivo on my iOS device
which isn't proprietary.

It seems that your concerns regarding 2FA are based on a number of
misconceptions.

1. That it will cost money

You can generate TOTP codes using password generators, desktop apps, or
even by hand in the command line. It's a simple algorithm that doesn't
even require an Internet connection. However, in order for it to truly
be 2FA, it should be on a separate device (i.e, your phone) though
generating it on the desktop is what people do if they have no external
device.

2. That the algorithm will pose problems in other countries

I'm aware of ITAR and munitions exports, but I'm not convinced SHA1 and
HMAC poses as much of a problem as you say it does, even in
Russia/China.

3. That it requires specialized hardware

Again, not true. See part 1. TOTP should work on any device regardless
of the underlying hardware so long as it supports basic cryptographic
primitives.
___
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: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Tue, Sep 06, 2022 at 06:18:17PM +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 17:00, Gary Buhrmaster wrote:
> > mobile device
> 
> Requires proprietary Google services.

For an OTP generating app? I don't see why it would... 

https://search.f-droid.org/?q=otp=en

are all open source, freely available and don't need google for
anything. 

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

[Bug 2124631] New: perl-JSON-Path-1.0.2 is available

[bugzilla]

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

Bug ID: 2124631
   Summary: perl-JSON-Path-1.0.2 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-JSON-Path
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.0.2
Upstream release that is considered latest: 1.0.2
Current version/release in rawhide: 1.0.1-1.fc38
URL: https://metacpan.org/release/JSON-Path/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/15651/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124631
___
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: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 06/09/2022 17:00, Gary Buhrmaster wrote:

mobile device


Requires proprietary Google services.


computer


Requires proprietary TPM 2.0 chip.

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

Re: Orphaned packages looking for new maintainers

[Jonathan Wright via devel]

I'm happy to help maintain the python packages.

FAS: jonathanspw

On Mon, Sep 5, 2022 at 11:00 AM Ankur Sinha  wrote:

> I've taken a few more (a few for the neuro-sig):
>
> > Depending on: mcpanel (1), status change: 2022-08-30 (0 weeks ago)
> >   eegview (maintained by: aekoroglu, ankursinha, neuro-sig)
> >   eegview-0.0-15.fc37.src requires mcpanel-devel =
> 0.0-15.fc37
> >   eegview-0.0-15.fc37.x86_64 requires
> libmcpanel.so.0()(64bit)
>
> Taken for neuro-sig, co-maintainers welcome
>
> > Depending on: python-aiofiles (5), status change: 2022-08-30 (0 weeks
> ago)
> > 
> >
> >   python-matrix-nio (maintained by: ankursinha)
> >   python-matrix-nio-0.19.0-6.fc38.src requires
> python3dist(aiofiles) = 0.7
> >   python3-matrix-nio-0.19.0-6.fc38.noarch requires
> python3.11dist(aiofiles) = 0.7
>
> Taken for myself, co-maintainers welcome.
>
> > Depending on: python-piexif (3), status change: 2022-08-30 (0 weeks ago)
> >
> >   vimiv-qt (maintained by: ankursinha)
> >   vimiv-qt-0.8.0-7.fc37.x86_64 requires python3-piexif =
> 1.1.3-14.fc37
>
> Taken for myself, co-maintainers welcome.
>
> > Depending on: python-rply (4), status change: 2022-08-30 (0 weeks ago)
> >   python-rnc2rng (maintained by: iztokf)
> >   python-rnc2rng-2.6.6-3.fc37.src requires python3dist(rply)
> = 0.7.8
> >   python3-rnc2rng-2.6.6-3.fc37.noarch requires
> python3.11dist(rply) = 0.7.8
> >
> >   python-citeproc-py (maintained by: ankursinha, ignatenkobrain,
> neuro-sig)
> >   python-citeproc-py-0.6.0-5.fc37.src requires
> python3dist(rnc2rng) = 2.6.6
> >
> >   python-duecredit (maintained by: ankursinha, neuro-sig)
> >   python-duecredit-0.9.1-5.fc37.src requires
> python3dist(citeproc-py) = 0.6
> >   python3-duecredit-0.9.1-5.fc37.noarch requires
> python3.11dist(citeproc-py)
> > = 0.6, python3dist(citeproc-py) = 0.6
> >
> >   python-pybids (maintained by: ankursinha, neuro-sig)
> >   python-pybids-0.13.1-5.fc37.src requires
> python3dist(duecredit) = 0.9.1
>
> Taken for neuro-sig, co-maintainers welcome
>
> > Depending on: rtfilter (2), status change: 2022-08-30 (0 weeks ago)
> >   mcpanel (maintained by: orphan)
> >   mcpanel-0.0-15.fc37.i686 requires librtfilter.so.1
> >   mcpanel-0.0-15.fc37.src requires rtfilter-devel =
> 1.1-16.fc37
> >   mcpanel-0.0-15.fc37.x86_64 requires
> librtfilter.so.1()(64bit)
> >
> >   eegview (maintained by: aekoroglu, ankursinha, neuro-sig)
> >   eegview-0.0-15.fc37.src requires mcpanel-devel =
> 0.0-15.fc37
> >   eegview-0.0-15.fc37.x86_64 requires
> libmcpanel.so.0()(64bit)
>
> Taken for neuro-sig, co-maintainers welcome
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
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 2124508] Please branch and build perl-X11-Protocol-Other in epel9.

[bugzilla]

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

Jonathan Wright  changed:

   What|Removed |Added

 Blocks||2107786





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2107786
[Bug 2107786] Please branch and build clusterssh in epel9.
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124508
___
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 2124507] Please branch and build perl-X11-Protocol in epel9.

[bugzilla]

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

Jonathan Wright  changed:

   What|Removed |Added

 Blocks||2107786





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2107786
[Bug 2107786] Please branch and build clusterssh in epel9.
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124507
___
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: Inactive packagers to be removed after the F37 release

[Gary Buhrmaster]

On Tue, Sep 6, 2022 at 8:40 AM Vitaly Zaitsev via devel
 wrote:
>
> On 06/09/2022 10:26, Ondrej Mosnáček wrote:
> > This is just not true. Anyone with an Android or iOS device can set up
> > a software token via FreeOTP [1].
>
> I'm OK with software 2FA authenticators, but they want to force everyone
> to use Fido2 compatible hardware tokens. $50/each.

As previously discussed, those can be stored/instantiated
"in" your mobile device or computer.  For those who find
a need, or choose to have, a separable physical hardware
token, that is certainly another option.
___
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: Help needed with Python fc36 build failing

[Michael J Gruber]

> On Mon, Sep 5, 2022 at 2:01 PM Sandro  
> 
> pyproject does not work well, and is not backwards compatible. This is
> particularly a problem for EPEL ports from Fedora. Personally, I'd
> like to see it fixed for EPEL before relying on it for anything in
> Fedora.

The current py packaging guidelines recommend the opt-in dependency generator 
(which uses pyproject.toml) unless EPEL 8 or non-current Fedoras are used. 
Should this caveat be extended to F36 and EPEL 9, or am I mis-understanding the 
role of pyproject.toml for the packaging macros?
___
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 37 compose report: 20220906.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-37-20220905.n.0
NEW: Fedora-37-20220906.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:27
Upgraded packages:   0
Downgraded packages: 0

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: elementary-calculator-1.7.2-3.fc37
Summary: Calculator app designed for elementary
RPMs:elementary-calculator
Size:595.54 KiB

Package: elementary-camera-6.2.0-2.fc37
Summary: Camera app designed for elementary
RPMs:elementary-camera
Size:503.25 KiB

Package: elementary-capnet-assist-2.4.2-2.fc37
Summary: Captive Portal Assistant for elementary
RPMs:elementary-capnet-assist
Size:590.22 KiB

Package: elementary-code-6.2.0-2.fc37
Summary: Code editor from elementary
RPMs:elementary-code elementary-code-devel
Size:3.56 MiB

Package: elementary-files-6.1.4-2.fc37
Summary: File manager from elementary
RPMs:elementary-files elementary-files-devel elementary-files-portal
Size:5.10 MiB

Package: elementary-music-5.1.1-5.fc37
Summary: Music player and library from elementary
RPMs:elementary-music elementary-music-devel
Size:4.72 MiB

Package: elementary-notifications-6.0.2-2.fc37
Summary: GTK Notifications Server
RPMs:elementary-notifications elementary-notifications-demo
Size:297.72 KiB

Package: elementary-photos-2.7.5-2.fc37
Summary: Photo manager and viewer from elementary
RPMs:elementary-photos
Size:8.52 MiB

Package: elementary-print-0.1.3-9.fc37
Summary: Simple shim for printing support via Contractor
RPMs:elementary-print
Size:62.70 KiB

Package: elementary-screenshot-tool-6.0.2-4.fc37
Summary: Screenshot tool designed for elementary
RPMs:elementary-screenshot-tool
Size:702.50 KiB

Package: elementary-shortcut-overlay-1.2.1-4.fc37
Summary: Native, OS-wide shortcut overlay
RPMs:elementary-shortcut-overlay
Size:525.92 KiB

Package: elementary-sideload-6.0.2-3.fc37
Summary: Sideload flatpaks on Pantheon
RPMs:elementary-sideload
Size:716.79 KiB

Package: elementary-terminal-6.1.0-1.fc37
Summary: The terminal of the 21st century
RPMs:elementary-terminal elementary-terminal-fish
Size:827.75 KiB

Package: elementary-videos-2.8.4-2.fc37
Summary: Video player and library app from elementary
RPMs:elementary-videos
Size:1005.69 KiB

Package: elementary-wallpapers-5.4-7.fc37
Summary: Collection of wallpapers from the elementary project
RPMs:elementary-wallpapers elementary-wallpapers-gnome
Size:46.24 MiB

Package: pantheon-agent-geoclue2-1.0.5-4.fc37
Summary: Pantheon Geoclue2 Agent
RPMs:pantheon-agent-geoclue2
Size:525.71 KiB

Package: pantheon-agent-polkit-1.0.5-2.fc37
Summary: Pantheon Polkit Agent
RPMs:pantheon-agent-polkit
Size:502.13 KiB

Package: switchboard-6.0.2-2.fc37
Summary: Modular Desktop Settings Hub
RPMs:switchboard switchboard-devel switchboard-libs
Size:784.02 KiB

Package: switchboard-plug-about-6.1.0-2.fc37
Summary: Switchboard System Information plug
RPMs:switchboard-plug-about
Size:742.93 KiB

Package: switchboard-plug-applications-6.0.1-3.fc37
Summary: Switchboard Applications plug
RPMs:switchboard-plug-applications
Size:725.84 KiB

Package: switchboard-plug-bluetooth-2.3.6-4.fc37
Summary: Switchboard Bluetooth plug
RPMs:switchboard-plug-bluetooth
Size:675.25 KiB

Package: switchboard-plug-display-2.3.2-3.fc37
Summary: Switchboard Display plug
RPMs:switchboard-plug-display
Size:781.44 KiB

Package: switchboard-plug-mouse-touchpad-6.1.0-3.fc37
Summary: Switchboard Mouse and Touchpad plug
RPMs:switchboard-plug-mouse-touchpad
Size:749.98 KiB

Package: switchboard-plug-networking-2.4.3-2.fc37
Summary: Switchboard Networking plug
RPMs:switchboard-plug-networking
Size:976.99 KiB

Package: switchboard-plug-printers-2.2.0-2.fc37
Summary: Switchboard Printers Plug
RPMs:switchboard-plug-printers
Size:954.94 KiB

Package: switchboard-plug-sharing-2.1.5-4.fc37
Summary: Switchboard Sharing Plug
RPMs:switchboard-plug-sharing
Size:567.62 KiB

Package: switchboard-plug-sound-2.3.1-2.fc37
Summary: Switchboard Sound Plug
RPMs:switchboard-plug-sound
Size:973.25 KiB


= UPGRADED PACKAGES =

= 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

Re: hardened memory allocate port to linux-fedora system for secutiry

[Siddhesh Poyarekar]

On Sat, Aug 27, 2022 at 9:14 AM Carlos O'Donell  wrote:
> (2) Switching the default vs. improving the default.
>

A third option (or maybe it's an improvement to the default?), since
the choice of allocators seems to come up consistently, could be to
consider seriously (and is likely not a trivial project) the idea of
making it easier to switch allocators.

However to echo what Timothée said, there's value in packaging
hardened_malloc for Fedora to make it available to users.  It's much
too early to start talking about switching defaults IMO.

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-09-05.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

  Package   (co)maintainersStatus Change

abduco dfateyev, orphan0 weeks ago
bumpversionjdornak, orphan 0 weeks ago
clinfo orphan  0 weeks ago
colm   jtaylor, lorbus, orphan 0 weeks ago
ellorphan  0 weeks ago
espresso-abavigne, orphan  0 weeks ago
fortune-modepel-packagers-sig, orphan, 0 weeks ago
   sergiomb, shlomif
geteltoritoorphan  0 weeks ago
gimp-focusblur-plugin  orphan  0 weeks ago
git-archive-allorphan  0 weeks ago
git-fame   fale, ignatenkobrain, orphan0 weeks ago
git-lab-porcelain  orphan  3 weeks ago
gmqcc  orphan  0 weeks ago
hctavigne, orphan  0 weeks ago
httrackcicku, fale, orphan 0 weeks ago
ipsilonorphan, puiterwijk, simo2 weeks ago
kelbt  orphan  0 weeks ago
libmaxminddb   jtaylor, mruprich, orphan   0 weeks ago
libtomlorphan  0 weeks ago
libtvdborphan  1 weeks ago
mcpanelorphan  0 weeks ago
metapixel  orphan  1 weeks ago
mirrorlist-server  adrian, orphan, rust-sig0 weeks ago
monobristolorphan  0 weeks ago
mozilla-https-everywhere   orphan, rathann 1 weeks ago
novacom-client orphan  2 weeks ago
novacom-server orphan  2 weeks ago
nsca-ngorphan  0 weeks ago
origin go-sig, orphan, tdawson 0 weeks ago
parzip orphan  0 weeks ago
perl-BSSolvngompa, orphan  0 weeks ago
perl-Parse-Debian-Packages orphan  0 weeks ago
php-psr-http-clientorphan  0 weeks ago
pidgin-save-conv-order orphan  1 weeks ago
python-aiofilesorphan  0 weeks ago
python-aioodbc orphan  0 weeks ago
python-aiorpcx jonny, orphan   0 weeks ago
python-argopt  orphan  0 weeks ago
python-arpybochecha, orphan, python-sig0 weeks ago
python-august  orphan  2 weeks ago
python-bitstruct   orphan  2 weeks ago
python-calligrabot merlinm, orphan 2 weeks ago
python-colanderinfra-sig, lmacken, orphan, ralph   0 weeks ago
python-coreapi orphan  0 weeks ago
python-coreschema  orphan  0 weeks ago
python-cu2qu   orphan  2 weeks ago
python-daemonize   orphan  0 weeks ago
python-devtoolsorphan

[Bug 2124543] perl-SOAP-WSDL-3.004-11.fc38 FTBFS: Can't locate CGI.pm in @INC at t/SOAP/WSDL/Server/Simple.t line 6

[bugzilla]

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



--- Comment #2 from Andrew Bauer  ---
Thanks for the heads up. I am travelling for work this week and will look into
this later, as time allows. Thank you.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124543
___
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 2124543] perl-SOAP-WSDL-3.004-11.fc38 FTBFS: Can't locate CGI.pm in @INC at t/SOAP/WSDL/Server/Simple.t line 6

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
> It looks that some dependency stopped pulling perl-CGI

It was an upstream change in perl-Template-Toolkit-3.101-1.fc38
:

#---
# Version 3.100
#

Improvements:
* Template::Plugin::CGI removed to be used as a separate distro. (Sawyer X)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124543
___
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 2124543] New: perl-SOAP-WSDL-3.004-11.fc38 FTBFS: Can't locate CGI.pm in @INC at t/SOAP/WSDL/Server/Simple.t line 6

[bugzilla]

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

Bug ID: 2124543
   Summary: perl-SOAP-WSDL-3.004-11.fc38 FTBFS: Can't locate
CGI.pm in @INC at t/SOAP/WSDL/Server/Simple.t line 6
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-SOAP-WS
DL?collection=f38
Status: NEW
 Component: perl-SOAP-WSDL
  Assignee: dwro...@ertelnet.rybnik.pl
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dwro...@ertelnet.rybnik.pl,
perl-devel@lists.fedoraproject.org,
zonexpertconsult...@outlook.com
Blocks: 2117176 (F38FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-SOAP-WSDL-3.004-11.fc38 fails to build in Fedora 38 because a test fails:

t/SOAP/WSDL/Server/Simple.t ... 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
[...]
t/SOAP/WSDL/Server/Simple.t (Wstat: 512 (exited 2)
Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Result: FAIL
file:///builddir/build/BUILD/SOAP-WSDL-3.004/t/acceptance/wsdl/WSDLParser-imported.wsdl
already imported; ignoring it.
found unrecognised attribute {http://foo.bar}Action (ignored) at
/builddir/build/BUILD/SOAP-WSDL-3.004/blib/lib/SOAP/WSDL/Base.pm line 130.
Multiple parts detected in message testMultiPartWarning.
WS-I BP demands 0 to 1 parts in message body
Multiple parts detected in message testMultiPartWarning.
WS-I BP demands 0 to 1 parts in message body
Multiple parts detected in message testMultiPartWarning.
WS-I BP demands 0 to 1 parts in message body
Use of uninitialized value in hash element at
/usr/share/perl5/vendor_perl/Class/Std/Fast.pm line 159.
Use of uninitialized value in hash element at
/usr/share/perl5/vendor_perl/Class/Std/Fast.pm line 159.
Use of uninitialized value in hash element at
/usr/share/perl5/vendor_perl/Class/Std/Fast.pm line 159.
Use of uninitialized value in hash element at
/usr/share/perl5/vendor_perl/Class/Std/Fast.pm line 159.
Use of uninitialized value in hash element at
/usr/share/perl5/vendor_perl/Class/Std/Fast.pm line 159.
Can't locate CGI.pm in @INC (you may need to install the CGI module) (@INC
contains: /builddir/build/BUILD/SOAP-WSDL-3.004/blib/lib
/builddir/build/BUILD/SOAP-WSDL-3.004/blib/arch /usr/local/lib64/perl5/5.36
/usr/local/share/perl5/5.36 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
t/SOAP/WSDL/Server/Simple.t line 6.
BEGIN failed--compilation aborted at t/SOAP/WSDL/Server/Simple.t line 6.
Failed 1/124 test programs. 0/1233 subtests failed.

A difference in passing and failing build roots is at
. It looks that some
dependency stopped pulling perl-CGI package while your test requires it.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2117176
[Bug 2117176] Fedora 38 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124543
___
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 2124508] Please branch and build perl-X11-Protocol-Other in epel9.

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|jples...@redhat.com,|
   |robinlee.s...@gmail.com |
 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value
 Depends On||2124507



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/47412



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2124507
[Bug 2124507] Please branch and build perl-X11-Protocol in epel9.
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124508
___
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 2124507] Please branch and build perl-X11-Protocol in epel9.

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Blocks||2124508





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2124508
[Bug 2124508] Please branch and build perl-X11-Protocol-Other in epel9.
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124507
___
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 2124537] perl-HTML-FormFu-Element-reCAPTCHA-1.00-25.fc38 FTBFS: t/recaptcha.t fails with perl-HTML-Tiny-1.07-1.fc38

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||Red Hat Bugzilla 2124499



--- Comment #1 from Petr Pisar  ---
For your reference, I fixed a similar issue in perl-Captcha-reCAPTCHA (bug
#2124499).


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124537
___
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 2124537] New: perl-HTML-FormFu-Element-reCAPTCHA-1.00-25.fc38 FTBFS: t/recaptcha.t fails with perl-HTML-Tiny-1.07-1.fc38

[bugzilla]

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

Bug ID: 2124537
   Summary: perl-HTML-FormFu-Element-reCAPTCHA-1.00-25.fc38 FTBFS:
t/recaptcha.t fails with perl-HTML-Tiny-1.07-1.fc38
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-HTML-Fo
rmFu-Element-reCAPTCHA?collection=f38
Status: NEW
 Component: perl-HTML-FormFu-Element-reCAPTCHA
  Assignee: emman...@seyman.fr
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2117176 (F38FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-HTML-FormFu-Element-reCAPTCHA-1.00-25.fc38 fails to build in Fedora 38
because a test fails:

#   Failed test 'stringified form'
#   at t/recaptcha.t line 29.
#  got: '
# 
# 
# 
# //
# 
# http://www.google.com/recaptcha/api/challenge?k=xxx";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?k=xxx; width="500"
/>
# 
# 
# 
# '
# expected: '
# 
# 
# 
# //
# 
# http://www.google.com/recaptcha/api/challenge?k=xxx";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?k=xxx;
width="500">
# 
# 
# 
# '
# Looks like you failed 1 test of 1.
t/recaptcha.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 

This is triggered by upgrading perl-HTML-Tiny from 1.05-40.fc37 to 1.07-1.fc38.
The reason is that HTML-Tiny-1.07 changed a serialization of empty iframe
elements to a single tag.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2117176
[Bug 2117176] Fedora 38 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124537
___
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 2124507] Please branch and build perl-X11-Protocol in epel9.

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/47411


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124507
___
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 2124499] perl-Captcha-reCAPTCHA-0.99-6.fc38 FTBFS: t/10.get_html.t fails with perl-HTML-Tiny-1.07-1.fc38

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2022-09-06 12:23:36




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

[Marcin Juszkiewicz]

W dniu 3.09.2022 o 10:47, Demi Marie Obenour pisze:

On 9/3/22 04:42, Marcin Juszkiewicz wrote:

W dniu 3.09.2022 o 02:56, l...@fedoraproject.org pisze:



Which addons are incompatible? Additionally, use "Addon Compatibility
Check" for the purpose. The best practice is to contact these addons
developers fixing their issues.



After using Thunderbird for over 10 years I have a feeling that addons
developers more often abandon their addons when Thunderbird breaks
compatibility rather than continue working on them.



Can you name specific addons?


External Editor for example - worked up to v90 (or whichever was the 
previous "we break extensions" point). Current solution to get it 
working is so bizarre that I prefer to forget about it.


I stopped adding new extensions some time ago to not get used to extra 
functionality which may/will vanish with version update.


Now I have 11 extensions working and removed all which stopped being 
compatible.

___
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 2124499] perl-Captcha-reCAPTCHA-0.99-6.fc38 FTBFS: t/10.get_html.t fails with perl-HTML-Tiny-1.07-1.fc38

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Captcha-reCAPTCHA-0.99
   ||-7.fc38
 Status|ASSIGNED|MODIFIED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124499
___
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 2115214] perl-Database-DumpTruck-1.2-24.fc37 FTBFS: Failed test 'Proper data was retrieved from the database' with JSON::PP 4.11

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2115214
___
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 2124499] perl-Captcha-reCAPTCHA-0.99-6.fc38 FTBFS: t/10.get_html.t fails with perl-HTML-Tiny-1.07-1.fc38

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||CPAN 144224
 Status|NEW |ASSIGNED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124499
___
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 2124508] New: Please branch and build perl-X11-Protocol-Other in epel9.

[bugzilla]

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

Bug ID: 2124508
   Summary: Please branch and build perl-X11-Protocol-Other in
epel9.
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-X11-Protocol-Other
  Assignee: jples...@redhat.com
  Reporter: johan...@kreuzer-bb.de
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-X11-Protocol-Other in epel9.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124508
___
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 2124507] New: Please branch and build perl-X11-Protocol in epel9.

[bugzilla]

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

Bug ID: 2124507
   Summary: Please branch and build perl-X11-Protocol in epel9.
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-X11-Protocol
  Assignee: jples...@redhat.com
  Reporter: johan...@kreuzer-bb.de
QA Contact: extras...@fedoraproject.org
CC: cicku...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-X11-Protocol in epel9.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124507
___
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: Orphaned various packages (GNOME / GObject libraries)

[Mamoru TASAKA]

Fabio Valentini wrote on 2022/09/06 18:45:

Hi all,

Since the Pantheon desktop will not be available on Fedora 37+ for the
foreseeable future (libsoup3pocalypse etc.), I am no longer interested
in maintaining some of its dependencies or "shared" components that
are still used by existing applications and some other GObject
libraries, and have hence orphaned them:

- zeitgeist (Required-By: cairo-dock, gnome-activity-journal, synapse)



Taken.

Regards,
Mamoru
___
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 2102597] Add perl-DBIx-Class to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-670c12c809 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-2022-670c12c809

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=2102597
___
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 2102581] Add perl-SQL-Abstract to EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
FEDORA-EPEL-2022-670c12c809 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-2022-670c12c809

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=2102581
___
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

[rpms/perl-Database-DumpTruck] PR #2: Fix JSON comparison in tests

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-Database-DumpTruck` 
that you are following.

Merged pull-request:

``
Fix JSON comparison in tests
``

https://src.fedoraproject.org/rpms/perl-Database-DumpTruck/pull-request/2
___
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 2124499] New: perl-Captcha-reCAPTCHA-0.99-6.fc38 FTBFS: t/10.get_html.t fails with perl-HTML-Tiny-1.07-1.fc38

[bugzilla]

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

Bug ID: 2124499
   Summary: perl-Captcha-reCAPTCHA-0.99-6.fc38 FTBFS:
t/10.get_html.t fails with perl-HTML-Tiny-1.07-1.fc38
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Captcha
-reCAPTCHA?collection=f38
Status: NEW
 Component: perl-Captcha-reCAPTCHA
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
perl-ma...@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2117176 (F38FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Captcha-reCAPTCHA-0.99-6.fc38 fails to build in Fedora 38 because a test
fails:

t/pod.t . ok
#   Failed test 'Simple: Generate HTML OK 18'
#   at t/10.get_html.t line 111.
#  got: 'http://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500" />
# '
# expected: 'http://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500">
# '
#   Failed test 'Error: Generate HTML OK 31'
#   at t/10.get_html.t line 111.
#  got: 'http://www.google.com/recaptcha/api/challenge?error=%3c%3csome+random+error%3e%3e&k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?error=%3c%3csome+random+error%3e%3ek=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500" />
# '
# expected: 'http://www.google.com/recaptcha/api/challenge?error=%3c%3csome+random+error%3e%3e&k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?error=%3c%3csome+random+error%3e%3ek=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500">
# '
#   Failed test 'Error in hash: Generate HTML OK 44'
#   at t/10.get_html.t line 111.
#  got: 'http://www.google.com/recaptcha/api/challenge?error=%3c%3csome+random+error%3e%3e&k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?error=%3c%3csome+random+error%3e%3ek=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500" />
# '
# expected: 'http://www.google.com/recaptcha/api/challenge?error=%3c%3csome+random+error%3e%3e&k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?error=%3c%3csome+random+error%3e%3ek=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500">
# '
#   Failed test 'Secure: Generate HTML OK 58'
#   at t/10.get_html.t line 111.
#  got: 'https://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# https://www.google.com/recaptcha/api/noscript?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500" />
# '
# expected: 'https://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# https://www.google.com/recaptcha/api/noscript?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500">
# '
#   Failed test 'Options: Generate HTML OK 71'
#   at t/10.get_html.t line 111.
#  got: '
# //
# 
# http://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500" />
# '
# expected: '
# //
# 
# http://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500">
# '
#   Failed test 'Use old verion: Generate HTML OK 87'
#   at t/10.get_html.t line 111.
#  got: '
# //
# 
# http://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# http://www.google.com/recaptcha/api/noscript?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY;
width="500" />
# '
# expected: '
# //
# 
# http://www.google.com/recaptcha/api/challenge?k=6LdAAAkAwAAAFJj6ACG3Wlix_GuQJMNGjMQnw5UY";
type="text/javascript">
# 

Re: Orphaned various packages (GNOME / GObject libraries)

[Kalev Lember]

On Tue, Sep 6, 2022 at 11:47 AM Fabio Valentini 
wrote:

> I expect that editorconfig, graphite2, libcloudproviders to be picked
> up by GNOME package maintainers, since they're dependencies of core
> GNOME or Fedora Workstation components (CC @kalev).
>

Thanks! I picked up those 3.

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

Orphaned various packages (GNOME / GObject libraries)

[Fabio Valentini]

Hi all,

Since the Pantheon desktop will not be available on Fedora 37+ for the
foreseeable future (libsoup3pocalypse etc.), I am no longer interested
in maintaining some of its dependencies or "shared" components that
are still used by existing applications and some other GObject
libraries, and have hence orphaned them:

- contractor (Required-By: appeditor)
- editorconfig (Required-By: gnome-builder, gnome-text-editor,
kf5-texteditor, vim-editorconfig)
- elementary-sound-theme (unused freedesktop.org sound theme)
- elementary-theme (GTK 2/3/4 stylesheet which breaks all DEs except Pantheon)
- granite (Required-By: various GTK applications)
- graphite2 (Required-By: harfbuzz, libreoffice, texlive)
- libcloudproviders (Required-By: gtk3, nautilus, nextcloud-client)
- zeitgeist (Required-By: cairo-dock, gnome-activity-journal, synapse)

I expect that editorconfig, graphite2, libcloudproviders to be picked
up by GNOME package maintainers, since they're dependencies of core
GNOME or Fedora Workstation components (CC @kalev).

granite will maybe need to stay around, though its widgets are a bit
broken if you don't use the elementary GTK stylesheet. There's also
granite-7 now (granite is like the elementary version of libhandy for
GTK3, granite-7 is like the elementary version of libadwaita for
GTK4), and I expect that they will both need to be packaged at some
point.

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

Re: F38 proposal: Minizip renaming (Self-Contained Change proposal)

[Lukas Javorsky]

Hi guys,

Thank you so much for the feedback.

Let's wrap it up...

1) We will not rename the current "minizip-compat" to "minizip".

2) The Obsolete in the "minizip-ng" package will look like this:
"Obsoletes: minizip < 3.0.3"
It shouldn't affect the "minizip-compat" because we won't rename that (look
at step 1)

3) The removal of the "Provides" and "Obsolete" in the new "minizip-ng"
package will be removed in Fedora 42 (hopefully at that time all users are
upgraded)

Note: The rebuild (step 2 in the proposal change) will be done by the
maintainers of the dependent packages. I'll report a bug for each
component, where I will request it. If some of the maintainers will not be
responsive, I will create a PR and as provenpackagers to merge it.

Is this plan correction okay with you?
Or is there something else you would like to clear out?

On Tue, Aug 30, 2022 at 11:04 PM Maxwell G via devel <
devel@lists.fedoraproject.org> wrote:

> On 22/08/30 05:57PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Aug 15, 2022 at 05:04:27PM -0400, Ben Cotton wrote:
> > > == Detailed Description ==
> > > Upstream has changed the naming of the "minizip" package to
> > > "minizip-ng" and we should follow their naming so there is no
> > > confusion about which package is the right one. Upstream has also
> > > requested to rename the "minizip-compat" zlib subpackage to "minizip"
> > > which is the right naming for the package.
> > >
> > > The "minizip" and "minizip-compat" provides different shared libraries
> > > which prevent us from conflicting sonames.
> > >
> > > The plan behind this change can be put into x steps which will be
> > > completed separately and in the given order:
> > >
> > > ''NOTE: All of the Provides and Obsoletes will be added to the *-devel
> > > subpackages as well.''
> > >
> > > 1) Create a new package "minizip-ng" which will `Provides: minizip =
> > > %{sameevr}` and `Obsoletes: (minizip < 3.0.2-7 and minizip > 3.0.0-1)`
> >
> > Hi,
> >
> > it seems that Obsoletes does not work with boolean dependencies,
> > so the proposed for would not work.
>
> Correct. And even if it did work, you'd want to use the "with" operator
> not "and."
>
> > Instead, please use the standard form described by the Packaging
> > Guidelines:
> >   Obsoletes: minizip < 3.0.3
>
> That also won't work. If minizip-ng "Obsoletes: minizip < 3.0.3" and the
> new minizip package (the current minizip-compat) is 1.2.12-5, it will
> get Obsoleted by minizip-ng, which is unwanted. I would suggest adding
> "Epoch: 1" to the new minizip package (current minizip-compat) so it
> sorts above 3.0.3.
>
> You also shouldn't add "Provides: minizip = %{sameevr}`" to minizip-ng.
> It will break parallel installability with the new minizip package. Just
> wait to retire the current minizip (the one that's becoming minizip-ng)
> until step 2 has been completed.
>
> > > 2) Rebuild all of the packages that BuildRequire/Require "minizip"
> > > package to BuildRequire/Require new "minizip-ng" package
>
> Who will be doing this? How will it be done?
>
> > > 3) Retire the "minizip" package following the
> > > [
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/
> > > Package Retirement Process]
> > >
> > > 4) Wait for the Fedora 40 when it's ensured that every user has
> > > updated at least to the Fedora 38. Remove the `Provides` and
> > > `Obsoletes` from the "minizip-ng" package
> >
> > FWIW, I prefer to keep those for a while. We don't officially support
> > this, but people do upgrades over more than two versions quite often,
> > and it's nice not to break that.
>
> I agree. If you use the approach I outlined above, removing the
> the Obsoletes won't be necessary in order to rename minizip-compat to
> minizip.
>
> > > 5) Rename the "minizip-compat" to the "minizip" package and add
> > > `Provides: minizip-compat = %{sameevr}` and `Obsoletes: minizip-compat
> > > < 1.2.12`
> >
> > As already mentioned in the original discussion thread, this step is
> > risky. We generally try to follow upstream naming on packages, but
> > sometimes it's not possible for various technical reasons. This seems
> > to be one of those cases, because limitiations of Obsoletes mean that
> > we can't obsolete a subset of package versions.
>
> If you use the Epoch approach, this wouldn't be an
> issue. Also, what's the idea of waiting to do step 5 until Fedora 40?
>
> > Minizip-compat is not intended to be used by anything in the
> > distribution, so it's not a big deal if the package name is "wrong".
> > Thus, I think it's better to skip this last step and tell minizip
> > upstream that the we'll keep the "-compat" name for compatiblity
> > reasons. Maybe add a sentence of explanation to the package name.
>
> I agree. While it's possible to overcome the technical hurdles, this
> whole Change seems like more headache than its worth. Kevin and I had to
> deal with a similar situation of Obsoletes and Provides and boolean
> Requires with the 

Re: Conditional Patch line

[Miro Hrončok]

On 05. 09. 22 21:58, Richard W.M. Jones wrote:

On Mon, Sep 05, 2022 at 09:56:58PM +0200, Dominik 'Rathann' Mierzejewski wrote:

On Monday, 05 September 2022 at 21:42, Richard W.M. Jones wrote:

I have a downstream patch[0] which -- I don't really understand why --
breaks riscv64 builds but is necessary for primary Fedora arches.  Is
it correct to do:

   %ifnarch riscv64
   Patch123: downstream.patch
   %endif

given that the package uses %autosetup and therefore doesn't have
explicit %patch lines.

I think this means that if I build the SRPM on riscv64 then the
downstream patch wouldn't be included, meaning that SRPM would then
fail to build on other arches.


This is correct. And forbidden by the packaging guidelines as others pointed 
out.

As long as riscv64 lives in another Koji, this will not create real problems. 
However once (if) riscv64 is added to the proper Fedora Koji, when the SRPM 
would be built on riscv64, the build would fail on all other architectures due 
to the missing patch file.



In this particular case that doesn't

matter, but it feels wrong.  Is there a recommended way to do this
(apart from fixing the patch)?


Change %autosetup to plain %setup and apply the patch conditionally
instead of conditionally including it in the SRPM.


There are 26 patches so that's a bit of a PITA.  Is there not an
easier way?


You can do this:

=
Patch1:   ...
Patch2:   ...
...
PatchX:   ...
...

# Patches after 500 are applied conditionally

# Only applied on non-riscv64
Patch501: downstream.patch

...

%prep
%autosetup -N (-S git_am or whatever other options you like)
# apply all patches < 500
%autopatch -M 499

# apply conditional patches
%ifnarch riscv64
%autopatch 501
%endif
=

Alternatively, if you cannot (or don't want to) reorder the patches for some 
reason, you could do:


=
# apply all patches <= 122
%autopatch -M 122

%ifnarch riscv64
%autopatch 123
%endif

# apply all patches >= 124
%autopatch -m 124
=

Which is a tad uglier.

Note that %autopatch accepts positional arguments with patch numbers only since 
RPM 4.17. Before that you can either use %patch501 (which does not work with 
%autosetup -S) or %apply_patch -q %{PATCH501} (which RPM considered internal 
and removed from 4.17+).


For an uglier but portable solution that works on RPM <=4.16 and >=4.17, and 
also respects %autosetup -S option, see 
https://src.fedoraproject.org/rpms/python3.8/blob/f35/f/python3.8.spec#_736


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

Re: Conditional Patch line

[Leigh Scott]

> On Mon, Sep 05, 2022 at 09:56:58PM +0200, Dominik 'Rathann' Mierzejewski 
> wrote:
> 
> There are 26 patches so that's a bit of a PITA.  Is there not an
> easier way?
> 
> Rich.

Try using autopatch.

# Apply patches up to #1000 from this spec.
%autopatch -M1000 -p1

https://pkgs.rpmfusion.org/cgit/free/chromium-freeworld.git/tree/chromium-freeworld.spec#n222
___
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

[rpms/perl-Database-DumpTruck] PR #2: Fix JSON comparison in tests

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: 
`perl-Database-DumpTruck` that you are following:
``
Fix JSON comparison in tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Database-DumpTruck/pull-request/2
___
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 2124460] Pleadse branch and build perl-Crypt-SSLeay in epel9

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|caillon+fedoraproject@gmail |
   |.com, caol...@redhat.com,   |
   |jples...@redhat.com,|
   |ka...@ucw.cz,   |
   |mspa...@redhat.com, |
   |rhug...@redhat.com, |
   |rstr...@redhat.com, |
   |sandm...@redhat.com |
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/47408


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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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=2123834
___
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 2124241] perl-PAR-Packer-1.056 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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=2124241
___
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 2124002] perl-YAML-LibYAML-0.84 is available

[bugzilla]

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



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

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=2124002
___
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 2123496] perl-Verilog-Perl-3.480 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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=2123496
___
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

[rpms/perl-Database-DumpTruck] PR #1: Fix JSON comparison in tests

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-Database-DumpTruck` 
that you are following.

Merged pull-request:

``
Fix JSON comparison in tests
``

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

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 06/09/2022 10:26, Ondrej Mosnáček wrote:

This is just not true. Anyone with an Android or iOS device can set up
a software token via FreeOTP [1].


I'm OK with software 2FA authenticators, but they want to force everyone 
to use Fido2 compatible hardware tokens. $50/each.


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

[Bug 2115214] perl-Database-DumpTruck-1.2-24.fc37 FTBFS: Failed test 'Proper data was retrieved from the database' with JSON::PP 4.11

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #2 from Michal Josef Spacek  ---
One possible fix is `use Test::Deep::JSON`.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2115214
___
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: Inactive packagers to be removed after the F37 release

[Ondrej Mosnáček]

On Sun, Sep 4, 2022 at 7:30 PM Michael Catanzaro  wrote:
> And anybody who isn't
> willing to buy a security key wouldn't be able to contribute to Fedora
> at all.

This is just not true. Anyone with an Android or iOS device can set up
a software token via FreeOTP [1]. Sure, security-wise it's not as good
as a HW token, but it's already way better than nothing. I've been
using it for 2FA on Fedora for several months now without any problem.
I'm really surprised that this thread got so far without mentioning
FreeOTP...

[1] https://freeotp.github.io/
___
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

[rpms/perl-Database-DumpTruck] PR #1: Fix JSON comparison in tests

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: 
`perl-Database-DumpTruck` that you are following:
``
Fix JSON comparison in tests
``

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

[Bug 2124460] New: Pleadse branch and build perl-Crypt-SSLeay in epel9

[bugzilla]

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

Bug ID: 2124460
   Summary: Pleadse branch and build perl-Crypt-SSLeay in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Crypt-SSLeay
  Assignee: jples...@redhat.com
  Reporter: johan...@kreuzer-bb.de
CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com,
jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Pleadse branch and build perl-Crypt-SSLeay in epel9.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124460
___
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 2124459] New: Please branch and build perl-Net-OpenSSH in epel9

[bugzilla]

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

Bug ID: 2124459
   Summary: Please branch and build perl-Net-OpenSSH in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Net-OpenSSH
  Assignee: steve.tray...@cern.ch
  Reporter: johan...@kreuzer-bb.de
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
steve.tray...@cern.ch
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Net-OpenSSH in epel9.


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

[Panu Matilainen]

On 9/2/22 17:31, Neal H. Walfield wrote:

Hi all,

rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
Sequoia PGP.

   https://rpm.org/wiki/Releases/4.18.0
   https://sequoia-pgp.org/

Thanks to Fabio Valentini (decathorpe) for packaging not only
rpm-sequoia, but all of the Sequoia packages for Fedora.

   
https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/


With this note, I'd firstly like to make the Fedora community more
aware of this project.  (I don't think it has been mentioned here
yet.)

Second, although the internal OpenPGP backend is still the default
backend, it will be removed in rpm 4.19:

   https://github.com/rpm-software-management/rpm/issues/1935


While that was the initial goal, I suspect we may have to stretch this a 
bit. I think we'll first need a release where the upstream default is 
something else, and then in the next release we can actually look at 
axing it.




It is probably best to start the transition as soon as possible to
work out any kinks.

In that vein, I'd like to offer my help.  Making this type of change
needs to be done carefully.  Perhaps these are questions or concerns.
I'd like to hear them and respond to them.  There is also technical
work that needs to be done.  I'm more of a developer than a packager,
but if Fedora decides to use the Sequoia backend, I'd like to offer my
help in any way I can.


Since rpm 4.18 gained the Sequoia support afterall, we can and should 
look into swapping over in Fedora 38. That'll help sorting out any rough 
edges and make it easier to eventually swap the default in upstream as 
well. We probably need to do this with a change process as anything 
rpm-related tends to be system/distro wide in a sense (see below)


Once the dust from 4.18 has settled (final is expected in a couple of 
weeks) we can start digging into this, although nothing prevents 
starting with other "paperwork" etc.



Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
work to port it to Sequoia to OpenSSL:

   
https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000


This may well be a blocker on Fedora level, in part to keep container 
etc images small but also for distro crypto policies and FIPS (neither 
of which nettle supports AIUI).


- Panu -
___
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: Conditional Patch line

[Daniel P . Berrangé]

On Mon, Sep 05, 2022 at 08:42:34PM +0100, Richard W.M. Jones wrote:
> I have a downstream patch[0] which -- I don't really understand why --
> breaks riscv64 builds but is necessary for primary Fedora arches.  Is
> it correct to do:
> 
>   %ifnarch riscv64
>   Patch123: downstream.patch
>   %endif
> 
> given that the package uses %autosetup and therefore doesn't have
> explicit %patch lines.

Unrelated to your question, but FWIW PatchNNN is not required, all
patches can be merely  "Patch: filename" and they'll get applied
in the order they are listed in the spec.

> I think this means that if I build the SRPM on riscv64 then the
> downstream patch wouldn't be included, meaning that SRPM would then
> fail to build on other arches.  In this particular case that doesn't
> matter, but it feels wrong.  Is there a recommended way to do this
> (apart from fixing the patch)?

Rather than fixing the root cause, if you want a relatively simple
workaround still, you could merely move the conditional into the
patch hack:

  if test $(uname -m) == "riscv64"
  then
...autoconf patch stuff...
  fi

or something along those lines 

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Users with commit rights in src.fp.o but no more in packager group

[Vít Ondruch]

Dne 06. 09. 22 v 9:20 Vít Ondruch napsal(a):


Dne 06. 09. 22 v 0:25 Kevin Fenzi napsal(a):

On Mon, Sep 05, 2022 at 12:13:26PM +0200, Miro Hrončok wrote:

On 05. 09. 22 11:07, Vít Ondruch wrote:
Apart from that, I don't think that the pseudo-users or group 
ownership

would work. I saw a good amount of people giving the packages to some
groups or pseudo-users, but in turn, that meant there is nobody who
would care about such package.

+100

While that can surely happen, it can and does also happen when someone
is 'main admin' of a package. :) You can't make someone care.



Right, but we have a process to identify inactive maintainers. If 
there is no maintainer left, the package is orphaned. The ownership 
should never be moved to the group. It is much harder to identify 
identify packages which are assigned to certain group, because the 
groups often are active.


And as I said, being member of ruby-packagers-sig, it is not straight 
forward to remove group from packages. Even though it has admin 
privileges, it cannot be removed from the package by the group member. 
Maybe I should report this somewhere officially ...



Here we go:

https://pagure.io/fedora-infrastructure/issue/10882


Not sure if this is the right place, maybe it should have been reported 
against pagure-dist-git ...



Vít






I think the best thing we can do is match up the people who care with
the packages they care about. Using main admin as a indicator of who
cares for the package doesn't seem right to me. You can definitely have
cases of packages where multiple people work on it, or cases where just
one person does, but they aren't the main admin.



But this is typically problem of inactive maintainers. And I am 
looking forward to the current activity of identifying the inactive 
packagers. I truly believe this cleanup will help to deliver better 
content.





Anyhow, the only real reason we need main admin is that bugzilla needs 1
specific user to assign bugs to. Perhaps we could consider this when/if
we ever move off bugzilla.



+1


Vít




kevin

___
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


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

Re: Users with commit rights in src.fp.o but no more in packager group

[Vít Ondruch]

Dne 06. 09. 22 v 0:25 Kevin Fenzi napsal(a):

On Mon, Sep 05, 2022 at 12:13:26PM +0200, Miro Hrončok wrote:

On 05. 09. 22 11:07, Vít Ondruch wrote:

Apart from that, I don't think that the pseudo-users or group ownership
would work. I saw a good amount of people giving the packages to some
groups or pseudo-users, but in turn, that meant there is nobody who
would care about such package.

+100

While that can surely happen, it can and does also happen when someone
is 'main admin' of a package. :) You can't make someone care.



Right, but we have a process to identify inactive maintainers. If there 
is no maintainer left, the package is orphaned. The ownership should 
never be moved to the group. It is much harder to identify identify 
packages which are assigned to certain group, because the groups often 
are active.


And as I said, being member of ruby-packagers-sig, it is not straight 
forward to remove group from packages. Even though it has admin 
privileges, it cannot be removed from the package by the group member. 
Maybe I should report this somewhere officially ...




I think the best thing we can do is match up the people who care with
the packages they care about. Using main admin as a indicator of who
cares for the package doesn't seem right to me. You can definitely have
cases of packages where multiple people work on it, or cases where just
one person does, but they aren't the main admin.



But this is typically problem of inactive maintainers. And I am looking 
forward to the current activity of identifying the inactive packagers. I 
truly believe this cleanup will help to deliver better content.





Anyhow, the only real reason we need main admin is that bugzilla needs 1
specific user to assign bugs to. Perhaps we could consider this when/if
we ever move off bugzilla.



+1


Vít




kevin

___
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


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

[Bug 2124241] perl-PAR-Packer-1.056 is available

[bugzilla]

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



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


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

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-PAR-Packer-1.056-1.fc3
   ||8




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

[Tommy Nguyen]

On Mon, 2022-09-05 at 22:45 -0400, Daniel Micay via devel wrote:
> The comparison is being done incorrectly. Since hardened_malloc
> builds
> both a lightweight and heavyweight library by default, and since I
> already explained this and that the lightweight library still has
> optional security features enabled, it doesn't seem to have been done
> in
> good faith. My previous posts where I provided both concise and
> detailed
> information explaining differences and the approach were ignored. Why
> is
> that?

I agree. I decided to do a more fair test myself (I'm quite interested
in hardened_malloc). First, I downloaded the source RPM for my current
kernel:

dnf download --source kernel-5.19.6-200.fc36.x86_64

Then made both heavy and light variants:

sysctl -p /etc/sysctl.d/hardened_malloc.conf
make VARIANT=light

Setup the chroot:

mock -r fedora-36-x86_64 --init

Create our SRPM:

mock -r fedora-36-x86_64 --buildsrpm --spec kernel.spec --sources $PWD
--resultdir $PWD

Now do the compilations:

cp out-light/libhardened_malloc.so .
./preload.sh /usr/bin/time mock -r fedora-36-x86_64 --rebuild kernel-
5.19.6-200.fc36.src.rpm >light.out 2>&1

/usr/bin/time mock -r fedora-36-x86_64 --rebuild kernel-5.19.6-
200.fc36.src.rpm >no_preload.out 2>&1


___
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 2123834] perl-Log-Log4perl-1.56 is available

[bugzilla]

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



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


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