[Bug 1969474] perl-POE-Component-IRC-6.92 is available

[bugzilla]

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



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

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-15abda18e1   
singularity-3.7.4-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef   
openjpeg2-2.3.1-11.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9eaea6f65c   
audacious-plugins-4.0.5-4.el7 fluidsynth-2.1.8-4.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f706ca6458   
radsecproxy-1.9.0-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-8c50b78c57   
nginx-1.20.1-2.el7


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

centpkg-0.6.6-1.el7

Details about builds:



 centpkg-0.6.6-1.el7 (FEDORA-EPEL-2021-d7c1321604)
 CentOS utility for working with dist-git

Update Information:

Update to latest upstream release 0.6.6    Latest upstream 0.6.5

ChangeLog:

* Tue Jun  8 2021 Mohan Boddu  - 0.6.6-1
- Latest upstream
* Fri Jun  4 2021 Python Maint  - 0.6.5-2
- Rebuilt for Python 3.10
* Tue May 25 2021 Carl George  - 0.6.5-1
- Latest upstream


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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bb6ec0e942   
singularity-3.7.4-1.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1dd57fe441   
radsecproxy-1.9.0-1.el8


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

centpkg-0.6.6-1.el8
conda-4.10.1-2.el8
epel-release-8-11.el8
firebird-4.0.0.2496-1.el8
kirc-0.2.7-1.el8
python-conda-package-handling-1.7.3-2.el8
python-drgn-0.0.13-2.el8

Details about builds:



 centpkg-0.6.6-1.el8 (FEDORA-EPEL-2021-7e8ceb5660)
 CentOS utility for working with dist-git

Update Information:

Update to latest upstream release 0.6.6    Latest upstream 0.6.5

ChangeLog:

* Tue Jun  8 2021 Mohan Boddu  - 0.6.6-1
- Latest upstream
* Fri Jun  4 2021 Python Maint  - 0.6.5-2
- Rebuilt for Python 3.10
* Tue May 25 2021 Carl George  - 0.6.5-1
- Latest upstream




 conda-4.10.1-2.el8 (FEDORA-EPEL-2021-40fa556a93)
 Cross-platform, Python-agnostic binary package manager

Update Information:

Build for EPEL8

ChangeLog:





 epel-release-8-11.el8 (FEDORA-EPEL-2021-159d68a2ef)
 Extra Packages for Enterprise Linux repository configuration

Update Information:

Add epel-next-release subpackage.  See mailing list proposal for more details
about EPEL Next.  https://lists.fedoraproject.org/archives/list/epel-
de...@lists.fedoraproject.org/thread/NYXQNQFAY44RNCJTP6WLYUGJSQX5XSIX/

ChangeLog:

* Thu Jun  3 2021 Carl George  - 8-11
- Add epel-next-release subpackage




 firebird-4.0.0.2496-1.el8 (FEDORA-EPEL-2021-38992da22b)
 SQL relational database management system

Update Information:

Update to 4.0.0 (#1963311)

ChangeLog:

* Tue Jun  8 2021 Philippe Makowski  - 4.0.0.2496-1
- Update to 4.0.0 (#1963311)

References:

  [ 1 ] Bug #1963311 - firebird-4.0.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1963311




 kirc-0.2.7-1.el8 (FEDORA-EPEL-2021-c49197dabe)
 Tiny IRC client written in POSIX C99

Update Information:

Update to 0.2.7

ChangeLog:

* Tue Jun  8 2021 Davide Cavalca  - 0.2.7-1
- Update to 0.2.7

References:

  [ 1 ] Bug #1967597 - kirc-0.2.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1967597




 python-conda-package-handling-1.7.3-2.el8 (FEDORA-EPEL-2021-40fa556a93)
 Create and extract conda packages of various formats

Update Information:

Build for EPEL8

ChangeLog:





 python-drgn-0.0.13-2.el8 (FEDORA-EPEL-2021-fc6a924019)
 Scriptable debugger library

Update Information:

Update to 0.13.0

ChangeLog:

* Tue Jun  8 2021 Davide Cavalca  - 0.0.13-2
- Backport fix for s390x and drop the ExcludeArch
* 

[Bug 1968116] perl-POE-Component-IRC-6.91 is available

[bugzilla]

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



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

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

[Bug 1969474] perl-POE-Component-IRC-6.92 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1950383] please build perl-Archive-Extract for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed|2021-05-19 12:40:20 |2021-06-09 02:14:08



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


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Kevin Fenzi]

On Tue, Jun 08, 2021 at 05:44:20PM -0700, Michel Alexandre Salim via devel 
wrote:
> On Tue, Jun 08, 2021 at 05:38:27PM -0700, Michel Alexandre Salim via devel 
> wrote:
> > Hi,
> > 
> > On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> > > Hello.
> > > 
> > > As you might already know, we have recently merged in the Python 3.10 side
> > > tag to Rawhide, despite several builds not succeeding. We always aim for
> > > some compromise between having the side tag open for too long and having
> > > too many failures.
> > > 
> > > https://fedoraproject.org/wiki/Changes/Python3.10
> > > 
> > 
> > For some reason, `mock -r fedora-rawhide-x86_64 install python3` is
> > still pulling in python3-3.9.5-2.fc35.x86_64
> > 
> > This makes testing any fix rather difficult, as it will pass locally and
> > then fail when doing a Koji (scratch) build.
> > 
> > e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2
> > 
> For future reference, `mock --enablerepo=local` does the trick.

This is because rawhide composes are (still) broken. 
:(

Hopefully things will get fixed up soon...

kevin


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

[Bug 1968179] perl-Verilog-Perl-3.478 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1968116] perl-POE-Component-IRC-6.91 is available

[bugzilla]

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



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

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

[Bug 1967068] perl-Graphics-TIFF-15 is available

[bugzilla]

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



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

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

[Bug 1965838] perl-Graphics-TIFF-14 is available

[bugzilla]

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



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

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

Re: Heads Up: openexr 3.0 coming to Rawhide

[Richard Shaw]

On Tue, Jun 8, 2021 at 9:34 AM Josef Řídký  wrote:

> Well, the next question to answer is, should the package without active
> upstream maintenance be the reason for slowing down the progress of another
> project? Should such a package remain in Fedora at all?
>
> I would personally avoid to do such openexr2 package split, just because I
> know how painful it will become to get rid of such versions later from
> Fedora and do it just as transition never worked for me - it remained in
> the compose for much longer than expected, but it's just my 0.02$.
>

I'm tempted to just cancel the upgrade due to the OpenVDB debacle at this
point... I'll leave the COPR going for those that want to test their
packages ahead of time.

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Michel Alexandre Salim via devel]

On Tue, Jun 08, 2021 at 05:38:27PM -0700, Michel Alexandre Salim via devel 
wrote:
> Hi,
> 
> On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> > Hello.
> > 
> > As you might already know, we have recently merged in the Python 3.10 side
> > tag to Rawhide, despite several builds not succeeding. We always aim for
> > some compromise between having the side tag open for too long and having
> > too many failures.
> > 
> > https://fedoraproject.org/wiki/Changes/Python3.10
> > 
> 
> For some reason, `mock -r fedora-rawhide-x86_64 install python3` is
> still pulling in python3-3.9.5-2.fc35.x86_64
> 
> This makes testing any fix rather difficult, as it will pass locally and
> then fail when doing a Koji (scratch) build.
> 
> e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2
> 
For future reference, `mock --enablerepo=local` does the trick.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Michel Alexandre Salim via devel]

Hi,

On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> Hello.
> 
> As you might already know, we have recently merged in the Python 3.10 side
> tag to Rawhide, despite several builds not succeeding. We always aim for
> some compromise between having the side tag open for too long and having
> too many failures.
> 
> https://fedoraproject.org/wiki/Changes/Python3.10
> 

For some reason, `mock -r fedora-rawhide-x86_64 install python3` is
still pulling in python3-3.9.5-2.fc35.x86_64

This makes testing any fix rather difficult, as it will pass locally and
then fail when doing a Koji (scratch) build.

e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

[Bug 815713] perl-Padre-1.00 is available

[bugzilla]

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

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|jples...@redhat.com |extras-orphan@fedoraproject
   ||.org



--- Comment #7 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


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

[Bug 1964651] F35FailsToInstall: perl-Padre

[bugzilla]

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

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|jples...@redhat.com |extras-orphan@fedoraproject
   ||.org



--- Comment #4 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


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

[Bug 1964647] F35FailsToInstall: perl-Debug-Client

[bugzilla]

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

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|jples...@redhat.com |extras-orphan@fedoraproject
   ||.org



--- Comment #4 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


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

Re: [HEADS UP] libgta-1.2.1-5.fc34 successfully built

[Richard Shaw]

On Tue, Jun 8, 2021 at 6:24 PM Jiri Kucera  wrote:

> Hello,
>
> libgta-1.2.1-5.fc34 was built successfully[1] with side
> tag f34-build-side-42373. You can now rebuild your dependent packages
> against this side tag so I can create a Bodhi update.
>

It's a good practice to kick off builds yourself and then work with the
maintainers for any failures. I use the following script. I'm not a bash
expert so others may have better ones but it works for me:

First I run a needs_rebuilding script to see which packages need to be
rebuilt. This saves them to a file called "needs_rebuilding":

$ cat .local/bin/needs_rebuilding
#!/bin/bash

if [ $# -eq 0 ]
  then
echo "No arguments supplied"
echo "Usage: $0  [pkgname] ..."
exit 0
fi

provides=$(mktemp -t provides-XX)
deps=$(mktemp -t rawdeps-XX)

# Only break on newline not space or tab in for loops
IFS=$'\n'

for pkg in "$@"; do
echo "Checking for provides in $pkg."
dnf --quiet repoquery --repoid=rawhide --provides "$pkg" >> $provides
done

sed -i "/^bundled/d" $provides
sort -u -o $provides $provides

echo "Found $(wc -l $provides | awk '{print $1}') provides to be evaluated."

for dep in $(cat $provides); do
echo "Checking requirements for $dep"
dnf --quiet repoquery --repoid=rawhide --qf "%{source_name}" --whatrequires
"$dep" >> $deps
done

sort -u -o ./needs_rebuilding $deps

# Remove the packages being checked
for pkgname in "$@"; do
sed -i "/$pkgname/d" needs_rebuilding
done

echo "Rebuild dependencies saved to ./needs_rebuilding"

Then I have a rebuild script specifically for side tags:

$ cat .local/bin/rebuild-side-tag
#!/bin/bash

if [ $# -eq 0 ]
  then
echo "No arguments supplied"
echo "Usage: $0  "
exit 0
fi

sidetag=
commitmsg=

for pkg in $(cat ./needs_rebuilding); do
echo "Rebuilding $pkg"
tmpdir=$(mktemp -d -t $pkg-XX)
fedpkg clone $pkg $tmpdir
pushd $tmpdir
rpmdev-bumpspec -c "$1" $pkg.spec
fedpkg commit -c -p
fedpkg build --target=$2 --nowait
popd
done
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[HEADS UP] libgta-1.2.1-5.fc34 successfully built

[Jiri Kucera]

Hello,

libgta-1.2.1-5.fc34 was built successfully[1] with side
tag f34-build-side-42373. You can now rebuild your dependent packages
against this side tag so I can create a Bodhi update.

Regards,
Jiri

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

[Bug 1964651] F35FailsToInstall: perl-Padre

[bugzilla]

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



--- Comment #3 from Miro Hrončok  ---
This package has been orphaned.

You can pick it up at https://src.fedoraproject.org/rpms/perl-Padre by clicking
button "Take". If nobody picks it up, it will be retired and removed from a
distribution.


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

[Bug 1964647] F35FailsToInstall: perl-Debug-Client

[bugzilla]

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



--- Comment #3 from Miro Hrončok  ---
This package has been orphaned.

You can pick it up at https://src.fedoraproject.org/rpms/perl-Debug-Client by
clicking button "Take". If nobody picks it up, it will be retired and removed
from a distribution.


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

Re: Use of Epoch/improper ordering

[Daniel P . Berrangé]

On Tue, Jun 08, 2021 at 03:31:07PM -0500, Greg Hellings wrote:
> Quick question about the Epoch tag in a spec file: I goofed during F34's
> rawhide series and packaged an RC of my package with the wrong version name
> (1.9.0RC3-1 instead of 1.9.0-0.1) which causes it to sort higher in
> ordering than the final 1.9.0-5. From what I can gather, the proper
> resolution for this is to add an Epoch tag to the SRPM file and build
> 1:1.9.0-5. However, adding the epoch tag seems to have no effect. When I
> try to build, I'm told version 1.9.0-5 is already built for Rawhide/Fedora
> 34.
> 
> Is there a way to claw back the improperly versioned 1.9.0RC3 package from
> ages ago? Is there some magic to enable the Epoch tag that I'm missing? How
> do I get 1.9.0 final package out into Fedora?

This problem is because koji ignores the epoch when checking if a build
version already exists and stores output in directories whose name does
not contain the epoch. The solution is simply to *also* bump the release
tag to '6'. This makes koji see it is as a new build and the epoch change
makes the RPM upgrade path happy.

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

Use of Epoch/improper ordering

[Greg Hellings]

Quick question about the Epoch tag in a spec file: I goofed during F34's
rawhide series and packaged an RC of my package with the wrong version name
(1.9.0RC3-1 instead of 1.9.0-0.1) which causes it to sort higher in
ordering than the final 1.9.0-5. From what I can gather, the proper
resolution for this is to add an Epoch tag to the SRPM file and build
1:1.9.0-5. However, adding the epoch tag seems to have no effect. When I
try to build, I'm told version 1.9.0-5 is already built for Rawhide/Fedora
34.

Is there a way to claw back the improperly versioned 1.9.0RC3 package from
ages ago? Is there some magic to enable the Epoch tag that I'm missing? How
do I get 1.9.0 final package out into Fedora?

TIA

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

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

[Kevin Fenzi]

On Tue, Jun 08, 2021 at 01:03:24PM -0700, Troy Dawson wrote:
> It isn't just EPEL, I see this on all the calendar reminders I get from
> Fedora.  I wonder if there are two instances of the app running.
> 
> Does anyone know the right place to file a bug for this?

fedocal is in the process of being moved from a vm to a openshift
project. 

I've disabled the vm version now, so hopefully that will fix this. 

kevin
--
> 
> On Tue, Jun 8, 2021 at 11:48 AM Andrew C Aitchison 
> wrote:
> 
> >
> > I get two copies of the steering meeting reminders through
> > epel-devel@lists.fedoraproject.org,
> >
> > One has
> > Source: https://apps.fedoraproject.org/calendar/meeting/9854/
> > the other has
> > Source: https://calendar.fedoraproject.org//meeting/9854/
> >
> > Today's reminder is archived at
> >
> > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/TQXND3O5WEXQ7QYOVWHBSCCW3ZLKCIT2/
> > and
> >
> > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/IG5W4TJZWD7ZHJLT5USVNUVMGVSVLTFU/
> >
> > Is it possible to send just one of these to the list ?
> >
> > Thanks,
> >
> > --
> > Andrew C. Aitchison Kendal, UK
> > and...@aitchison.me.uk
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >

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



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

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

[Troy Dawson]

It isn't just EPEL, I see this on all the calendar reminders I get from
Fedora.  I wonder if there are two instances of the app running.

Does anyone know the right place to file a bug for this?

On Tue, Jun 8, 2021 at 11:48 AM Andrew C Aitchison 
wrote:

>
> I get two copies of the steering meeting reminders through
> epel-devel@lists.fedoraproject.org,
>
> One has
> Source: https://apps.fedoraproject.org/calendar/meeting/9854/
> the other has
> Source: https://calendar.fedoraproject.org//meeting/9854/
>
> Today's reminder is archived at
>
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/TQXND3O5WEXQ7QYOVWHBSCCW3ZLKCIT2/
> and
>
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/IG5W4TJZWD7ZHJLT5USVNUVMGVSVLTFU/
>
> Is it possible to send just one of these to the list ?
>
> Thanks,
>
> --
> Andrew C. Aitchison Kendal, UK
> and...@aitchison.me.uk
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 21:52, Jos de Kloe wrote:

I am seeing this error when trying to build locally using mock:

Error:
  Problem: package python3-xarray-0.17.0-1.fc35.noarch requires python(abi) = 
3.9, but none of the providers can be installed
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

   - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel versions? 
That should not happen I think with a mock rebuild command like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?


The conflict between i686 and x86_64 is just dnf resolver desperately trying to 
resolve somehow. When python3-xarray is rebuilt, you will not get that error.


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 21:52, Jos de Kloe wrote:

I am seeing this error when trying to build locally using mock:

Error:
  Problem: package python3-xarray-0.17.0-1.fc35.noarch requires python(abi) = 
3.9, but none of the providers can be installed
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

   - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel versions? 
That should not happen I think with a mock rebuild command like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?


The conflict between i686 and x86_64 is just dnf resolver desperately trying to 
resolve somehow. When python3-xarray is rebuilt, you will not get that error.


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Jos de Kloe]

I am seeing this error when trying to build locally using mock:

Error:
 Problem: package python3-xarray-0.17.0-1.fc35.noarch requires 
python(abi) = 3.9, but none of the providers can be installed
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

  - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' 
to use not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel 
versions? That should not happen I think with a mock rebuild command 
like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?

Jos

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

As you might already know, we have recently merged in the Python 
3.10side tagto Rawhide, despite several builds not succeeding.We always 
aim for some compromise between having the side tag open for too long 
and having too many failures.


https://fedoraproject.org/wiki/Changes/Python3.10 



The packages, when not rebuilt, are not installable in rawhide, hence 
fixing them should be our top priority. If you need help with 
Python-related issues, we (the Python Maintenance team at Red Hat) are 
happy to help. Unfortunately, several packages fail to build for 
Python-unrelated reasons.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, that your package fails to 
install. It would be really helpful if you could find the missing 
dependency and mark the bugzilla for your package dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.

Maintainers by package:
5minute  pmoravco
APLpy    sergiopr 

Re: Packages that failed to build with Python 3.10 (and what to do)

[Jos de Kloe]

I am seeing this error when trying to build locally using mock:

Error:
 Problem: package python3-xarray-0.17.0-1.fc35.noarch requires 
python(abi) = 3.9, but none of the providers can be installed
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

  - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' 
to use not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel 
versions? That should not happen I think with a mock rebuild command 
like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?

Jos

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

As you might already know, we have recently merged in the Python 
3.10side tagto Rawhide, despite several builds not succeeding.We always 
aim for some compromise between having the side tag open for too long 
and having too many failures.


https://fedoraproject.org/wiki/Changes/Python3.10 



The packages, when not rebuilt, are not installable in rawhide, hence 
fixing them should be our top priority. If you need help with 
Python-related issues, we (the Python Maintenance team at Red Hat) are 
happy to help. Unfortunately, several packages fail to build for 
Python-unrelated reasons.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, that your package fails to 
install. It would be really helpful if you could find the missing 
dependency and mark the bugzilla for your package dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.

Maintainers by package:
5minute  pmoravco
APLpy    sergiopr 

Re: [HEADS UP] libgta SONAME bump in Fedora 34

[Jiri Kucera]

Good to know, thanks Zbyszek.

On Tue, Jun 8, 2021 at 6:47 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jun 08, 2021 at 05:43:37PM +0200, Jiri Kucera wrote:
> > Hello,
> >
> > I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
> > bumps its SONAME. The list of affected components is below
>
> There should be no need to rebuild indirect dependencies. If those
> indirect dependencies were to use any symbols from libgta, they would
> be linked directly.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] libgta SONAME bump in Fedora 34

[Jiri Kucera]

Hi Dominik,

from paraview source rpm is produced paraview-devel which is a dependency
of libeml-devel and libmatroska-devel:

[root@fedora ~]# dnf --enablerepo '*-source' repoquery --whatrequires
paraview-devel
Last metadata expiration check: 0:01:10 ago on Tue 08 Jun 2021 05:26:24 PM
UTC.
libebml-devel-0:1.4.2-1.fc34.i686
libebml-devel-0:1.4.2-1.fc34.x86_64
libmatroska-devel-0:1.6.2-2.fc34.i686
libmatroska-devel-0:1.6.2-2.fc34.x86_64
libmatroska-devel-0:1.6.3-1.fc34.i686
libmatroska-devel-0:1.6.3-1.fc34.x86_64

Regards,
Jiri

On Tue, Jun 8, 2021 at 5:55 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Hi!
>
> On Tuesday, 08 June 2021 at 17:43, Jiri Kucera wrote:
> > Hello,
> >
> > I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
> > bumps its SONAME. The list of affected components is below (the list is
> not
> > complete, the path from some packages to libgta in dependency graph is
> too
> > long):
> >
> > libgta:
> ...
> > paraview:
> >   libebml:
> > gerbera (build requirement)
> > mkvtoolnix
> >   libmatroska
>
> What does paraview have to do with libebml or libmatroska? I can't find
> any dependencies here.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that failed to build with Python 3.10 (and what to do)

[Ankur Sinha]

On Tue, Jun 08, 2021 15:58:04 +0200, Tomas Hrnciar wrote:
> ankursinha MUSIC python-SALib python-brian2 python-dipy python-duecredit
> python-fastavro python-fsleyes-props python-fslpy python-hdfs python-klusta
> python-matrix-nio python-nilearn python-nitime python-nixio python-pingouin
> python-pybids python-pymatreader python-pypet python-pyphi python-pyriemann
> python-pyscaffold python-sklearn-nature-inspired-algorithms python-trimesh

Woah! :D

I'll start looking into these now. Hopefully they're all simple fixes.

Thanks again for all your work.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 19:19, Antonio T. sagitter wrote:

I need help for PETSC, please.

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


I took a look and reported https://bugs.python.org/issue44351

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 19:19, Antonio T. sagitter wrote:

I need help for PETSC, please.

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


I took a look and reported https://bugs.python.org/issue44351

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

Re: userspace-rcu 0.13.0 soname bump

[Michael Jeanson]

On 2021-06-08 14 h 47, Kaleb Keithley wrote:
On Tue, Jun 8, 2021 at 2:31 PM Michael Jeanson 

I have started the process to update userspace-rcu to 0.13 in rawhide
which implies a soname bump to 8.

Does that imply python3.10 too?


Yes, I explicitly waited for python 3.10 to land before starting the 
side tag.


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

Re: userspace-rcu 0.13.0 soname bump

[Kaleb Keithley]

On Tue, Jun 8, 2021 at 2:31 PM Michael Jeanson 
wrote:

> I have started the process to update userspace-rcu to 0.13 in rawhide
> which implies a soname bump to 8.
>

Does that imply python3.10 too?


>  From what I understand, the following packages will need to be rebuilt:
>
> device-mapper-multipath
> glusterfs
> knot
> libntirpc
> lttng-tools
> lttng-ust
> netsniff-ng
> nfs-ganesha
>
>
I'll build mine: glusterfs, libntirpc, and nfs-ganesha once I know the
answer to the python-3.10 question.


> I have created a side tag 'f35-build-side-42347' and built
> userspace-rcu, lttng-ust and lttng-tools. At this point I'm unsure what
> the rest of the procedure is to get the other packages built in this tag
> and then get them pushed to rawhide once it's done.
>

--

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

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

[Andrew C Aitchison]

I get two copies of the steering meeting reminders through 
epel-devel@lists.fedoraproject.org,


One has
Source: https://apps.fedoraproject.org/calendar/meeting/9854/
the other has
Source: https://calendar.fedoraproject.org//meeting/9854/

Today's reminder is archived at
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/TQXND3O5WEXQ7QYOVWHBSCCW3ZLKCIT2/
and
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/IG5W4TJZWD7ZHJLT5USVNUVMGVSVLTFU/

Is it possible to send just one of these to the list ?

Thanks,

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

userspace-rcu 0.13.0 soname bump

[Michael Jeanson]

I have started the process to update userspace-rcu to 0.13 in rawhide 
which implies a soname bump to 8.


From what I understand, the following packages will need to be rebuilt:

device-mapper-multipath
glusterfs
knot
libntirpc
lttng-tools
lttng-ust
netsniff-ng
nfs-ganesha


I have created a side tag 'f35-build-side-42347' and built 
userspace-rcu, lttng-ust and lttng-tools. At this point I'm unsure what 
the rest of the procedure is to get the other packages built in this tag 
and then get them pushed to rawhide once it's done.


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

Summary/Minutes from today's FESCo Meeting (2021-06-08)

[Zbigniew Jędrzejewski-Szmek]

Meeting started by zbyszek at 17:00:06 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2021-06-08/fesco.2021-06-08-17.00.log.html
.



Meeting summary
---
* init process  (zbyszek, 17:00:07)

* New meeting time?  (zbyszek, 17:03:00)
  * ACTION: zbyszek will make a whenisgood poll  (zbyszek, 17:03:58)

* #2617 F35 Change: Make btrfs the default file system for Fedora Cloud
  (zbyszek, 17:06:36)
  * AGREED: We'll wait a week for more discussion and information about
userspace access options.  (zbyszek, 17:27:35)
  * ACTION: Eighth_Doctor, cmurf, dcavalca, michel will provide some
more information about userspace access options  (zbyszek, 17:28:19)

* Next week's chair  (zbyszek, 17:28:52)
  * ACTION: sghallagh will chair next meeting  (zbyszek, 17:29:57)

Action Items, by person
---
* Eighth_Doctor, cmurf, dcavalca, michel will provide some more
  information about userspace access options
* zbyszek will make a whenisgood poll
* sghallagh will chair next meeting
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: What about future EPEL for Centos ?

[Leon Fauster]

On 08.06.21 15:11, Miroslav Suchý wrote:

Dne 07. 06. 21 v 17:52 Matthew Miller napsal(a):
Troy answered the overall questions separately, but... in practice, I 
expect

this to be a very small issue.


Small issue in Koji and for Fedora Project itself. But can be bummer 
when you try to build your set of packages on top of EPEL. Or rebuild 
the EPEL package locally in Mock. Because then you have to do 
non-trivial amount of work [1]. And what is worse - the path has been 
tested by only few people so far.


[1] 
https://github.com/rpm-software-management/mock/wiki/Feature-rhelchroots




BTW and JFI:
COPR is preparing rhelchroots - maybe for 2022 Q1 (just speculation)
More here - https://bugzilla.redhat.com/show_bug.cgi?id=1965480

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Antonio T. sagitter]

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

As you might already know, we have recently merged in the Python 
3.10side tagto Rawhide, despite several builds not succeeding.We always 
aim for some compromise between having the side tag open for too long 
and having too many failures.


https://fedoraproject.org/wiki/Changes/Python3.10 



The packages, when not rebuilt, are not installable in rawhide, hence 
fixing them should be our top priority. If you need help with 
Python-related issues, we (the Python Maintenance team at Red Hat) are 
happy to help. Unfortunately, several packages fail to build for 
Python-unrelated reasons.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, that your package fails to 
install. It would be really helpful if you could find the missing 
dependency and mark the bugzilla for your package dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.


> ...

petsc sagitter


I need help for PETSC, please.

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

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Antonio T. sagitter]

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

As you might already know, we have recently merged in the Python 
3.10side tagto Rawhide, despite several builds not succeeding.We always 
aim for some compromise between having the side tag open for too long 
and having too many failures.


https://fedoraproject.org/wiki/Changes/Python3.10 



The packages, when not rebuilt, are not installable in rawhide, hence 
fixing them should be our top priority. If you need help with 
Python-related issues, we (the Python Maintenance team at Red Hat) are 
happy to help. Unfortunately, several packages fail to build for 
Python-unrelated reasons.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, that your package fails to 
install. It would be really helpful if you could find the missing 
dependency and mark the bugzilla for your package dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.


> ...

petsc sagitter


I need help for PETSC, please.

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

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Stephen John Smoogen]

On Tue, 8 Jun 2021 at 12:27, Stephen Gallagher  wrote:

> On Tue, Jun 8, 2021 at 10:51 AM Tom Hughes  wrote:
> >
> > On 08/06/2021 14:51, Stephen Gallagher wrote:
> >
> > > I was thinking about suggesting a similar PAM module to convert
> > > existing hashes, but I suspect that we'd be coming up against some
> > > issues with security policy and separation of actions. Right now, I
> > > expect that SELinux permits PAM processes to have read-only access to
> > > /etc/shadow, but such a change would necessitate read/write access,
> > > which is riskier. It's also why PAM has separate activities for
> > > authentication, authorization and password-change.
> >
> > Surely it has to allow write as well because any authentication can
> > already prompt for a password change if the password is expired?
> >
>
> It's been a while, but I *think* I remember that PAM sends back an
> "expired password" message and the client application (eg. `login`)
> then calls the pam_chpass() stack.
> ___
>

I believe it is something like that. mainly because there are many systems
where a password change is a major auditable event and you only want those
generated from specific systems and then pushed out. [Yes this doesn't fit
well with the world of today, but the PAM stack was written for the
security policies and actions of the late 1980's/early 1990's... ]

-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: older than 30 days and empty side tag clean up

[Michel Alexandre Salim via devel]

On Fri, Jun 04, 2021 at 09:46:00PM +0200, Fabio Valentini wrote:
> On Fri, Jun 4, 2021 at 8:58 PM Kevin Fenzi  wrote:
> >
> > On Fri, Jun 04, 2021 at 01:07:39PM -0500, Richard Shaw wrote:
> > > On Fri, Jun 4, 2021 at 12:26 PM Kevin Fenzi  wrote:
> > >
> > > > Greetings.
> > > >
> > > > Release engineering has just enabled a cron job to remove koji side tags
> > > > that are older than 30 days or have no builds tagged into them.
> > > >
> > >
> > > It would be nice if they automatically deleted themselves after being used
> > > in a Bodhi update.
> >
> > They are supposed to be. koji has:
> > remove_empty = on
> > which is supposed to delete sidetags that are empty.
> > I'm not sure why thats not working, need to file a issue on it...
> >
> > That only handles the empty case tho, not the old.
> >
> > >
> > > Can they be deleted immediately or do we need to wait until the update 
> > > goes
> > > stable?
> >
> > Should be able to delete them right after the update appears.
> 
> Well, there are two different cases here, aren't there?
> 
> For side tags created for rawhide, they are - in my experience -
> automatically deleted by bodhi once the update goes to stable, shortly
> after it is created.
> 
> For those created for stable releases, I think it makes sense to keep
> them around until the update is pushed to stable, too - otherwise you
> won't be able to edit the update at all. It looks like the bug that
> bodhi didn't delete those side tags after the update is pushed to
> stable has been fixed? At least, all my
> side-tags-for-stable-release-updates-that-are-now-stable are gone.
> 
Is there a race condition here? If e.g. the maintainer takes some time to get
a complicated set of packages all built, and the updates get published to Bodhi
on day 25 ... by the time they get auto-pushed to stable it will be day 32 or 
33.

Perhaps side tags associated with an in-progress update should be excluded.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Re: [HEADS UP] libgta SONAME bump in Fedora 34

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 08, 2021 at 05:43:37PM +0200, Jiri Kucera wrote:
> Hello,
> 
> I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
> bumps its SONAME. The list of affected components is below

There should be no need to rebuild indirect dependencies. If those
indirect dependencies were to use any symbols from libgta, they would
be linked directly.

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Michel Alexandre Salim via devel]

On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> Hello.
> 
> As you might already know, we have recently merged in the Python 3.10 side
> tag to Rawhide, despite several builds not succeeding. We always aim for
> some compromise between having the side tag open for too long and having
> too many failures.
> 
> https://fedoraproject.org/wiki/Changes/Python3.10
> 
...
> fbthrift dcavalca filbranden salimma
> follydcavalca filbranden salimma
> watchman dcavalca filbranden salimma
> 
These are all related; I'll try to get them fixed. There's a known issue with 
fbthrift's use of Cython that has been affecting rebuilds for the past few 
weeks, so now is as good a time as any.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Stephen Gallagher]

On Tue, Jun 8, 2021 at 10:51 AM Tom Hughes  wrote:
>
> On 08/06/2021 14:51, Stephen Gallagher wrote:
>
> > I was thinking about suggesting a similar PAM module to convert
> > existing hashes, but I suspect that we'd be coming up against some
> > issues with security policy and separation of actions. Right now, I
> > expect that SELinux permits PAM processes to have read-only access to
> > /etc/shadow, but such a change would necessitate read/write access,
> > which is riskier. It's also why PAM has separate activities for
> > authentication, authorization and password-change.
>
> Surely it has to allow write as well because any authentication can
> already prompt for a password change if the password is expired?
>

It's been a while, but I *think* I remember that PAM sends back an
"expired password" message and the client application (eg. `login`)
then calls the pam_chpass() stack.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-06-09 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.net

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

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




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

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

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

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-06-09 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.net

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

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




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

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

Re: [HEADS UP] libgta SONAME bump in Fedora 34

[Dominik 'Rathann' Mierzejewski]

Hi!

On Tuesday, 08 June 2021 at 17:43, Jiri Kucera wrote:
> Hello,
> 
> I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
> bumps its SONAME. The list of affected components is below (the list is not
> complete, the path from some packages to libgta in dependency graph is too
> long):
> 
> libgta:
...
> paraview:
>   libebml:
> gerbera (build requirement)
> mkvtoolnix
>   libmatroska

What does paraview have to do with libebml or libmatroska? I can't find
any dependencies here.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Björn 'besser82' Esser]

Am Dienstag, dem 08.06.2021 um 15:08 +0100 schrieb Tom Hughes via devel:
> On 08/06/2021 14:51, Stephen Gallagher wrote:
> 
> > I was thinking about suggesting a similar PAM module to convert
> > existing hashes, but I suspect that we'd be coming up against some
> > issues with security policy and separation of actions. Right now, I
> > expect that SELinux permits PAM processes to have read-only access
> > to
> > /etc/shadow, but such a change would necessitate read/write access,
> > which is riskier. It's also why PAM has separate activities for
> > authentication, authorization and password-change.
> 
> Surely it has to allow write as well because any authentication can
> already prompt for a password change if the password is expired?


Well, extending the pam_unix module in such a way, may be the best
solution:

  * User logs in.
  * PAM checks password
  * hash is not $y$
  * silently rehash plain password with yescrypt
  * update shadow
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Björn 'besser82' Esser]

Am Dienstag, dem 08.06.2021 um 09:22 -0500 schrieb Martin Jackson:
> 
> On 6/8/21 9:13 AM, Ewoud Kohl van Wijngaarden wrote:
> > On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser
> > wrote:
> > > Unfortunately there is no automatic way to update the hash from
> > > anything, but yescrypt, to yescrypt without knowing / entering the
> > > actual user password; in the future existing yescrypt hashes can be
> > > updated to new yescrypt hashes with stronger salts and/or cost
> > > parameters in-place without changing the password, and without user
> > > interaction.
> > > 
> > > Has anyone some better idea?
> > 
> > they use older distros that don't support it, it'll end up flapping 
> > where one system sets it to the older hashing and one to the newer.
> > 
> > Or maybe I'm just the only person who does this.
>
> Indeed you are not the only one.  Even in large LDAP shops, there
> could 
> be a local "break-glass" account, so managing hashes could still be a 
> factor in those environments.
> 
> One of the pain points of managing a large-scale Puppet infrastructure
> is supporting different hashes for different OS's. I've seen this
> done, 
> and the result is...not always pretty.
> 
> What does usage of yescrypt look like in the rest of the ecosystem? 
> Are 
> other major distros moving to it, or likely to?

Debian is moving to yescrypt; ALT Linux and Kali Linux have already
switched.  Most other distributions, that ship libxcrypt >= 4.3 have
support for yescrypt and are able to deal with $y$ shadow hashes out of
the box; they simply just lack the adaption of the tools (shadow-utils,
pam, etc.) to use it as hash method for *creating* shadow hashes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[HEADS UP] libgta SONAME bump in Fedora 34

[Jiri Kucera]

Hello,

I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
bumps its SONAME. The list of affected components is below (the list is not
complete, the path from some packages to libgta in dependency graph is too
long):

libgta:
  OpenSceneGraph:
FlightGear
FlightGear-Atlas (build requirement)
SimGear
fgrun
gpick (build requirement)
osgearth
scribus:
  scribus-generator
speed-dreams
  gdal:
GMT
OpenSceneGraph
PDAL
R-rgdal:
  R-rgeos (build requirement):
R-broom (build requirement):
  R-dplyr (build requirement):

  R-geepack
  R-modelr (build requirement)
R-ggplot2 (build requirement):
  
bes:
  ocsinventory-agent
  php-horde-horde:

cloudcompare
dans-gdal-scripts
gazebo:
  fawkes
grass
liblas
libosmium:
  osm2pgsql (build requirement)
  osmium-tool (build requirement)
  pyosmium (build requirement)
mapnik:
  python-mapnik:
nik4
  viking
mapserver
merkaartor
ncl
ogr2osm
opencv:
  
osgearth
paraview:
  libebml:
gerbera (build requirement)
mkvtoolnix
  libmatroska
postgis:
  pgRouting
python-cartopy (build requirement):
  pygrib (build requirement)
  python-geoplot:
python-missingno
python-fiona:
  python-geopandas:
python-earthpy
python-libpysal (build requirement)
python-mapclassify (build requirement)
python-networkx (build requirement):
  
python-phyghtmap
python-rasterio:
  python-contextily
  python-xarray (build requirement):

python-tilestache (build requirement)
qgis
qmapshack
saga
vfrnav
vtk:
  InsightToolkit:
petpvc
  Mayavi:
python-tvb-data
  engrid
  freecad (build requirement)
  libASL
  maxima (build requirement):
sagemath
wxMaxima
  mrpt
  opencascade:
gmsh:
  getdp (build requirement)
kicad
netgen-mesher
  openmeeg (build requirement)
  pcl
  python-cclib
  smesh
xastir (build requirement)

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

valgrinded executable seem to run far more slowly in Rawhide

[Richard W.M. Jones]

I haven't filed a bug yet because I'm not sure what component to
assign this too.  I upgraded to Rawhide this morning and noticed that
some tests that previously ran OK are now timing out.  It turned out
that the tests were failing because a valgrinded executable runs much
more slowly in Rawhide today.

Here's my test:

Upgrade to Rawhide and install these additional packages:

  # dnf install libnbd nbdkit valgrind

Unpack the certificates from
http://oirase.annexia.org/tmp/rawhide-valgrind-bug/pki.tar.gz into /tmp

Run this command as NON-root (it's self-contained and just connects
the two commands together over localhost port 10809):

  $ time nbdkit --tls=require --tls-certificates=/tmp/pki null --run 'valgrind 
nbdinfo nbds://localhost'

For me this takes over 40 seconds in Rawhide, versus a couple of
seconds in Fedora 33/34.  Also if you remove "valgrind" it runs
instantaneously even in Rawhide.  If you run it as root, it runs
quickly again (WTF!)

The perf flamegraph seems to indicate it's doing a lot of stuff with
DWARF 3 symbols.

  http://oirase.annexia.org/tmp/rawhide-valgrind-bug/libnbd.svg

Uninstalling all relevant debuginfo packages didn't seem to help.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1969474] perl-POE-Component-IRC-6.92 is available

[bugzilla]

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



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


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

[Bug 1969474] perl-POE-Component-IRC-6.92 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-7daf9701c8 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7daf9701c8


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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Björn 'besser82' Esser]

Am Di., 8. Juni 2021 um 15:46 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote:
> > Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones
> > :
> > >
> > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote:
> > > > == Dependencies ==
> > > > * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> > > > * authselect: https://github.com/authselect/authselect/pull/253
> > > > * libuser: WIP ongoing
> > > > * shadow-utils: 
> > > > https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
> > > >
> > > > * pam: Is already capable to use yescrypt.
> > > > * libxcrypt: Is already capable for computing yescrypt hashes.
> > >
> > > libguestfs (virt-customize etc.) might also need changing.  What
> > > happens if a new user account is created with (eg) $6$ sha512.  Does
> > > it use that scheme forever?  Attempt to upgrade it?  Break?
> >
> > Well, yes, that needs to be updated, too, but it's written in OCAML…
> > I suppose, you want to volunteer, and get a well deserved F35 change
> > badge for doing so?!  :P
> >
> > If a user account is created with a sha512crypt hash, it will keep it
> > as long as the password remains unchanged.  I'm currently thinking of
> > a way to migrate all local users to use yescrypt hashes, but it's not
> > that easy: Human users could be prompted on first login to change
> > their password, if the hash in shadow is not yescrypt - there is a way
> > to force that.  But what about local users with older password hashes
> > that get logged in by any non-human interaction, like www-cron; those
> > would need to be updated manually by the system admin.  Maybe I can
> > write a CLI-tool for doing so.
> >
> > Unfortunately there is no automatic way to update the hash from
> > anything, but yescrypt, to yescrypt without knowing / entering the
> > actual user password;
>
> I think it's better to leave existing passwords in place. You can't
> really force people to log in as all users, so the only realistic
> scenario is to keep existing passwords if there's more than one user.
>
> And I don't think there's a reason to try to force immediate password
> switch. As far as we know, previous defaults like sha256 are OK.
>
> > in the future existing yescrypt hashes can be
> > updated to new yescrypt hashes with stronger salts and/or cost
> > parameters in-place without changing the password, and without user
> > interaction.
>
> Interesting. How does this work?

You can find a basic description here:

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

Re: Heads Up: openexr 3.0 coming to Rawhide

[Josef Řídký]

Well, the next question to answer is, should the package without active
upstream maintenance be the reason for slowing down the progress of another
project? Should such a package remain in Fedora at all?

I would personally avoid to do such openexr2 package split, just because I
know how painful it will become to get rid of such versions later from
Fedora and do it just as transition never worked for me - it remained in
the compose for much longer than expected, but it's just my 0.02$.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Jun 7, 2021 at 6:20 PM Richard Shaw  wrote:

> I've been able to update several packages to build with OpenEXR 3 but
> there are many more to go, perhaps too many for me to handle.
>
> Specifically (and ironically) OpenVDB which is also a project under the
> stewardship of the ASWF has not had a single commit to it to be compatible
> with OpenEXR 3.
>
> For that reason I'm considering submitting for an openexr2 package. But
> that means really mapping out the dependency chain, right? We don't want
> both packages used within the same "stack".
>
> Thoughts?
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Fedocal] Reminder meeting : Fedora Source-git SIG

[csomh]

Dear all,

You are kindly invited to the meeting:
   Fedora Source-git SIG on 2021-06-09 from 14:30:00 to 15:30:00 GMT
   At meet.google.com/mic-otnv-kse

The meeting will be about:
Bi-weekly meeting of the Fedora source-git SIG

Agenda:
https://pagure.io/fedora-source-git/sig/issues?tags=meeting=Open

SIG Info:
https://fedoraproject.org/wiki/SIGs/Source-git


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

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

[Fedocal] Reminder meeting : Fedora Source-git SIG

[csomh]

Dear all,

You are kindly invited to the meeting:
   Fedora Source-git SIG on 2021-06-09 from 14:30:00 to 15:30:00 GMT
   At meet.google.com/mic-otnv-kse

The meeting will be about:
Bi-weekly meeting of the Fedora source-git SIG

Agenda:
https://pagure.io/fedora-source-git/sig/issues?tags=meeting=Open

SIG Info:
https://fedoraproject.org/wiki/SIGs/Source-git


Source: https://apps.fedoraproject.org/calendar/meeting/9982/

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

[Bug 1969474] perl-POE-Component-IRC-6.92 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-POE-Component-IRC-6.92
   ||-1.fc35



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.


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

[Bug 1969474] perl-POE-Component-IRC-6.92 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Martin Jackson]

Indeed you are not the only one.  Even in large LDAP shops, there could 
be a local "break-glass" account, so managing hashes could still be a 
factor in those environments.


One of the pain points of managing a large-scale Puppet infrastructure 
is supporting different hashes for different OS's. I've seen this done, 
and the result is...not always pretty.


What does usage of yescrypt look like in the rest of the ecosystem?  Are 
other major distros moving to it, or likely to?


Marty

On 6/8/21 9:13 AM, Ewoud Kohl van Wijngaarden wrote:

On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote:

Unfortunately there is no automatic way to update the hash from
anything, but yescrypt, to yescrypt without knowing / entering the
actual user password; in the future existing yescrypt hashes can be
updated to new yescrypt hashes with stronger salts and/or cost
parameters in-place without changing the password, and without user
interaction.

Has anyone some better idea?


I'd advise against this. People can use a system like Puppet to sync 
password hashes between systems (as a cheap alternative to LDAP). If 
they use older distros that don't support it, it'll end up flapping 
where one system sets it to the older hashing and one to the newer.


Or maybe I'm just the only person who does this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Bug 1964647] F35FailsToInstall: perl-Debug-Client

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

  Flags|needinfo?(jplesnik@redhat.c |
   |om) |



--- Comment #2 from Jitka Plesnikova  ---
I orphaned the package.


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

[Bug 1964651] F35FailsToInstall: perl-Padre

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

  Flags|needinfo?(jplesnik@redhat.c |
   |om) |



--- Comment #2 from Jitka Plesnikova  ---
I orphaned the package.


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

Orphaning perl-Debug-Client and perl-Padre

[Jitka Plesnikova - Gmail]

I've just orphaned packages:

perl-Debug-Client (https://src.fedoraproject.org/rpms/perl-Debug-Client)
perl-Padre (https://src.fedoraproject.org/rpms/perl-padre)

perl-Debug-Client is not possible to build with Perl 5.34. It is
required only
by perl-Padre. Upstreams of the packages have been inactive for a few
years and
it probably won't be fixed early.

Jitka

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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote:

Unfortunately there is no automatic way to update the hash from
anything, but yescrypt, to yescrypt without knowing / entering the
actual user password; in the future existing yescrypt hashes can be
updated to new yescrypt hashes with stronger salts and/or cost
parameters in-place without changing the password, and without user
interaction.

Has anyone some better idea?


I'd advise against this. People can use a system like Puppet to sync 
password hashes between systems (as a cheap alternative to LDAP). If 
they use older distros that don't support it, it'll end up flapping 
where one system sets it to the older hashing and one to the newer.


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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Tom Hughes via devel]

On 08/06/2021 14:51, Stephen Gallagher wrote:


I was thinking about suggesting a similar PAM module to convert
existing hashes, but I suspect that we'd be coming up against some
issues with security policy and separation of actions. Right now, I
expect that SELinux permits PAM processes to have read-only access to
/etc/shadow, but such a change would necessitate read/write access,
which is riskier. It's also why PAM has separate activities for
authentication, authorization and password-change.


Surely it has to allow write as well because any authentication can
already prompt for a password change if the password is expired?

Tom

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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 6/8/21 3:18 PM, Björn 'besser82' Esser wrote:

I'm currently thinking of
a way to migrate all local users to use yescrypt hashes, but it's not
that easy: Human users could be prompted on first login to change
their password, if the hash in shadow is not yescrypt - there is a way
to force that.


This is a very bad choice. SHA512crypt still not cracked -> no need to 
force users to change their passwords.


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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Ian McInerney]

On Tue, Jun 8, 2021 at 2:46 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote:
> > Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones
> > :
> > >
> > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote:
> > > > == Dependencies ==
> > > > * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> > > > * authselect: https://github.com/authselect/authselect/pull/253
> > > > * libuser: WIP ongoing
> > > > * shadow-utils:
> https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
> > > >
> > > > * pam: Is already capable to use yescrypt.
> > > > * libxcrypt: Is already capable for computing yescrypt hashes.
> > >
> > > libguestfs (virt-customize etc.) might also need changing.  What
> > > happens if a new user account is created with (eg) $6$ sha512.  Does
> > > it use that scheme forever?  Attempt to upgrade it?  Break?
> >
> > Well, yes, that needs to be updated, too, but it's written in OCAML…
> > I suppose, you want to volunteer, and get a well deserved F35 change
> > badge for doing so?!  :P
> >
> > If a user account is created with a sha512crypt hash, it will keep it
> > as long as the password remains unchanged.  I'm currently thinking of
> > a way to migrate all local users to use yescrypt hashes, but it's not
> > that easy: Human users could be prompted on first login to change
> > their password, if the hash in shadow is not yescrypt - there is a way
> > to force that.  But what about local users with older password hashes
> > that get logged in by any non-human interaction, like www-cron; those
> > would need to be updated manually by the system admin.  Maybe I can
> > write a CLI-tool for doing so.
> >
> > Unfortunately there is no automatic way to update the hash from
> > anything, but yescrypt, to yescrypt without knowing / entering the
> > actual user password;
>
> I think it's better to leave existing passwords in place. You can't
> really force people to log in as all users, so the only realistic
> scenario is to keep existing passwords if there's more than one user.
>
> And I don't think there's a reason to try to force immediate password
> switch. As far as we know, previous defaults like sha256 are OK.
>

Yes, please do not force users to change their password just to use the new
hash. Fedora can be used as a personal workstation distribution, so people
may have their own policies/decisions on when they want to change passwords
- and simply upgrading the OS may not be part of that policy.

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

Re: older than 30 days and empty side tag clean up

[Kevin Fenzi]

On Tue, Jun 08, 2021 at 10:08:05AM +, Mattia Verga via devel wrote:
> Il 06/06/21 19:53, Kevin Fenzi ha scritto:
> > On Sun, Jun 06, 2021 at 07:40:41AM +, Mattia Verga via devel wrote:
> >> I thought that deleting a side-tag would delete all its child
> >> (*-testing-pending and similar), but it doesn't seem so:
> >>
> >> https://koji.fedoraproject.org/koji/search?match=glob=tag=f35-build-side-40730*
> >>
> >> It seems that this side-tag has been deleted, but its child were not. Is
> >> it this the right behavior? I'd like to know because if we want Bodhi to
> >> delete the side-tag, it would be simpler if deleting the parent tag also
> >> delete its childs.
> > Odd, yes, I thought it deleted the associated tags too.
> >
> > kevin
> 
> So, I've reported this to Koji upstream [1], and it turned out this is
> the expected behavior.
> 
> We can set Bodhi to remove children tags when the side-tag is deleted,
> but I think releng's cronjob that removes old side-tag should be updated
> to take children tags into consideration. However I can't find anywhere
> in ansible or releng repository where `koji-sidetag-cleanup` script is.

Because it's part of/shipped by koji itself. :)

kevin


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

Re: [cdparanoia] License field fix awaiting to be merged

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 07, 2021 at 06:27:17PM +0200, Jiri Kucera wrote:
> Hi Zbyszek,
> 
> reply inline
> 
> On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > On Wed, Jun 02, 2021 at 01:31:15PM -, Benjamin Beasley wrote:
> > > > So, it doesn't really matter if two source files are distributed under
> > the GPLv2+ license.
> > > > The resulting binary (i.e. /usr/bin/cdparanoia) will always be GPLv2.
> > > > […]
> > > > But Licensing Guidelines make clear that the License: field refers to
> > the
> > > > binary packages not source ones.
> > > >
> > > > BR,
> > > >
> > > > Andrea
> > >
> > > The “effective license” approach you advocated is not mentioned in the
> > packaging guidelines but has historical support in the wiki (
> > https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F).
> > It has also come up on the fedora-legal list recently (
> > https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/W57JRNLWVOT55D7TDF7VYFMJT5QMBEGR/
> > ).
> >
> > FWIW, the licensing guidelines live on the wiki. There is nothing
> > "historical" about the Licensing:FAQ document, it is still the official
> > guide of how to interpret the Licensing:Main page.
> >
> > I know Ben wrote something that disagrees with the document, but
> > I think he is wrong. It also goes against the long-established practice.
> > And if we want to change the rules, the document that specifies them
> > should be changed, a post on the mailing list is not enough.
> >
> > > There is, I think, a valid question of how much mechanistic detail to
> > apply to documenting the source files *that contribute to the binary RPM
> > contents.* One approach, which I have favored in my packages, exhaustively
> > lists licenses of such files. The other, which you have advocated,
> > simplifies the license field into an “effective license” when clearly
> > appropriate. Both philosophies seem to be well-established as acceptable.
> > My view is therefore this patch seems to be correct but not absolutely
> > required.
> >
> > No, the patch is wrong. It's not super harmful, but it's still wrong.
> >
> 
> So what should be the correct License then? According to [1], the one
> possibility is
> 
>   License: (GPLv2 and GPLv2+) and LGPLv2
> 
> but according to [2] point 2, this should be shortened to
> 
>   License: GPLv2 and LGPLv2
> 
> because GPLv2 is stricter.

Yes, the second version is correct. The first version is not correct,
because it's trying to say that you can distribute some specific
binary under terms of "GPLv2 and GPLv2-or-any-later" at the same time,
and the only way to you can do this without violating the terms of the
first part is to ignore the "-or-any-later" clause of the second part.

> Should the patch be reverted with the comment
> explaining multiple licensing situations?

Or just reverted. I think the comment that was there before was sufficient.

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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Stephen Gallagher]

On Tue, Jun 8, 2021 at 9:46 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote:
...
> > in the future existing yescrypt hashes can be
> > updated to new yescrypt hashes with stronger salts and/or cost
> > parameters in-place without changing the password, and without user
> > interaction.
>
> Interesting. How does this work?

My guess would be that the PAM module that performs the authentication
would just re-encrypt and store that password after a successful auth
against the previous salt/params.

I was thinking about suggesting a similar PAM module to convert
existing hashes, but I suspect that we'd be coming up against some
issues with security policy and separation of actions. Right now, I
expect that SELinux permits PAM processes to have read-only access to
/etc/shadow, but such a change would necessitate read/write access,
which is riskier. It's also why PAM has separate activities for
authentication, authorization and password-change.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1969474] New: perl-POE-Component-IRC-6.92 is available

[bugzilla]

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

Bug ID: 1969474
   Summary: perl-POE-Component-IRC-6.92 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-POE-Component-IRC
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: andrea.v...@gmail.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.92
Current version/release in rawhide: 6.91-1.fc35
URL: http://search.cpan.org/dist/POE-Component-IRC/

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


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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote:
> Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones
> :
> >
> > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote:
> > > == Dependencies ==
> > > * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> > > * authselect: https://github.com/authselect/authselect/pull/253
> > > * libuser: WIP ongoing
> > > * shadow-utils: 
> > > https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
> > >
> > > * pam: Is already capable to use yescrypt.
> > > * libxcrypt: Is already capable for computing yescrypt hashes.
> >
> > libguestfs (virt-customize etc.) might also need changing.  What
> > happens if a new user account is created with (eg) $6$ sha512.  Does
> > it use that scheme forever?  Attempt to upgrade it?  Break?
> 
> Well, yes, that needs to be updated, too, but it's written in OCAML…
> I suppose, you want to volunteer, and get a well deserved F35 change
> badge for doing so?!  :P
> 
> If a user account is created with a sha512crypt hash, it will keep it
> as long as the password remains unchanged.  I'm currently thinking of
> a way to migrate all local users to use yescrypt hashes, but it's not
> that easy: Human users could be prompted on first login to change
> their password, if the hash in shadow is not yescrypt - there is a way
> to force that.  But what about local users with older password hashes
> that get logged in by any non-human interaction, like www-cron; those
> would need to be updated manually by the system admin.  Maybe I can
> write a CLI-tool for doing so.
> 
> Unfortunately there is no automatic way to update the hash from
> anything, but yescrypt, to yescrypt without knowing / entering the
> actual user password;

I think it's better to leave existing passwords in place. You can't
really force people to log in as all users, so the only realistic
scenario is to keep existing passwords if there's more than one user.

And I don't think there's a reason to try to force immediate password
switch. As far as we know, previous defaults like sha256 are OK.

> in the future existing yescrypt hashes can be
> updated to new yescrypt hashes with stronger salts and/or cost
> parameters in-place without changing the password, and without user
> interaction.

Interesting. How does this work?

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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Björn 'besser82' Esser]

Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones
:
>
> On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote:
> > == Dependencies ==
> > * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> > * authselect: https://github.com/authselect/authselect/pull/253
> > * libuser: WIP ongoing
> > * shadow-utils: 
> > https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
> >
> > * pam: Is already capable to use yescrypt.
> > * libxcrypt: Is already capable for computing yescrypt hashes.
>
> libguestfs (virt-customize etc.) might also need changing.  What
> happens if a new user account is created with (eg) $6$ sha512.  Does
> it use that scheme forever?  Attempt to upgrade it?  Break?

Well, yes, that needs to be updated, too, but it's written in OCAML…
I suppose, you want to volunteer, and get a well deserved F35 change
badge for doing so?!  :P

If a user account is created with a sha512crypt hash, it will keep it
as long as the password remains unchanged.  I'm currently thinking of
a way to migrate all local users to use yescrypt hashes, but it's not
that easy: Human users could be prompted on first login to change
their password, if the hash in shadow is not yescrypt - there is a way
to force that.  But what about local users with older password hashes
that get logged in by any non-human interaction, like www-cron; those
would need to be updated manually by the system admin.  Maybe I can
write a CLI-tool for doing so.

Unfortunately there is no automatic way to update the hash from
anything, but yescrypt, to yescrypt without knowing / entering the
actual user password; in the future existing yescrypt hashes can be
updated to new yescrypt hashes with stronger salts and/or cost
parameters in-place without changing the password, and without user
interaction.

Has anyone some better idea?

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

[EPEL-devel] Re: What about future EPEL for Centos ?

[Miroslav Suchý]

Dne 07. 06. 21 v 17:52 Matthew Miller napsal(a):

Troy answered the overall questions separately, but... in practice, I expect
this to be a very small issue.


Small issue in Koji and for Fedora Project itself. But can be bummer when you try to build your set of packages on top 
of EPEL. Or rebuild the EPEL package locally in Mock. Because then you have to do non-trivial amount of work [1]. And 
what is worse - the path has been tested by only few people so far.


[1] https://github.com/rpm-software-management/mock/wiki/Feature-rhelchroots

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

Schedule for today's FESCo Meeting (2021-06-08)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2021-06-08 17:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= New Members =

@defolos and @mohanboddu are new.

Let's discussing the meeting time too.

= Discussed and Voted in the Ticket =

#2614 F35 Change: Replace SDL 1.2 with sdl12-compat using SDL 2.0 
https://pagure.io/fesco/issue/2614
APPROVED (+5,0,-0)


= Followups =

= New business =

#2617 F35 Change: Make btrfs the default file system for Fedora Cloud 
https://pagure.io/fesco/issue/2617


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Does anyone know how to contact Greg Swift (xaeth)?

[Major Hayden]

On 6/8/21 2:05 AM, François Cami wrote:

This is the official unresponsive maintainer check for xaeth.
Associated bz:https://bugzilla.redhat.com/show_bug.cgi?id=1949831

Greg's last build was 7 years ago:
https://koji.fedoraproject.org/koji/userinfo?userID=1887

Neglected bz:
https://bugzilla.redhat.com/show_bug.cgi?id=1495323

Greg is the primary maintainer for python-augeas:
Latest version in Fedora: 0.5.0
https://src.fedoraproject.org/rpms/python-augeas
Latest upstream release: 1.1
https://pypi.org/project/python-augeas/

I'll gladly take over python-augeas if it is orphaned.


I just poked him on Twitter[0] for you. 

[0] https://twitter.com/majorhayden/status/1402247805918396423

--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


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

Re: [cdparanoia] License field fix awaiting to be merged

[Jiri Kucera]

CC'ing Zbyszek

On Mon, Jun 7, 2021 at 6:27 PM Jiri Kucera  wrote:

> Hi Zbyszek,
>
> reply inline
>
> On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Wed, Jun 02, 2021 at 01:31:15PM -, Benjamin Beasley wrote:
>> > > So, it doesn't really matter if two source files are distributed
>> under the GPLv2+ license.
>> > > The resulting binary (i.e. /usr/bin/cdparanoia) will always be GPLv2.
>> > > […]
>> > > But Licensing Guidelines make clear that the License: field refers to
>> the
>> > > binary packages not source ones.
>> > >
>> > > BR,
>> > >
>> > > Andrea
>> >
>> > The “effective license” approach you advocated is not mentioned in the
>> packaging guidelines but has historical support in the wiki (
>> https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F).
>> It has also come up on the fedora-legal list recently (
>> https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/W57JRNLWVOT55D7TDF7VYFMJT5QMBEGR/
>> ).
>>
>> FWIW, the licensing guidelines live on the wiki. There is nothing
>> "historical" about the Licensing:FAQ document, it is still the official
>> guide of how to interpret the Licensing:Main page.
>>
>> I know Ben wrote something that disagrees with the document, but
>> I think he is wrong. It also goes against the long-established practice.
>> And if we want to change the rules, the document that specifies them
>> should be changed, a post on the mailing list is not enough.
>>
>> > There is, I think, a valid question of how much mechanistic detail to
>> apply to documenting the source files *that contribute to the binary RPM
>> contents.* One approach, which I have favored in my packages, exhaustively
>> lists licenses of such files. The other, which you have advocated,
>> simplifies the license field into an “effective license” when clearly
>> appropriate. Both philosophies seem to be well-established as acceptable.
>> My view is therefore this patch seems to be correct but not absolutely
>> required.
>>
>> No, the patch is wrong. It's not super harmful, but it's still wrong.
>>
>
> So what should be the correct License then? According to [1], the one
> possibility is
>
>   License: (GPLv2 and GPLv2+) and LGPLv2
>
> but according to [2] point 2, this should be shortened to
>
>   License: GPLv2 and LGPLv2
>
> because GPLv2 is stricter. Should the patch be reverted with the comment
> explaining multiple licensing situations?
>
> Regards,
> Jiri
>
> [1]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario
> [2]
> https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Does anyone know how to contact Ryan Rix (rrix)?

[Ben Cotton]

On Tue, Jun 8, 2021 at 3:10 AM François Cami  wrote:
>
> This is the official unresponsive maintainer check for rrix.

I sent this thread via direct message to rrix's Twitter account.

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

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Richard W.M. Jones]

On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote:
> == Dependencies ==
> * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> * authselect: https://github.com/authselect/authselect/pull/253
> * libuser: WIP ongoing
> * shadow-utils: 
> https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
> 
> * pam: Is already capable to use yescrypt.
> * libxcrypt: Is already capable for computing yescrypt hashes.

libguestfs (virt-customize etc.) might also need changing.  What
happens if a new user account is created with (eg) $6$ sha512.  Does
it use that scheme forever?  Attempt to upgrade it?  Break?

https://github.com/rwmjones/guestfs-tools/blob/e929ce331740d383d020e126fab8ff93663e8b2b/customize/password.ml#L124

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

[Miro Hrončok]

On 02. 06. 21 10:02, Tomas Hrnciar wrote:
Hello, in order to deliver Python 3.10, we are running a coordinated rebuild in 
a side tag.


https://fedoraproject.org/wiki/Changes/Python3.10 



If you see a "Rebuilt for Python 3.10" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.

If you need to, please let usknow, so we can coordinate.

If you'd like to build the package, you should be able to build it in the side 
tag via:


on branch rawhide:
$ fedpkg build --target=f35-python
$ koji wait-repo f35-python --build 

Note that it will take a while before all the essential packages are rebuilt, 
so don't expect all your dependencies to be available right away. When in 
trouble, ask here or on IRC (#fedora-python on Libera.Chat).


Builds: 
https://koji.fedoraproject.org/koji/builds?latest=0=f35-python=-build_id=0 



Please avoid any potentially disturbing changes in Python packages until the 
rebuild is over.


Thanks. Let us know if you have any questions.


The side tag has been merged into Rawhide.

From now on, build as you do normally, but note that some dependencies might 
be broken.


We will follow up with list of failures and next steps tomorrow, it has been a 
long day.


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

rpmautospec: Invitiation to Test

[Nils Philippsen]

Hey everybody,

we've recently deployed the changes needed to enable automatic RPM
release numbers and changelogs to Koji in staging, and now we want you
to throw things at it!

Detailed information is below, but the gist is: it looks like this will
be real sometime soon. This is the time to ensure we folks working on
it over the past weeks haven't left in any glaring errors.

We look forward to hearing from you!

Cheers,
Nils

---

Background--

In 2020, a prototype of rpmautospec was developed as feature for the
Koji build system to relieve Fedora contributors from manually
maintaining the release field and changelog of RPM packages. The
results were presented at Nest in August and were met with a positive
response.

FESCo accepted this feature to be implemented with changes to the
underlying release enumeration logic for the Fedora 35 release, and
subsequently a CPE team resumed work on the project in April 2021 to
bring the revised proposal to fruition. After about 6 weeks of
development, the team are pleased to announce that a first version of
rpmautospec based on the new logic is ready to be tested in staging.

Changed requirements in comparison to the prototype
---

FESCO asked the team to implement a simplified release enumeration
algorithm. It basically just considers the number of commits since the
last time the version was changed and avoids storing information about
historical builds in git tags.

What it does at this stage of development
-

* When building packages in Koji/staging, the release field and
changelog are maintained automatically from the commits and their
log entries (more specifically, their subject lines) in the git
repository. The contents of a changelog file, if present in the
repository, will override any older commit log information, to allow
correcting/amending changelog entries after the fact.
* For the release field, flags for pre-release versions,
snapshot/extra version information and release number offset exist
and are honoured. This isn’t yet implemented for changelog entries,
though, i.e. generated changelog entries will have the plain release
number in their header even for pre-release or snapshot versions.
* The new git history traversal code follows forks in order to support
merging branches. For changelog generation, this means it follows a
parent with the same tree to support git merge -s ours. Unresolvable
merges (with content from disparate branches) won’t fail a build,
but this problem will be flagged in the changelog (as the oldest
entry).
* An API function is provided allowing 3rd party users like fedpkg,
rpmdev-bumpspec to check if rpmautospec features are used and adapt
to it where necessary. Pull requests to use this have been submitted
to rpmdev-bumpspec and fedpkg/rpkg.

What’s yet to come
--

* Reflect flags to %autorelease in generated changelog entries.
* Have `fedpkg local`, `fedpkg mockbuild` (possibly `fedpkg srpm`)
support rpmautospec features, i.e. prepare the SRPM on the fly as
Koji would do it before building.
* Allow for uncommitted changes in local builds with fedpkg, i.e. bump
the release number by one and generate a boilerplate “- uncommitted
changes” RPM changelog entry.
* Up-to-date and more complete documentation (real soon now).

Testing Information
---

 * Source code can be found here: https://pagure.io/fedora-
   infra/rpmautospec
 * Installable packages are available for all supported Fedora
   versions,
   from 33 onwards.
 * Quick Start:
- The staging environment is separate from what you use day to day,
  recent
  changes to your account might not have made it there. Ensure you can
  log
  into your Fedora account on staging, and that it is part of the
  necessary
  groups (e.g. packager): https://accounts.stg.fedoraproject.org
  If you have issues with your staging account, please log a ticket
  with
  Fedora Infrastructure here: https://pagure.io/fedora-
  infrastructure/new_issue
- Clone the staging repository of a package: `fedpkg-stage clone ...`
- Move the existing changelog entries beneath %changelog in the spec
  file
  into a file named changelog in that same directory and add that file
  to
  be tracked by git.
- Enable automatic release number enumeration and changelog generation
  in
  the spec file:

   ... Release: %autorelease ... %changelog %autochangelog

- Commit these changes to git, push and build:

   git commit -m "Use automatic release and changelog" git push
   fedpkg-stage build
   
- If you want to use the Koji CLI tool, point it at staging this way:
  
  koji --profile=stg ...
  
 * We are interested in issues concerning using rpmautospec, if you
   need help
   but also where its behavior is unexpected or even disruptive, such
   as:
- (How) Can I do …?
- My 

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Arthur G]

+1
...and many thanks for providing a very comprehensive rationale.

On Tue, 8 Jun 2021 at 21:47, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote:
> > == Feedback ==
> +1
>
> > == Benefit to Fedora ==
> > == Dependencies ==
> > * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> > * authselect: https://github.com/authselect/authselect/pull/253
> > * libuser: WIP ongoing
> > * shadow-utils:
> https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
> >
> > * pam: Is already capable to use yescrypt.
> > * libxcrypt: Is already capable for computing yescrypt hashes.
> I added systemd to the list here: systemd-sysusers supports yescrypt
> as the default (through crypt_preferred_method() which also returns
> yescrypt, or directly if crypt_preferred_method() is not available).
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote:
> == Feedback ==
+1

> == Benefit to Fedora ==
> == Dependencies ==
> * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> * authselect: https://github.com/authselect/authselect/pull/253
> * libuser: WIP ongoing
> * shadow-utils: 
> https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
> 
> * pam: Is already capable to use yescrypt.
> * libxcrypt: Is already capable for computing yescrypt hashes.
I added systemd to the list here: systemd-sysusers supports yescrypt
as the default (through crypt_preferred_method() which also returns
yescrypt, or directly if crypt_preferred_method() is not available).

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

Re: older than 30 days and empty side tag clean up

[Mattia Verga via devel]

Il 06/06/21 19:53, Kevin Fenzi ha scritto:
> On Sun, Jun 06, 2021 at 07:40:41AM +, Mattia Verga via devel wrote:
>> I thought that deleting a side-tag would delete all its child
>> (*-testing-pending and similar), but it doesn't seem so:
>>
>> https://koji.fedoraproject.org/koji/search?match=glob=tag=f35-build-side-40730*
>>
>> It seems that this side-tag has been deleted, but its child were not. Is
>> it this the right behavior? I'd like to know because if we want Bodhi to
>> delete the side-tag, it would be simpler if deleting the parent tag also
>> delete its childs.
> Odd, yes, I thought it deleted the associated tags too.
>
> kevin

So, I've reported this to Koji upstream [1], and it turned out this is
the expected behavior.

We can set Bodhi to remove children tags when the side-tag is deleted,
but I think releng's cronjob that removes old side-tag should be updated
to take children tags into consideration. However I can't find anywhere
in ansible or releng repository where `koji-sidetag-cleanup` script is.

mattia

[1] https://pagure.io/koji/issue/2901

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

Does anyone know how to contact Ryan Rix (rrix)?

[François Cami]

Hi,

This is the official unresponsive maintainer check for rrix.
Associated bz: https://bugzilla.redhat.com/show_bug.cgi?id=1968568

Ryan's last build was nearly 7 years ago:
https://koji.fedoraproject.org/koji/userinfo?userID=1124

Neglected bz:
https://bugzilla.redhat.com/show_bug.cgi?id=1878064

I'll gladly take over python-netifaces if it is orphaned.

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

Does anyone know how to contact Greg Swift (xaeth)?

[François Cami]

Hi,

This is the official unresponsive maintainer check for xaeth.
Associated bz: https://bugzilla.redhat.com/show_bug.cgi?id=1949831

Greg's last build was 7 years ago:
https://koji.fedoraproject.org/koji/userinfo?userID=1887

Neglected bz:
https://bugzilla.redhat.com/show_bug.cgi?id=1495323

Greg is the primary maintainer for python-augeas:
Latest version in Fedora: 0.5.0
https://src.fedoraproject.org/rpms/python-augeas
Latest upstream release: 1.1
https://pypi.org/project/python-augeas/

I'll gladly take over python-augeas if it is orphaned.

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

[Bug 1964657] F35FailsToInstall: perl-XML-Atom-SimpleFeed

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Flags|needinfo?(emmanuel@seyman.f |needinfo+
   |r)  |




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

[Bug 1964649] F35FailsToInstall: perl-MouseX-App-Cmd

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Flags|needinfo?(emmanuel@seyman.f |needinfo+
   |r)  |




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

[Bug 1964648] F35FailsToInstall: perl-HTML-TreeBuilder-LibXML

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Flags|needinfo?(emmanuel@seyman.f |needinfo+
   |r)  |




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