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.


GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible

Attachment: signature.asc
Description: PGP signature

Reply via email to