https://bugzilla.redhat.com/show_bug.cgi?id=2085377
--- Comment #23 from Dan Horák dan@danny.cz --- (In reply to jschmidb from comment #22)
Yes, but this change hasn't made it to the released libzpc archive (currently still version 1.0.0), if > I see right. Looks to me it would make sense to release version 1.0.1 with the latest changes.
Yep, makes sense. I changed the version to 1.0.1 in the spec file and CMakeLists.txt to be consistent. But then the rpmbuild fails, because it wants to get a libzpc-1.0.1.tar.gz. So I probably could first commit the changes on github to force rebuilding the tar.gz and then do the rpmbuild again, or I just rename the tar.gz? But then the contained CMakeLists.txt would not have the correct release ... hmm .. what should we do here?
good question, but I think the best option is to commit changes to github, make a new release (1.0.1) and use that for the next iteration in the review.
I also noticed that "%autosetup -q -n %{name}-%{version}" doesn't like the -q option, so I removed it.
plain %autosetup should be sufficient for standard source archives
One reminder because I saw some test data files/URLs in the CMakeLists.txt file, the Fedora or RHEL build systems don't have access to the internet (by design), so should the build download any files on > the fly, it will fail.
Yes, "cmake -DBUILD_TEST=ON" downloads test vectors from NIST and also downloads the Google gtest suite. But when building without test, no internet connection is needed.
OK, no problem then