Re: [MoM] Packaging mindthemap (Was: Request to contribute to DebianMed and be part of MoM)
Hello Andreas,
Thanks for your reply. I feel like I am getting closer to a successful build.
What seems to be difficult to understand is when I am building the package and get the following output which terminates pbuilder:
...
Feature record: CXX_FEATURE:0cxx_user_literals
Feature record: CXX_FEATURE:0cxx_variable_templates
Feature record: CXX_FEATURE:0cxx_variadic_macros
Feature record: CXX_FEATURE:0cxx_variadic_templates
dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 1
make: *** [debian/rules:21: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package
Patching seemed to be successful because running pbuilder states that it has applied the patch that I made. VERBOSE is uncommented and equals 1 in the rules, and that's the log that I can get above. Is there anyway to get a more meaningful output? Maybe I am using pbuilder wrong, but I have my doubts as libgatbcore-dev is installed successfully within the pbuilder session. The CMakeFile mainly reflects what you did for minia, so I don't see why this would be a problem unless I am acting stupid and have missed out something obvious. I'm not sure as to what other information I can provide on top of this.
Thanks,
Shayan Doust
July 3, 2019 1:49 PM, "Andreas Tille" <andreas@an3as.eu> wrote:
> Hi Shayan and Andrius,
>
> On Wed, Jul 03, 2019 at 03:11:04PM +0300, merkys@debian.org wrote:
>
>> On 2019-07-03 15:02, hello@shayandoust.me wrote:
>> Is this where I now have to rely on the pre-built gatb-core package that already exists within sid
>> and testing as a build dependency by editing the rules and control file instead of going down this
>> route?
>>
>> Yes. Ideally, mindthegap should use system-provided (Debian packaged)
>> gatb-core to build.
>>
>> I was thinking of quilt patching but I don't think that's the way to do it.
>>
>> This is usually the only way. Some CMakefiles are able to detect
>> system-provided libraries, however, sometimes one has to patch them.
>
> Fully ACK here. Since learning by example is probably the easiest way
> I'll provide you with one that will make things clear hopefully. How to
> find the example?
>
> $ apt-cache rdepends libgatbcore2
> libgatbcore2
> Reverse Depends:
> minia
> libgatbcore-dev
> discosnp
>
> Libgatbcore-dev is obviosly from the gatb-core source package and thus
> does not help much here. So what about discosnp and minia? If you
> check the quilt patches of discosnp you will find this one:
>
> https://salsa.debian.org/med-team/discosnp/blob/master/debian/patches/use_debian_packaged_gatb-core.
> atch
>
> So what you need to do is
>
> quilt new use_debian_packaged_gatb-core.patch
> quilt edit CMakeLists.txt
> do the changes that are needed to use the Debian packaged gatb-core
> quilt refresh
> quilt pop
>
> For sure you also need a
>
> Build-Depends: libgatbcore-dev
>
> in debian/control to make sure this library will be available in your
> pbuilder chroot at build time.
>
> For sure it make sense to check minia as well in case the CMakeLists.txt
> comes closer to your own target. I hope with these two examples you
> will manage to build against the Debian packaged gatb-core and you are
> convinced that the Git submodule code is not needed.
>
> Attention: When I was packaging minia and discosnp I realised that one
> of these (I do not remember which one) needed a later development state
> of gatb-core than the other one. I solved this in a really wimpy way:
> Just by try and error which commit would fit both. I blame gatb-core
> upstream for not doing a proper release management and providing a
> stable ABI for the dependant software. So you might realise that the
> gatb-core code that is needed for mindthegap might be even newer than
> the existing one in the Debian packaged gatb-core lib. Here we have a
> real conflict between Debian policy to avoid code duplication inside
> Debian and the more and more frequent usage of simply throwing any
> commit as submodule in some code and may be trust Conda or other
> packaging systems to fetch whatever fits (any security implications left
> aside by this method).
>
> Disclaimer: I have not checked the current situation with gatb-core but
> simply described the situation at least half a year ago. May be
> upstream has started now a stable ABI and is doing proper release
> management! You might like to verify this possibly.
>
> For your current packaging this means:
>
> A. Current Debian packaged gatb-core is working with mindthegap
> -> Fine
>
> B. In case you get build errors with strings that might be part
> of gatb-core check we need to upgrade gatb-core to a commit
> that works - may be the latest or the one that was used as
> submodule. However, before we continue we need to make sure
> that minia and discosnp will continue to build and run with
> this new gatb-core version. And we need to bump the SOVERSION
> we invented inside Debian to create a proper versioned dependency
> relation.
>
> This is in detail what I said in short in one of my initial mails for
> your packaging attempt of mindthegap.
>
> Hope this helps
>
> Andreas.
>
> --
> http://fam-tille.de
Reply to: