Re: [MoM] Packaging mindthemap (Was: Request to contribute to DebianMed and be part of MoM)
ahh, just continuing on from the previous email:
I've just made a copy of the directory I was working on and decided to manually invoke commands within an environment with the dependencies installed via apt. It seems like CMake complains because "include could not find load file GatbCore". I had a feeling this would be the issue. It's strange because I've closely followed the patchwork on the couple of projects that you've stated below and it still is not able to work. At least I know the only issue stopping this is CMake.
July 3, 2019 8:53 PM, hello@shayandoust.me wrote:
> 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: