https://bugzilla.redhat.com/show_bug.cgi?id=2085377
--- Comment #23 from Dan Horák <dan(a)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
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2085377