lp:fprintd

Created by Registry Administrators on 2012-07-16 and last modified on 2020-02-19
Get this branch:
bzr branch lp:fprintd

Related bugs

Related blueprints

Branch information

Owner:
Registry Administrators
Project:
fprintd
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://anongit.freedesktop.org/libfprint/fprintd.

The next import is scheduled to run in 1 hour.

Last successful import was 4 hours ago.

Import started 4 hours ago on alnitak and finished 4 hours ago taking 20 seconds — see the log
Import started 10 hours ago on alnitak and finished 10 hours ago taking 20 seconds — see the log
Import started 16 hours ago on alnitak and finished 16 hours ago taking 20 seconds — see the log
Import started 23 hours ago on alnitak and finished 23 hours ago taking 20 seconds — see the log
Import started on 2020-02-26 on alnitak and finished on 2020-02-26 taking 20 seconds — see the log
Import started on 2020-02-26 on alnitak and finished on 2020-02-26 taking 20 seconds — see the log
Import started on 2020-02-26 on alnitak and finished on 2020-02-26 taking 20 seconds — see the log
Import started on 2020-02-25 on alnitak and finished on 2020-02-25 taking 20 seconds — see the log
Import started on 2020-02-25 on alnitak and finished on 2020-02-25 taking 20 seconds — see the log
Import started on 2020-02-25 on alnitak and finished on 2020-02-25 taking 20 seconds — see the log

Recent revisions

402. By Bastien Nocera on 2020-02-19

ci: Re-enable stable branch

Now that libfprint v2 has landed in rawhide.

401. By Marco Trevisan (Treviño) on 2020-02-18

ci: Use extends to repeat libfprint builds

This syntax is just nicer and more maintainable than the YAML anchors

400. By Marco Trevisan (Treviño) on 2020-02-18

ci: Factorize the similar parameters in build jobs

399. By Marco Trevisan (Treviño) on 2020-02-14

main: Improve comments on fprint manager creation

Explain why the manager creation is async better in both in the main file
and in the manager itself

398. By Marco Trevisan (Treviño) on 2020-02-14

utils: Fix memory leak when error is ignored in list

If we get a `NoEnrolledPrints` error while list, we don't consider it an
hard error and in such case we proceed to releasing the device, but without
clearing the previously set error first.

397. By Marco Trevisan (Treviño) on 2020-02-14

device: Fix leaked matched print on identify

When starting an identify operation we allocate a gallery of prints from the
gallery, although if we match one of them we get that back in the finish
callback but with a further reference added.

So, in order to clean it up, use an auto-pointer or we'd end up in leaking
it, and the address sanitizer was catching this in our tests already:

  Indirect leak of 12020 byte(s) in 5 object(s) allocated from:
    #0 0x7fe8bc638ce6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
    #1 0x7fe8bc37ffd0 in g_malloc0 ../../glib/glib/gmem.c:132
    #2 0x55d100635c01 in load_from_file ../src/file_storage.c:159
    #3 0x55d100635c01 in file_storage_print_data_load ../src/file_storage.c:182
    #4 0x55d10063e950 in fprint_device_verify_start ../src/device.c:882
    #5 0x55d10064036b in dbus_glib_marshal_fprint_device_VOID__STRING_POINTER src/device-dbus-glue.h:96
    #6 0x7fe8bc50f6f5 (/usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2+0xd6f5)

396. By Marco Trevisan (Treviño) on 2020-02-14

device: Don't leak the user on claim error while deleting prints

When using the delete method we check if the device was claimed, if this
fails because the device is already in use we return an error, but we don't
free the user.

While this could be fixed by just a further g_free call, let's just remove
remove the other manual free calls, and use an auto-pointer instead for this
function.

395. By Marco Trevisan (Treviño) on 2020-02-14

device: Use g_clear_error instead of doing the same manually

We've now an utility function that can help us to free and unset an error
double pointer, so let's use it.

394. By Marco Trevisan (Treviño) on 2020-02-14

delete: Clear the error in case we ignore it

If we get a `NoEnrolledPrints` error during delete, we don't consider it an
hard error and in such case we proceed to releasing the device, but without
clearing the previously set error first.

393. By Marco Trevisan (Treviño) on 2020-02-14

device: Always free error in delete enrolled fingers2

During delete enrolled fingers2 call, if the check-claimed control fails, we
would return the error without freeing it.

While this could be fixed by just a further g_error_free call, let's just
remove the other manual free call, and use an auto-pointer instead for this
function.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.