Am Mittwoch, dem 11.05.2022 um 20:18 +0200 schrieb Lukáš Krejza:
Dne středa 11. května 2022 19:52:35 CEST, Andrei Borzenkov napsal(a):
On 11.05.2022 19:55, Lukáš Krejza wrote: ...
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
...
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver.
It is not part of libfprint-tod. The whole point of dynamic loading is to enable packaging drivers separately.
Providing your closed source driver for openSUSE is different matter entirely.
Yeah, exactly. I am adding Sp1rit to the loop.
Sorry, wrote my first email before seeing this one in my inbox :/
@Sp1rit, do you plan to submit libfprint-tod to Factory? I noticed that there are some build failures for older Leap versions, but i don't know if these are required to be resolved before Factory submission.
Typically not for Factory, but AFAIK sometimes for individual devel projects. I never really intended to submit this to factory, given that it's basically just a "fork" of libfprint. The specfile is also just a marginally modified specfile from hardware/libfprint (no idea if how much they have drifted between each other over two years). Because this just still just a "fork" it also ships a libfprint-2.so.2 in addition to the libfprint-2-tod.so.1. I also don't know what Factories policy in regards to these kinds of forks are, but I guess it's up to libfprints maintainer? Additionally, 3v1n0s "tod" branch had originally no proper versioning, so I assumed that it was going to be merged at some point into upstream libfprint. Given, that by now 3v1n0 actually tags releases and even has a seperate "tod-devel" branch, it seems like libfprint-tod is here to stay, so it might also have a place in Factory? I asume the best part forward would be merging the two spec files from libfprint and libfprint-tod to create some kind of multi source, single spec package. But I have no experience with that (but I think that what the Kernel packages do?)
For the driver, i have created libfprint-tod-broadcom in my home repo and will continue my work there, so i would be glad if anyone competent could comment if i should move it to Packman of create the package as a pullin, like for example Broadcom wireless firmware packages. Which one is preferred?
Given the propriatory nature of basically al "plugins" for these on hw verify sensors, I stayed far away from packaging the goodix one I use, but if you end up doing so for your sensor, they should probably go into a non openSUSE repo, like Packman.
Thanks.
Gryffus
Cheers, Florian "sp1rit" -- $\int_\text{now}^{+\infty}\text{Keep trying}$ Matrix: @sp1rit:tchncs.de <sp1rit@disroot.org> D248BF2F4C6A82A1E0569D897D8C1CD573166D09 <sp1rit@national.shitposting.agency> BBDE032EAAFBFC627FB7E635B1F4055D8460CE34