python-filelock - Debian Package Tracker

general

source: python-filelock (main)
version: 4.1.1-1
maintainer: Sascha Steinbiss (DMD) (LowNMU)
arch: all
std-ver: 4.7.4
VCS: Git (Browse, QA)

versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]

[pool directory]

o-o-stable: 3.0.12-2
oldstable: 3.9.0-1+deb12u1
old-p-u: 3.9.0-1+deb12u1
stable: 3.18.0-1+deb13u1
testing: 4.1.1-1
unstable: 4.1.1-1

versioned links

3.0.12-2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
3.9.0-1+deb12u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
3.18.0-1+deb13u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
4.1.1-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

python3-filelock

action needed

A new upstream version is available: 4.2.4 high

A new upstream version 4.2.4 is available, you should consider packaging it.

Created: 2026-10-15 Last update: 2026-10-23 11:30

14 security issues in trixie high

There are 14 open security issues in trixie.

13 important issues:

CVE-2026-112906: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1.
CVE-2026-112909: filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.
CVE-2026-112911: filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.
CVE-2026-112912: filelock is a platform-independent file lock for Python. From 3.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
CVE-2026-112914: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory. This issue is fixed in version 4.2.1.
CVE-2026-112915: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.
CVE-2026-112934: filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.
CVE-2026-112935: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.
CVE-2026-112936: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.
CVE-2026-112937: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.
CVE-2026-112939: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.
CVE-2026-112940: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.
CVE-2026-112941: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.

1 issue left for the package maintainer to handle:

CVE-2026-22701: (needs triaging) filelock is a platform-independent file lock for Python. Prior to version 3.20.3, a TOCTOU race condition vulnerability exists in the SoftFileLock implementation of the filelock package. An attacker with local filesystem access and permission to create symlinks can exploit a race condition between the permission validation and file creation to cause lock operations to fail or behave unexpectedly. The vulnerability occurs in the _acquire() method between raise_on_not_writable_file() (permission check) and os.open() (file creation). During this race window, an attacker can create a symlink at the lock file path, potentially causing the lock to operate on an unintended target file or leading to denial of service. This issue has been patched in version 3.20.3.

You can find information about how to handle this issue in the security team's documentation.

Created: 2026-01-10 Last update: 2026-10-23 05:01

12 security issues in sid high

There are 12 open security issues in sid.

12 important issues:

CVE-2026-112906: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1.
CVE-2026-112909: filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.
CVE-2026-112911: filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.
CVE-2026-112912: filelock is a platform-independent file lock for Python. From 3.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
CVE-2026-112914: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory. This issue is fixed in version 4.2.1.
CVE-2026-112915: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.
CVE-2026-112934: filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.
CVE-2026-112935: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.
CVE-2026-112937: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.
CVE-2026-112939: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.
CVE-2026-112940: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.
CVE-2026-112941: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.

Created: 2026-10-21 Last update: 2026-10-23 05:01

12 security issues in forky high

There are 12 open security issues in forky.

12 important issues:

CVE-2026-112906: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1.
CVE-2026-112909: filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.
CVE-2026-112911: filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.
CVE-2026-112912: filelock is a platform-independent file lock for Python. From 3.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
CVE-2026-112914: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory. This issue is fixed in version 4.2.1.
CVE-2026-112915: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.
CVE-2026-112934: filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.
CVE-2026-112935: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.
CVE-2026-112937: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.
CVE-2026-112939: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.
CVE-2026-112940: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.
CVE-2026-112941: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.

Created: 2026-10-21 Last update: 2026-10-23 05:01

13 security issues in bookworm high

There are 13 open security issues in bookworm.

13 important issues:

CVE-2026-112906: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1.
CVE-2026-112909: filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.
CVE-2026-112911: filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.
CVE-2026-112912: filelock is a platform-independent file lock for Python. From 3.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
CVE-2026-112914: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory. This issue is fixed in version 4.2.1.
CVE-2026-112915: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.
CVE-2026-112934: filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.
CVE-2026-112935: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.
CVE-2026-112936: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.
CVE-2026-112937: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.
CVE-2026-112939: filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.
CVE-2026-112940: filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.
CVE-2026-112941: filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.

Created: 2026-10-21 Last update: 2026-10-23 05:01

version in VCS is newer than in repository, is it time to upload? normal

vcswatch reports that this package seems to have a new changelog entry (version 4.2.2-1, distribution unstable) and new commits in its VCS. You should consider whether it's time to make an upload.

Here are the relevant commit messages:

commit 20fd6bf1bd9cb247b3a78f62a9289f6c9d8ceaf0
Author: Sascha Steinbiss <satta@debian.org>
Date:   Sun Oct 18 19:59:20 2026 +0200

    update patches for build

commit d9727acf95979e20df0bbbeec447353757265f38
Merge: 633ba3b 06cb712
Author: Sascha Steinbiss <satta@debian.org>
Date:   Sun Oct 18 18:33:42 2026 +0200

    Update upstream source from tag 'upstream/4.2.2'
    
    Update to upstream version '4.2.2'
    with Debian dir f5709c07d401020b1d3265010b3b33d9318cb00c

commit 06cb712be5f19056f4a9538380939ef3661e2bcd
Author: Sascha Steinbiss <satta@debian.org>
Date:   Sun Oct 18 18:33:39 2026 +0200

    New upstream version 4.2.2

Created: 2026-10-18 Last update: 2026-10-18 19:30

debian/patches: 1 patch to forward upstream low

Among the 1 debian patch available in version 4.1.1-1 of the package, we noticed the following issues:

1 patch where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update the metadata to document its real status.

Created: 2026-10-14 Last update: 2026-10-14 10:00

news

[rss feed]

[2026-10-22] python-filelock 4.1.1-1 MIGRATED to testing (Debian testing watch)
[2026-10-13] Accepted python-filelock 4.1.1-1 (source) into unstable (Sascha Steinbiss)
[2026-10-09] Accepted python-filelock 4.0.12-1 (source) into unstable (Sascha Steinbiss)
[2026-09-25] python-filelock 4.0.1-1 MIGRATED to testing (Debian testing watch)
[2026-09-19] Accepted python-filelock 4.0.1-1 (source) into unstable (Sascha Steinbiss)
[2026-09-19] python-filelock 3.32.6-1 MIGRATED to testing (Debian testing watch)
[2026-09-11] Accepted python-filelock 3.32.6-1 (source) into unstable (Sascha Steinbiss)
[2026-09-09] python-filelock 3.32.5-1 MIGRATED to testing (Debian testing watch)
[2026-09-03] Accepted python-filelock 3.32.5-1 (source) into unstable (Sascha Steinbiss)
[2026-09-03] python-filelock 3.32.4-2 MIGRATED to testing (Debian testing watch)
[2026-08-27] Accepted python-filelock 3.32.4-2 (source) into unstable (Alexandre Detiste)
[2026-08-25] Accepted python-filelock 3.32.4-1 (source) into unstable (Sascha Steinbiss)
[2026-08-19] python-filelock 3.32.2-1 MIGRATED to testing (Debian testing watch)
[2026-08-13] Accepted python-filelock 3.32.2-1 (source) into unstable (Sascha Steinbiss)
[2026-08-08] python-filelock 3.32.0-1 MIGRATED to testing (Debian testing watch)
[2026-07-26] Accepted python-filelock 3.32.0-1 (source) into unstable (Sascha Steinbiss)
[2026-07-15] python-filelock 3.29.7-1 MIGRATED to testing (Debian testing watch)
[2026-07-10] Accepted python-filelock 3.29.7-1 (source) into unstable (Sascha Steinbiss)
[2026-07-10] python-filelock 3.29.5-1 MIGRATED to testing (Debian testing watch)
[2026-07-04] Accepted python-filelock 3.29.5-1 (source) into unstable (Sascha Steinbiss)
[2026-06-21] python-filelock 3.29.4-1 MIGRATED to testing (Debian testing watch)
[2026-06-16] Accepted python-filelock 3.9.0-1+deb12u1 (source all) into oldstable-proposed-updates (Debian FTP Masters) (signed by: Sascha Steinbiss)
[2026-06-13] Accepted python-filelock 3.29.4-1 (source) into unstable (Sascha Steinbiss)
[2026-04-28] python-filelock 3.29.0-1 MIGRATED to testing (Debian testing watch)
[2026-04-23] Accepted python-filelock 3.29.0-1 (source) into unstable (Sascha Steinbiss)
[2026-03-22] python-filelock 3.25.2-1 MIGRATED to testing (Debian testing watch)
[2026-03-16] Accepted python-filelock 3.25.2-1 (source) into unstable (Sascha Steinbiss)
[2026-03-12] python-filelock 3.25.0-1 MIGRATED to testing (Debian testing watch)
[2026-03-07] Accepted python-filelock 3.25.0-1 (source) into unstable (Sascha Steinbiss)
[2026-03-01] python-filelock 3.24.3-1 MIGRATED to testing (Debian testing watch)

bugs [bug history graph]

all: 1
RC: 0
I&N: 1
M&W: 0
F&P: 0
patch: 0

links

homepage
lintian
buildd: logs, reproducibility
popcon
browse source code
other distros
security tracker
debian patches
debci

ubuntu

[Information about Ubuntu for Debian Developers]

version: 3.32.2-1