Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
report_error_removing_dirs | report_error_removing_dirs =================================================================== |
Debian/Kubuntu Qt/KDE Maintainers <debian-qt-kde@lists.debian.org> | no | 2016-03-31 | ||
hurd_disable_unimplemented.diff | On Hurd, do not look for functions unimplemented in libc The check_function_exists() function of cmake does not keep into account the defines that glibc provides for the stubs (i.e. unimplemented functions that always return ENOSYS), so some functions are detected as available. Unfortunately, due to --fatal-warnings for the linker, linking will fail. Hence, do not attempt to look for functions that are currently unimplemented on GNU/Hurd's libc. |
Pino Toscano <pino@debian.org> | not-needed | 2022-02-22 | ||
Use-CXX_FLAGS-for-moc_predefs.h.patch | Use CXX_FLAGS for moc_predefs.h | Maximiliano Curia <maxy@gnuservers.com.ar> | no | 2019-08-28 | ||
upstream_3e6800b3_fix_cifs_copy.patch | [PATCH] Don't unlink + rename on CIFS mounts during copy operations It turns out that the behavior of unlink() on CIFS mounts can be a bit "interesting". If the file one tries to unlink is opened then the operation is claimed to have succeeded but the filename is still visible in the file hierarchy until the last handle is closed. Since we rightfully attempt to copy under a temporary name + unlink + rename during copy() operations this would end badly (as the unlink() would "succeed" but the rename() would fail!). For instance Okular would constantly hit this case but it's likely not the only one to be affected. So instead we detect if the destination is a CIFS mount, in such cases we now overwrite the file directly since this actually succeed. (cherry picked from commit d248949eea3e3dcbb9283f30eebcb9ae86412cd1) |
Kevin Ottens <kevin.ottens@enioka.com> | no | upstream | 2023-08-24 | |
upstream_48322f44_fix_crash_when_kmountpoint_gives_nothing_on_cifs.patch | [PATCH] Don't crash if KMountPoint gives nothing back while checking for CIFS | Kevin Ottens <kevin.ottens@enioka.com> | no | upstream | 2023-09-15 | |
fix_cifs_file_locks.patch | [PATCH] Don't leak file descriptors when spawning new workers By default we inherit file descriptors from the parent in the worker process. This is a leak of resources since the worker won't be able to do anything with them. Also, in the case of CIFS this causes locks which might lead to bad surprises in the parent process. |
Kevin Ottens <kevin.ottens@enioka.com> | no | 2024-01-05 |