[Debian-on-mobile-maintainers] Trouble building libqmi (dpkg-gensymbols unhappy)

Fri Feb 18 09:08:59 GMT 2022

Le 18/02/2022 à 09:43, Evangelos Ribeiro Tzaras a écrit :
> Hi Arnaud,
> 
> On Fri, 2022-02-18 at 08:41 +0100, Arnaud Ferraris wrote:
>> Hi Evangelos,
>>
>> Le 18/02/2022 à 07:56, Evangelos Ribeiro Tzaras a écrit :
>>> Hi,
>>>
>>> I'm currently trying to backport MM and friends into pureOS (to see
>>> if
>>> qmi voice management fixes an issue with [Calls]) but I'm having
>>> trouble building libqmi:
>>>
>>>      dh_makeshlibs -a
>>> dpkg-gensymbols: error: some new symbols appeared in the symbols
>>> file:
>>> see diff output below
>>> dpkg-gensymbols: warning: debian/libqmi-glib5/DEBIAN/symbols
>>> doesn't
>>> match completely debian/libqmi-glib5.symbols
>>> --- debian/libqmi-glib5.symbols (libqmi-glib5_1.30.4-1_amd64)
>>> +++ dpkg-gensymbolsS9I87O       2022-02-18 06:57:13.066218572 +0100
>>> @@ -564,6 +564,7 @@
>>>     qmi_device_expected_data_format_get_type at Base 1.14.0
>>>     qmi_device_get_expected_data_format at Base 1.14.0
>>>     qmi_device_get_file at Base 1.6.0
>>> + qmi_device_get_node at Base 1.30.4-1
>>>     qmi_device_get_path at Base 1.6.0
>>>     qmi_device_get_path_display at Base 1.6.0
>>>     qmi_device_get_service_version_info at Base 1.6.0
>>> @@ -574,11 +575,14 @@
>>>     qmi_device_list_links at Base 1.28.6
>>>     qmi_device_new at Base 1.6.0
>>>     qmi_device_new_finish at Base 1.6.0
>>> + qmi_device_new_from_node at Base 1.30.4-1
>>> + qmi_device_new_from_node_finish at Base 1.30.4-1
>>>     qmi_device_open at Base 1.6.0
>>>     qmi_device_open_finish at Base 1.6.0
>>>     qmi_device_open_flags_build_string_from_mask at Base 1.10.0
>>>     qmi_device_open_flags_get_type at Base 1.10.0
>>>     qmi_device_peek_file at Base 1.6.0
>>> + qmi_device_peek_node at Base 1.30.4-1
>>>     qmi_device_release_client at Base 1.6.0
>>>     qmi_device_release_client_finish at Base 1.6.0
>>>     qmi_device_release_client_flags_build_string_from_mask at Base
>>> 1.10.0
>>> @@ -653,6 +657,8 @@
>>>     qmi_endpoint_parse_buffer at Base 1.24.6
>>>     qmi_endpoint_qmux_get_type at Base 1.24.6
>>>     qmi_endpoint_qmux_new at Base 1.24.6
>>> + qmi_endpoint_qrtr_get_type at Base 1.30.4-1
>>> + qmi_endpoint_qrtr_new at Base 1.30.4-1
>>>     qmi_endpoint_send at Base 1.24.6
>>>     qmi_endpoint_setup_indications at Base 1.24.6
>>>     qmi_endpoint_setup_indications_finish at Base 1.24.6
>>> dh_makeshlibs: error: failing due to earlier errors
>>> make: *** [debian/rules:10: binary] Error 25
>>>
>>>
>>> After checking with `nm` I can verify that the symbols are indeed
>>> in
>>> `debian/tmp/usr/lib/x86_64-linux-gnu/libqmi-glib.so.5.8.0` but not
>>> in
>>> `debian/libqmi-glib5.symbols`. However the builds went through on
>>> buildd, so I'm wondering what the problem is.
>>>
>>>
>>> Some more digging into those symbols shows:
>>> - `qmi_device_get_node()` `qmi_device_new_from_node()`
>>> `qmi_device_new_from_node_finish()` `qmi_device_peek_node()`
>>> (`src/libqmi-glib/qmi-device.h`) have been there since 1.28
>>> (judging by
>>> the gtk-doc "Since" annotations)
>>> - `qmi_endpoint_qrtr_get_type()` and `qmi_endpoint_qrtr_new()`
>>> don't
>>> have gtk-doc annotations, but checking with `git blame` etc the
>>> first
>>> tag it was included is `1.26-rc1`
>>>
>>>
>>> Any idea why
>>> a) those symbols are not in the symbols file?
>>
>> Those symbols are only present when building with QRTR support using
>> `libqrtr-glib`, which is in the NEW queue. Once this lib is accepted
>> in
>> the archive, I'll release a new libqmi package with QRTR support
>> enabled. The symbols file will be adapted then.
>>
>>> b) buildd does not care about them missing?
>>
>> buildd starts from a clean environment. As the current libqmi package
>> doesn't build-depend on libqrtr-glib-dev for obvious reasons, it
>> doesn't
>> get installed and therefore not detected by the configure script.
>>
>>> c) but my system (fully upgraded testing/sid) cares about them
>>> missing?
>>
>> I assume you have previously built and installed `libqrtr-glib-dev`?
> 
> That's it! I only feel slightly silly now ;)
> Next time I'll build it in a clean environment to recheck (I usually
> only do that after it has build fine locally).

Using minimal docker containers is really useful in such cases (plus it 
keeps your system free from tons of build dependencies you don't care 
about ;) )

> 
> If you want I can send a MR with that patch. I guess the versions that
> I specified are actually wrong since we only care about when the symbol
> was introduced to the binary package, not the upstream software.

Thanks, but that won't be necessary, I already carry this patch for 
Mobian, I'll just cherry-pick the relevant commits once libqrtr-glib is 
accepted.

Cheers,
Arnaud

> 
>>
>> Cheers,
>> Arnaud
>>
>>>
>>> I wasn't sure if this is an issue with the packaging or not
>>> (especially
>>> because buildd is happy) I wanted to reach out first before opening
>>> a
>>> bug. The attached patch let's builds succeed on my end (and I'm
>>> happy
>>> to open a MR should this be useful)
>>>
>>> [Calls] https://gitlab.gnome.org/GNOME/calls/-/issues/310
>>>
>>> Cheers
>>>
>>>
>>> _______________________________________________
>>> Debian-on-mobile-maintainers mailing list
>>> Debian-on-mobile-maintainers at alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
>>
>>
>> _______________________________________________
>> Debian-on-mobile-maintainers mailing list
>> Debian-on-mobile-maintainers at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
> 
> 
> _______________________________________________
> Debian-on-mobile-maintainers mailing list
> Debian-on-mobile-maintainers at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers