Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1898168 - salt fails to build with Python 3.10: Uses the ?.? Python version glob in the spec file
Summary: salt fails to build with Python 3.10: Uses the ?.? Python version glob in the...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: salt
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bryce Larson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PYTHON3.10
TreeView+ depends on / blocked
 
Reported: 2020-11-16 15:14 UTC by Miro Hrončok
Modified: 2020-11-21 01:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-20 06:45:38 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Miro Hrončok 2020-11-16 15:14:03 UTC 
salt fails to build with Python 3.10:

RPM build errors:
    File not found: /builddir/build/BUILDROOT/salt-3002.1-1.fc34.x86_64/usr/lib/python3.10/site-packages/salt-*-py?.?.egg-info

This was fixed:

https://src.fedoraproject.org/rpms/salt/c/098424117de0c7fd414cc1bd51aec57ae4d4f702?branch=master

And later reverted:

https://src.fedoraproject.org/rpms/salt/c/1d10613476464a8082820c57eaffb9f81724d83c?branch=master


BTW When the revert happened, there was small email exchange between us, but so far the problem still exists. Opening this for tracking purposes.


For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01767758-salt/

For all our attempts to build salt with Python 3.10, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/salt/

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/

Let us know here if you have any questions.

Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon.
We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
Comment 1 David Murphy 2020-11-16 23:27:46 UTC 
I was looking at the dates in the changelog and I am puzzled as to how the reversion could be due to my changes. 

https://src.fedoraproject.org/rpms/salt/c/1d10613476464a8082820c57eaffb9f81724d83c?branch=master

             %changelog            
                    -            * Wed Jul 29 2020 Fedora Release Engineering <releng> - 3001-2            
                    -            - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild            
                    +            * Mon Jul 27 2020 SaltStack Packaging Team <packaging> - 3001.1-1            
                    +            - Update to feature release 3001.1-1  for Python 3            
                     
The Fedora builds are done by SaltStack after general Linux releases for a point release, but the changes are always corrected for the day the actual works is done, since the Fedora builds are done by hand.  Hence the changes were done on Monday 27th July, which kind of makes it hard to revert a change made on Wednesday 29th July, two days later.

Understand we had some email about this at the time, but the issue with the dates I just became aware of.

However, I am wondering what is going on in the process that a change from two days earlier reverts a change from two days later.
I am very sure of the date Mon Jul 27, as I am rigorous about ensuring the date is correct in the changelog.
But I do see the dates on the changes Aug 11th, almost two weeks after the Monday, which is odd. I could expect a couple of days difference but two weeks is too large.

However will work to get the issue corrected so that this is not a problem going forward.

Note: the maintainer has been changed to brycel (our email addresses changed with the VMware buy of SaltStack)
Comment 2 Miro Hrončok 2020-11-17 07:49:52 UTC 
I don't understand how do you manage the spec file or what is the problem with the dates.

On Aug 11 a commit was pushed that had the date" "Jul 27" in the changelog. The commit overrode any changes made in the Fedora dist-git since the last push by the maintainer(s).
Comment 3 Bryce Larson 2020-11-20 00:29:34 UTC 
I returned the original fix https://src.fedoraproject.org/rpms/salt/c/f04c3c3febfddbcea6b1e82ac867c21ef14adf08?branch=master

Do we need to fix the changelog too?  if so, do we make david's changelog entry match the date it was committed or leave the dates as is and be out of order?
Comment 4 Fedora Update System 2020-11-20 00:42:10 UTC 
FEDORA-2020-5c5ff2deec has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5c5ff2deec
Comment 5 Miro Hrončok 2020-11-20 06:45:38 UTC 
> I returned the original fix https://src.fedoraproject.org/rpms/salt/c/f04c3c3febfddbcea6b1e82ac867c21ef14adf08?branch=master

Thanks.

> Do we need to fix the changelog too?

I don't.
Comment 6 Fedora Update System 2020-11-21 01:30:42 UTC 
FEDORA-2020-5c5ff2deec has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.