|
Notes |
|
|
(0018353)
|
|
Zalewa
|
|
2017-09-20 21:26
|
|
|
I think this file should be built in CMAKE_CURRENT_BINARY_DIR instead of src/core/. Doomseeker already looks for includes in that dir because that's where Qt tools build their files. |
|
|
|
(0018365)
|
|
Zalewa
|
2017-09-24 16:11
(edited on: 2017-09-24 16:12) |
|
I will have to retract the above statement as it would stand in contradiction with 3255 (reproducible builds).
Instead, svnrevision.h with properly filled information should be included in the source package and if 'updaterevision' tool fails to detect the repository it should not attempt to generate the file if that file already exists.
If the file doesn't exist and there's no repository to create it from, an invalid file should be created just as it is now.
|
|
|
|
|
|
At least the latter sounds like a sensible solution. Go for it. |
|
|
|
|
|
|
|
(0018389)
|
|
Zalewa
|
2017-09-25 19:26
(edited on: 2017-09-25 19:27) |
|
The svnrevision.h contains information that can be only generated from the repository. If you tarball the source code up and remove the .hg dir, then the information to generate svnrevision.h cannot be obtained anymore. The generator tool will create an invalid, yet compilable file instead (ie. revision info will be set to zero).
If we don't include the generated svnrevision.h in the archive, then how can we deterministically reproduce a build without the repository? The same page even suggests to use autorevision to export VCS metadata and include it in the tarball: 'https://wiki.debian.org/UpstreamGuide#Out-of-VCS_Builds. [^]' This is exactly what is happening here, even though we use "our" own tool for that.
A template file seems to be hardly needed for a file that contains 3 #defines, none of which should be manually modified in any way.
As I see it, there are 2 problems that need to be solved here:
Problem 1. svnrevision.h file should not be touched if it already exists and it's impossible to determine the correct info from the repo. In such case, it will be necessary to assume that svnrevision.h already contains the correct information and touching it in any way will destroy it. Of course, people can just change other parts of the code and then compile Doomseeker without invalidating svnrevision.h, but given that we will already have reproducible builds, executables comparisons will expose their modifications.
Problem 2. svnrevision.h is currently not included in the tar.bz2 archive with the rest of the source code. When code archive is released, an already generated and correct for the given commit svnrevision.h should be included in the archive as well.
|
|
|
|
(0018390)
|
|
Zalewa
|
|
2017-09-25 21:23
|
|
|
|
|
(0019127)
|
|
Blzut3
|
|
2018-03-04 09:12
|
|
|
|
|
|
I've been largely ignoring makesourcepackages.sh exists in the repository, and have been testing against upstream tarballs available at'http://doomseeker.drdteam.org/files/ [^]' so far.
Today I tried against makesourcepackages.sh. All good up until doomseeker-1.2/src/core/CMakeFileListing.cmake became the new violator, so I can't make a conclusive statement about the status of this specific bug. Since it's cmake related, perhaps a Debian packager only needs to adjust dh_clean target to clean up first. |
|
|
|
(0019719)
|
|
Zalewa
|
|
2018-09-24 21:48
|
|
|
What is the meaning of "unexpected" in this context? |
|
|
|
(0019724)
|
|
WubTheCaptain
|
2018-09-24 22:33
(edited on: 2018-09-24 22:35) |
|
Quote from Zalewa
What is the meaning of "unexpected" in this context?
See attached doomseeker_1.1-1_amd64.build. It is the following error:
Quote from doomseeker_1.1-1_amd64.build
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/doomseeker_1.1-1.diff.NLEjW2
This means (meant) when building from inside the ./doomseeker-1.1 directory, the results of that "source code" (svnrevision.h and CMakeFileListing.txt) changed in that directory in comparison to ../doomseeker-1.1_src.orig.tar.bz2
It seems like the original build also knew about doomseeker-1.1_src/src/core/CMakeFileListing.txt (now doomseeker-1.2/src/core/CMakeFileListing.cmake) being modified, but OP didn't make a mention of it.
I did read doomseeker_1.2-1_amd64.build file generated by debuild from this compilation. It does seem like this ticket's issue with svnrevision.h is fixed; The issue with CMakeFileListing.cmake isn't fixed, and needs to be resolved in another ticket (or by the Debian package maintainer). I'll attach that file now.
The question is: Would someone create a ticket about CMakeFileListing.cmake having this same exact issue (even if the issue becomes invalid) and close this ticket as resolved? Thanks.
|
|
|
|
|
Quote from WubTheCaptain
The question is: Would someone create a ticket about CMakeFileListing.cmake having this same exact issue (even if the issue becomes invalid) and close this ticket as resolved? Thanks.
My request for you to close this ticket as resolved is kindly for your acknowledgement of the other issue, so that you won't run the steps to reproduce and think "oh it's still broken, this issue with svnrevision.h is not resolved". It's resolved. :)
|
|
|
|
(0019726)
|
|
Zalewa
|
|
2018-09-24 22:40
|
|
|
What does the diff say about the "unexpected changes" in CMakeFileListing.cmake in Doomseeker 1.2? You had one attached for problems in Doomseeker 1.1, I'd like to see the diff for 1.2 too. |
|
|
|
|
Ah, I see. A related issue to this I guess.
--- doomseeker-1.2.orig/src/core/CMakeFileListing.cmake
+++ doomseeker-1.2/src/core/CMakeFileListing.cmake
@@ -74,6 +74,7 @@ set(HEADER_FILES
filefilter.h
fileutils.h
gamedemo.h
+ gitinfo.h
global.h
gui/aboutdialog.h
gui/commongui.h
Attaching the full file. |
|
|
|
|
|
Bear in mind this is not a real and official Doomseeker 1.2 release but 1.2~beta-1 from source tree at commit a9995252fabcdd532cddcb763dc6c0931510e056 concerning the diff and amd64 build error with CMakeFileListing.cmake, despite the source directory name doomseeker-1.2. (Debian just expects them to be called that way by default, and makesourcepackages.sh makes doomseeker-1.2.tar.xz.) |
|
|
|
(0019731)
|
|
Blzut3
|
|
2018-09-25 00:46
|
|
|
|
|
|
Blzut3: Fyi, it's not immediately obvious from your commit or the CMake comment lines why someone would do that or care about file listing differing.
I'll test this now, anyway. Results in a few. |
|
|
|
|
Reproducible source with debuild and no problems with places where gitinfo.h is used (mainly, the "About Doomseeker" dialog).
Note: I didn't test compiling libwadseeker-1.2.tar.xz, only doomseeker-1.2.tar.xz.
Thanks! |
|
doomseeker_1.1-1_amd64.build (1,058) 2017-09-01 11:45
dpkg.log (712) 2017-09-01 11:48