updated nwchem.spec available

[marcindulak]

The latest spec is at https://src.fedoraproject.org/rpms/nwchem/c/406bd9b8b37781a9c617e0f29e4845014fd903bd

I simply updated to nwchemgit/nwchem@6b5bd31 due to https://bugzilla.redhat.com/show_bug.cgi?id=1793464 and the build succeeded.

[edoapra]

Thanks for the update.
I should be able to, eventually, get 7.0.0 out in February.
A minor update (5.7.1) for Global Arrays should be available, too

[edoapra]

Commit pushed 210d2d7

[edoapra]

Pushed new commit
935dd57
It seem to fail only on f33/i686, but the ga-5.7.2 rpm might have a fix for the failure

[edoapra]

patch needed to build against ga rpm without peigs
1ecb311#diff-c33df58ef66df25270afbf7b54d8f103

[marcindulak]

I would like we stop using the release_date in the spec and don't refer anymore to the "versioned" tarballs

fedpkg/nwchem/nwchem.spec

Lines 8 to 10 in 1ecb311

	%{?!major_version: %global major_version 7.0.0}
	%{?!git_hash: %global git_hash 2c9a1c7c}
	%{?!release_date: %global release_date 2020-02-26}

but use instead major_version and git_hash

%{?!major_version: %global major_version 7.0.0}
%{?!git_hash: %global git_hash 6b5bd318870c3d6ad9168284bb3455e800383ccf}

https://src.fedoraproject.org/rpms/nwchem/blob/49cce8446fc0434a6bca421b3f6e3448efb0185a/f/nwchem.spec#_8-9

and point to the github archive

Source0:		https://github.com/nwchemgit/nwchem/archive/%{git_hash}.tar.gz

https://src.fedoraproject.org/rpms/nwchem/blob/49cce8446fc0434a6bca421b3f6e3448efb0185a/f/nwchem.spec#_48

Such versioning is much simpler and allows one to easily test various git hashes and not being limited to only "released" tarballs.

We have now also a conflict in the changelog https://src.fedoraproject.org/rpms/nwchem/blob/49cce8446fc0434a6bca421b3f6e3448efb0185a/f/nwchem.spec#_478

Let's start using a develop branch for the changes in the repository.

[marcindulak]

I'll prepare nwchem.spec according to the comments above and test it.

#9

[edoapra]

Such versioning is much simpler and allows one to easily test various git hashes and not being limited to only "released" tarballs.

It's fine for me. My preference for using released tarballs is for two reasons:
first that the tarballs have already been processed by the make 64_to_32 step and
second that we do rigorous and extensive QA testing for releases, while the same cannot be said for any arbitrary git snapshot.
Therefore, I see no problem switching from the manually created tar file mentioned above to the tar files that github automatically creates when creating a release, for example
https://github.com/nwchemgit/nwchem/archive/v7.0.0-release.tar.gz
This will get rid of the release date stamp.
If new bugs are fixed once the release is out, bug fixes go into the hotfix branch (e.g. hotfix/release-7-0-0), that is eventually released

[edoapra]

update dd52d5a
Added mcscf_scalapack.patch
Switched to https://github.com/nwchemgit/nwchem/archive/v%{major_version}-release.tar.gz tar file

[edoapra]

master branch of https://github.com/edoapra/fedpkg.nwchem is now in sync with https://src.fedoraproject.org/rpms/nwchem
I have moved my changes to the develop branch (not fully re-tested yet)
3c53b06

[marcindulak]

My preference for building straight from a git hash is due to the necessity of this during last year

fedpkg/nwchem/nwchem.spec

Lines 486 to 494 in dd52d5a

	* Tue Jan 21 2020 Marcin Dulak <Marcin.Dulak@gmail.com> - 7.0.0-2
	- new upstream snapshot release
	* Fri Oct 04 2019 Marcin Dulak <Marcin.Dulak@gmail.com> - 7.0.0-1
	- new upstream snapshot release
	* Fri Aug 30 2019 Marcin Dulak <Marcin.Dulak@gmail.com> - 6.8.2-1
	- new upstream snapshot release
	- switch to python3 br on fedora >= 30 bug #1738065

Very often new fedora changes and mass rebuilds cause the nwchem build to fail and I've been building from hashes multiple times before we settled on a specific, unreleased hash to be used in the spec.

Is there any difference between https://github.com/nwchemgit/nwchem/archive/v%{major_version}-release.tar.gz and https://github.com/nwchemgit/nwchem/archive/%{git_hash}.tar.gz if %{git_hash} corresponds to the %{major_version} tag?

[edoapra]

My preference for building straight from a git hash is due to the necessity of this during last year
Very often new fedora changes and mass rebuilds cause the nwchem build to fail and I've been building from hashes multiple times before we settled on a specific, unreleased hash to be used in the spec.

This might have unexpected consequences, since we do run travis ci on every github commit, but that does not cover all the code functionality. For this reason, my recommendation is to use release tar files in conjunction with patches. Patches "should'' be easy to generate (yes, I do remember some issues last here with the python3 transition ...). In other words, I do not considered a supported version code generated by a certain code snapshot at a certain time.

Is there any difference between https://github.com/nwchemgit/nwchem/archive/v%{major_version}-release.tar.gz and https://github.com/nwchemgit/nwchem/archive/%{git_hash}.tar.gz if %{git_hash} corresponds to the %{major_version} tag?

It should be the same. It seems easier to me to track down the release version to use the github tag instead of the git hash

[marcindulak]

I'm using

fedpkg/nwchem/nwchem.spec

Line 45 in dac6f2e

Source0: https://github.com/nwchemgit/nwchem/archive/%{git_hash}.tar.gz

as a convenience, so I don't need to rewrite the spec every time I want to test a git hash of nwchem.

I'm not planning to regularly release git hashes that do not correspond to git tags, and if this happens such nwchem versions will be built only on rawhide, and hopefully replaced by a git hash of a tagged release as soon as the tag is made.

There are several changes (source, PKG_TOP, prep) to the spec in order to switch from tag based archive to hash based archive and back (like here 63d1b9a). This is an extra work that does not provide a value.

[marcindulak]

I think we can close this old issue.