Register | Log in

python-filelock

platform independent file locking module

Choose email to subscribe with

general

source: python-filelock (main)
version: 4.2.8-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.2.8-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]
4.2.8-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

python3-filelock

action needed

16 security issues in trixie high

There are 16 open security issues in trixie.

15 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-112908: filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1, StrictSoftFileLock and AsyncStrictSoftFileLock on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. 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-112938: filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, On POSIX platforms, StrictSoftFileLock and AsyncStrictSoftFileLock validate the coordination directory in _ensure_protocol_directory but later reach the claims directory through _open_directory by pathname, allowing a local account that can rename the coordination name to swap in a symbolic link between check and use during acquisition. That race can create and leave claim files in another writable directory or strand claims in a different strict lock so the second lock times out. Separately, the claims property and force_break follow a resting symbolic link without a race when the lock user inspects or recovers the lock. Claims inspection discloses a file name to the other account only if the resulting exception text or claim_name reaches that account through a shared log, CI output, or error report. A blind force_break recovery that removes live claims from another strict lock can allow two processes into that lock's critical section; this path reaches other strict locks, not arbitrary files. 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-11-06 16:02

14 security issues in forky high

There are 14 open security issues in forky.

14 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-112908: filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1, StrictSoftFileLock and AsyncStrictSoftFileLock on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. 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-112938: filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, On POSIX platforms, StrictSoftFileLock and AsyncStrictSoftFileLock validate the coordination directory in _ensure_protocol_directory but later reach the claims directory through _open_directory by pathname, allowing a local account that can rename the coordination name to swap in a symbolic link between check and use during acquisition. That race can create and leave claim files in another writable directory or strand claims in a different strict lock so the second lock times out. Separately, the claims property and force_break follow a resting symbolic link without a race when the lock user inspects or recovers the lock. Claims inspection discloses a file name to the other account only if the resulting exception text or claim_name reaches that account through a shared log, CI output, or error report. A blind force_break recovery that removes live claims from another strict lock can allow two processes into that lock's critical section; this path reaches other strict locks, not arbitrary files. 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-11-06 16:02

15 security issues in bookworm high

There are 15 open security issues in bookworm.

15 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-112908: filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1, StrictSoftFileLock and AsyncStrictSoftFileLock on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. 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-112938: filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, On POSIX platforms, StrictSoftFileLock and AsyncStrictSoftFileLock validate the coordination directory in _ensure_protocol_directory but later reach the claims directory through _open_directory by pathname, allowing a local account that can rename the coordination name to swap in a symbolic link between check and use during acquisition. That race can create and leave claim files in another writable directory or strand claims in a different strict lock so the second lock times out. Separately, the claims property and force_break follow a resting symbolic link without a race when the lock user inspects or recovers the lock. Claims inspection discloses a file name to the other account only if the resulting exception text or claim_name reaches that account through a shared log, CI output, or error report. A blind force_break recovery that removes live claims from another strict lock can allow two processes into that lock's critical section; this path reaches other strict locks, not arbitrary files. 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-11-06 16:02

The VCS repository is not up to date, push the missing commits. high

vcswatch reports that the current version of the package is not in its VCS.
Either you need to push your commits and/or your tags, or the information about the package's VCS are out of date. A common cause of the latter issue when using the Git VCS is not specifying the correct branch when the packaging is not in the default one (remote HEAD branch), which is usually "master" but can be modified in salsa.debian.org in the project's general settings with the "Default Branch" field). Alternatively the Vcs-Git field in debian/control can contain a "-b <branch-name>" suffix to indicate what branch is used for the Debian packaging.

Created: 2026-10-18 Last update: 2026-11-04 22:31

debian/patches: 1 patch to forward upstream low

Among the 1 debian patch available in version 4.2.8-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-11-05 08:01

testing migrations

excuses:
- Migration status for python-filelock (4.1.1-1 to 4.2.8-1): Waiting for test results or another package, or too young (no action required now - check later)
- Issues preventing migration:
- ∙ ∙ Too young, only 2 of 5 days old
- Additional info (not blocking):
- ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/p/python-filelock.html
- ∙ ∙ Autopkgtest for python-filelock/4.2.8-1: amd64: No tests, superficial or marked flaky ♻, arm64: No tests, superficial or marked flaky ♻, armhf: No tests, superficial or marked flaky ♻ (reference ♻), i386: No tests, superficial or marked flaky ♻, loong64: No tests, superficial or marked flaky ♻ (reference ♻), ppc64el: No tests, superficial or marked flaky ♻, riscv64: No tests, superficial or marked flaky ♻ (reference ♻), s390x: No tests, superficial or marked flaky ♻ (reference ♻)
- ∙ ∙ Autopkgtest for pytorch/2.14.1+dfsg-1: amd64: Pass, arm64: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Reproduced on amd64 - info
- ∙ ∙ Reproduced on arm64 - info
- ∙ ∙ Reproduced on armhf - info
- ∙ ∙ Reproduced on i386 - info
- Not considered

news

[2026-11-04] Accepted python-filelock 4.2.8-1 (source) into unstable (Sascha Steinbiss)
[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)

1
2

bugs [bug history graph]

all: 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

Debian Package Tracker — Copyright 2013-2025 The Distro Tracker Developers

Report problems to the tracker.debian.org pseudo-package in the Debian BTS.

Documentation — Bugs — Git Repository — Contributing