Hi Andre, On Wed, Aug 28, 2024 at 04:42:39PM +0200, Andre Noll wrote: > Sure. I've amended the commit accordingly and pushed out the result to the > "debian" branch of the public git repo. The tip of this branch is > > d48d5327798befb66cee5ab08ab253449e431d5c > > So please upload this version.
Thanks for signing the mail. In my previous mail, I forgot to suggest a signed git tag or signed commit as another alternative for conveying the signature. I'm sorry for the delay. I had trouble with dgit and deferred the upload as a result. I fear I decline uploading this, because I believe that you forgot to check in debian/liblopsub-bin.install. The resulting package will not be usable as liblopsub-bin does not contain /usr/bin/lopsubgen. Additionally, what also is missing is debian/liblopsub-bin.links. In order to reduce the size of the binary package, I implemented documentation linking there. A more straight forward route could have been using dh_installdocs --link-doc. In any case, liblopsub-bin now also lacks /usr/share/doc and that is a policy violation. If you prefer avoiding this complexity, you may also just call dh_installdocs -p$(binpackage). Given that the resulting package doesn't work at all and violates policy, I prefer not uploading it as is. Would you mind retrying? > Yup. My approach is pretty similar, although it does not add a second > set of variables but creates output files for the build architecture > in a dedicated directory. It seems to work, but it compiles lopsubgen > twice even if CC_FOR_BUILD is unset. This should be avoidable by > comparing $(CC) and $(CC_FOR_BUILD) as you describe above. > > I'll give it some more testing on trixie, and see what I can do. You > may always look at the patch in the "pu" (proposed updates) branch > of the public repo. I looked at you pu branch and suggest changes. The use of a directory called "build" suggests an out-of-tree build to the uninitiated, but this is not what happens here. As a result, I consider it confusing. An improvement could be naming it "build-native" maybe. The avoidable extra compilation step does not seem worrying to me, because the total time of compilation for liblopsub still is fairly small and dominated by chroot setup time. I don't think dh_auto_build passes CC_FOR_BUILD, so in a Debian package cross build, I expect CC_FOR_BUILD to be a host architecture compiler. You may include /usr/share/dpkg/buildtools.mk in debian/rules and then pass CC_FOR_BUILD='$(CC_FOR_BUILD)' to dh_auto_build. I think the dependencies for the rules %.lsg.c:%.suite and others are wrong. You declare a dependency on lopsubgen, but you invoke $(B)/./lopsubgen. As a result, parallel builds may fail if $(B)/./lopsubgen isn't ready in time. After fixing the dependencies, you may drop $(B)/lopsubgen from the all target as it only is an intermediate product not meant for installation. I have not actually run a cross build. You may include or skip cross build support in your revised experimental upload at your choice. Helmut
