On Saturday, April 14 2018, I wrote: > On Friday, April 13 2018, I wrote: > >> On Thursday, April 12 2018, Boyuan Yang wrote: >> >>> Dear mentors, >>> >>> I am looking for a sponsor for my package "peek" >>> >>> * Package name : peek >>> Version : 1.3.1-1 >>> Upstream Author : Philipp Wolfer <p...@parolu.io> >>> * URL : https://github.com/phw/peek >>> * License : GPL-3+ >>> Section : graphics >> >> Hi, Boyuan, >> >> I'm looking at the package right now. So far, everything seems to be >> OK. I appreciated the way you took care of the licensing stuff, and how >> d/copyright seems to cover all the bases. >> >> I'll let you know if I have questions, or when I upload it. > > Hi again, > > I've been having a few problems when building the package locally. It's > a build failure due to a missing header, and the strange thing is that > it happens intermitently (i.e., sometimes I can build everything just > fine, sometimes the build fails). Here's the error: > > /build/peek-debian/peek-tmp/obj-x86_64-linux-gnu/src/utils.c:16:10: fatal > error: application.h: No such file or directory > #include "application.h" > ^~~~~~~~~~~~~~~ > compilation terminated. > make[4]: *** [tests/CMakeFiles/peek-test-utils.dir/build.make:126: > tests/CMakeFiles/peek-test-utils.dir/__/src/utils.c.o] Error 1 > make[4]: *** Waiting for unfinished jobs.... > > After spending some time tracking down the issue, what I found is that > "application.h" is generated automatically by Vala (see the > "vala_precompile" rule on CMakeLists.txt). I've compared the build logs > generated by a successful build against those generated by an > unsuccessful one, and there's nothing really wrong that I see. Plus, if > I rerun the "make" command after the failure the build succeeds. So > far, this is telling me that the problem seems to be a race condition > (due to the way cmake parallelizes the jobs, maybe). > > I'll see if I manage to investigate a bit more, but I'd appreciate if > you could take a look at this.
So, I tried disabling parallel builds: %: dh $@ --no-parallel And was able to build the package at least 10 consecutive times without any problems. I think there's a bug in the parallel build, indeed. Not sure if it's something related to CMakeLists.txt (likely), or to cmake. Anyway, I think we can proceed safely if you disable parallel builds for now. This is not the perfect solution, but it works fine, and the program is small enough that even a non-parallel build finishes quick. I'll wait until you address all the comments I've made, and then I'll upload the package to the archives. Thanks! -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/
signature.asc
Description: PGP signature