Conversation
| data['source_url'] = args.name + '-' + args.version + '.zip' | ||
| data['year'] = datetime.datetime.now().year # set current year | ||
|
|
||
| now = datetime.datetime.now() |
There was a problem hiding this comment.
Why did you change this? AFAICS you never use it in the fedora template..
There was a problem hiding this comment.
I didn't feel like calling now() twice for no particular reason.
The 'year' was already initialized by the existing init ... that is not changed. (there is data['year'] = now.year)
I am adding template of 'changelog_date' in a format suitable for Fedora changes.
The 'changelog_date' is used in the spec file template.
|
@xambroz thanks for the PR! Is there a easy way (without a Fedora system) to test this somehow? |
|
@xambroz friendly ping... |
There was a problem hiding this comment.
Is there a easy way (without a Fedora system) to test this somehow?
@toabctl Best way testing the spec file is of course on Fedora. Generating the spec file and trying to build that one with rpmbuild.
Would you be having some easy way testing spec file for SuSE without SuSE ?
| data['source_url'] = args.name + '-' + args.version + '.zip' | ||
| data['year'] = datetime.datetime.now().year # set current year | ||
|
|
||
| now = datetime.datetime.now() |
There was a problem hiding this comment.
I didn't feel like calling now() twice for no particular reason.
The 'year' was already initialized by the existing init ... that is not changed. (there is data['year'] = now.year)
I am adding template of 'changelog_date' in a format suitable for Fedora changes.
The 'changelog_date' is used in the spec file template.
|
There's a tool called "mock" that I use on Fedora and RHEL to test builds across multiple platforms. I see that it has built-in support for the OpenSuSE "tumbleweed" release, which may be helpful for multiple platform testing. as asked by xambroz. |
|
@xambroz Does this still make sense? If yes, could you rebase it, please? |
4 participants
Hello,
I have done some updates to the spec teplate for Fedora.
On one hand Fedora wants to prefer python3 packages over python2, on the other hand it is not always possible.
I have tried to make the package compliant with the current Fedora python packaging guidelines while keeping easy define to switch off the python3 generation.
Best regards
Michal Ambroz