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 <phil@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/
Attachment:
signature.asc
Description: PGP signature