[needs-packaging] libfprint-2-tod1-broadcom-cv3plus

[Yao Wei]

Firmwares and shared libraries for fingerprint support on Dell ControlVault3 Plus

URL: https://packages.broadcom.com/artifactory/dell-controlvault-drivers/
License: Proprietary
Note: We will also need this to be backported to noble for OEM support. The upstream release versioning is shared with ControlVault3 (non-Plus), as 6.x.x is for CV3 Plus, and 5.x.x is for CV3 (for the package libfprint-2-tod1-broadcom).

[Yao Wei (medicalwei)]

This package currently resides in:
https://launchpad.net/~medicalwei/+archive/ubuntu/dell-cv3-cv3plus

Packaging source:
https://git.launchpad.net/~oem-solutions-engineers/pc-enablement/+git/libfprint-2-tod1-broadcom-cv3plus

[Brian Murray (brian-murray)]

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

[Dave Jones (waveform)]

I think I need to understand a bit more about the relationship between this and LP: #2099655.

Are CV3 and CV3 Plus two different models of similar hardware?

It seems (upstream at least) that there are two versions of the same package (brcm_linux_fp): 5.x and 6.x. However, it appears you wish to package these two different versions as two different source packages? While this is doable, we'd typically have something like libfprint-foo-5 and libfprint-foo-6.

Would I be right in assuming that the CV3 is only supported on the 5.x version and the CV3 Plus is only supported on the 6.x version?

[Yao Wei (medicalwei)]

They support different hardware, exclusively, and I'm not sure whether using version number as suffix is required in this context as that is not the difference of library ABI version.

[Yao Wei (medicalwei)]

Uploaded 6.1.155-6.1.028.0+1-0ubuntu1~oem1 for the issues found in Bug #2099655, as for the upstream version change, I found I was uploading a repacked package instead of the original, and I was trying to correct it back.

[Marco Trevisan (Treviño) (3v1n0)]

One thing to mention here, these drivers are completely fine to be in the archive, but we should make sure that users are using `ubuntu-drivers` to install them.

Since distributing them in an installed OEM machine, may potentially break the fprintd GPL license.

[Yao Wei (medicalwei)]

libfprint itself is LGPL-2.1 licensed, and fprintd is GPL-2, but is communicating with libfprint using D-Bus, and the prebuilt binary Broadcom provides dynamically links to libfprint. I don't sense there's a GPL license violation by that. We could consult our legal team if further clarification is needed.

Despite of these, we do not install the package and ship the systems by default for OEM.

[Marco Trevisan (Treviño) (3v1n0)]

Sadly no:

> But is communicating with libfprint using D-Bus

fprintd is linked to libfprint, the situation is slippery and we had already contacted the legal team in the past, given that indeed it can be confusing (and that fprintd upstream warned us about).

Now the fact I'm also fprintd upstream doesn't change the fact that it's better to be extra-cautious when handling TOD drivers so that they are never installed together to fprintd, without user consent.

[Dave Jones (waveform)]

We're past feature freeze but that's okay for new packages going into universe which won't be on any published images. It appears the issues raised here and in the associated LP: #2099655 have been addressed so I'm sponsoring for plucky (minus the ~oemN suffix as I'm assuming that was added purely for rebuilds in the PPA).

[Dave Jones (waveform)]

Oops, forgot to remove sponsors after sponsoring this!