Le 17/07/17 à 11:28, Michal Čihař a écrit :
Hello
Laurent Bigonville píše v Pá 14. 07. 2017 v 17:57 +0200:
It seems that libgusb2 has lost some symbols in the last upgrade
without
bumping the soname.
fwupd is complaining with the following messages:
jui 14 17:49:30 valinor fwupd[2426]: failed to open plugin
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_unifying.so:
failed to open plugin: /usr/lib/x86_64-linux-gnu/fwupd-plugins-
2/libfu_plugin_unifying.so: symbol g_usb_device_get_release, version
LIBGUSB_0.1.0 not defined in file libgusb.so.2 with link time
reference
jui 14 17:49:30 valinor fwupd[2426]: failed to open plugin
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_usb.so: failed
to open plugin: /usr/lib/x86_64-linux-gnu/fwupd-plugins-
2/libfu_plugin_usb.so: symbol g_usb_device_get_release, version
LIBGUSB_0.1.0 not defined in file libgusb.so.2 with link time
reference
jui 14 17:49:30 valinor fwupd[2426]: failed to open plugin
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_colorhug.so:
failed to open plugin: /usr/lib/x86_64-linux-gnu/fwupd-plugins-
2/libfu_plugin_colorhug.so: symbol g_usb_context_wait_for_replug,
version LIBGUSB_0.1.0 not defined in file libgusb.so.2 with link time
reference
jui 14 17:49:30 valinor fwupd[2426]: failed to open plugin
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_altos.so:
failed to open plugin: /lib/x86_64-linux-gnu/libdfu.so.1: symbol
g_usb_interface_get_subclass, version LIBGUSB_0.1.0 not defined in
file libgusb.so.2 with link time reference
jui 14 17:49:30 valinor fwupd[2426]: failed to open plugin
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_dfu.so: failed
to open plugin: /lib/x86_64-linux-gnu/libdfu.so.1: symbol
g_usb_interface_get_subclass, version LIBGUSB_0.1.0 not defined in
file libgusb.so.2 with link time reference
The problem is that 0.2.8 and 0.2.9 releases had broken version script
(not listing some newly added symbols and those were wrongly generated
as introduced in LIBGUSB_0.1.0, while they were added later). This was
fixed in the 0.2.10 release:
https://github.com/hughsie/libgusb/compare/gusb_0_2_9...gusb_0_2_10#dif
f-5252c79baf9de758594b8543f116836d
I will revert the symbol versioning changes and let's see how upstream
will address this:
https://github.com/hughsie/libgusb/issues/9
If you don't have a lot of reverse-dependency, one of the solution is to
ask to binNMU to rebuild the packages with the proper version of the
symbol then and then wait to see what upstream is saying
INVHO I wouldn't revert the change without knowing what upstream will
do, you might end up with carrying a patch forever...
