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

Fri Feb 18 08:43:18 GMT 2022

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).

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.

> 
> 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