在 2018年4月15日星期日 CST 上午9:53:52，Sergio Durigan Junior 写道： > 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. That looks quite weird. I can now think of an immediate workaround (forcing non-parallel build to dh). Will perhaps try to dig into it later. Indeed we can proceed safely now and probably file a Debian bug (as well as an upstream one) to track this issue. > Meanwhile, I have small nits to point out that I'd like answered/solved > before we proceed with the upload: > > 1) On d/rules, is there any reason you're using: > > export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed > > ? This passes --as-needed flag to the linker and strips unnecessary library dependencies. It can be unnecessary sometimes but mostly harmless. In fact I have added it to all packages I maintain and no regressions have been found before. > 2) You can remove the following line from override_dh_auto_configure > (also on d/rules): > > -DCMAKE_LIBRARY_ARCHITECTURE="$(DEB_TARGET_MULTIARCH)" > > Since you're not building a library, this is not needed. Indeed. Will remove it from d/rules. > 3) I'd like to see the buildsystem explicitly specified on the "%" rule, > like: > > %: > dh $@ --buildsystem=cmake That's optional but benificial. Will fix it and explicitly specify the buildsystem (cmake). > Other than that, the package looks good to me. Once we solve the build > failure, I'll gladly upload it for you! I have committed onto Salsa packaging repo with changes above (non-parallel build and issue 2) and 3)). Source package on mentors.d.o is also updated. -- Regards, Boyuan Yang
Attachment:
signature.asc
Description: This is a digitally signed message part.