Debian Patches
Status for mailutils/1:3.21-1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| set_mu_sieve_moddir.patch | Make MU_SIEVE_MODDIR configurable. This makes libmailutilsX versions coinstallable. =================================================================== |
Jordi Mallach <jordi@debian.org> | yes | |||
| guile-3.0.patch | Re: mailutils: please upgrade to guile-3.0 soon, if feasible =================================================================== |
Rob Browning <rlb@defaultvalue.org> | no | |||
| fix_libpq_include.patch | Fix postgresql include dir. diff --git a/sql/postgres.c b/sql/postgres.c index 1c6bed90b..b9a8cf89d 100644 |
Jordi Mallach <jordi@debian.org> | no | 2021-02-09 | ||
| fix-build-gcc15.patch | Fix build with GCC 15 | Sergej Pupykin <pupykin.s+arch@gmail.com> | invalid | debian | https://gitlab.archlinux.org/archlinux/packaging/packages/mailutils/-/blob/main/fix-build.patch | 2025-09-08 |
| mysql-mariadb-fallback.patch | Fall back to -lmariadb and mariadb/*.h when using mariadb libmariadb-dev ships libmariadb.so and mariadb/{mysql,errmsg}.h instead of libmysqlclient.so and mysql/*.h, so --with-mysql needs to probe for both layouts. =================================================================== |
Jordi Mallach <jordi@debian.org> | yes | 2026-08-18 | ||
| frm-fix-mb_len_max-fortify.patch | fix FTBFS with fortified wcrtomb: "Assumed value of MB_LEN_MAX wrong" frm/frm.h falls back to "#define MB_LEN_MAX 4" without ever including <limits.h>, so on glibc the macro ends up forced to 4. When FriBidi support pulls in <wchar.h>, glibc's fortified wcrtomb() wrapper asserts MB_LEN_MAX == 16 and aborts the build with: . bits/wchar2.h: In function 'wcrtomb': bits/wchar2.h:299:3: error: #error "Assumed value of MB_LEN_MAX wrong" . Including <limits.h> first lets MB_LEN_MAX resolve to its correct system value instead. |
Jordi Mallach <jordi@debian.org> | invalid | upstream | vendor | 2026-08-18 |
| restore-3.20-compat-symbols.patch | Restore exported symbols dropped in 3.21 without a SONAME bump Upstream 3.21 turned mu_cfg_section_add_params, mu_create_canned_param, mu_create_canned_section, and mu_str_expand into static inline wrappers around new _ext/_unquote functions, which drops them from libmailutils.so.9's exported symbols without a SONAME bump. All four are public API (declared in installed headers) with a real, live external consumer (mailfromd calls the cfg trio directly), so an unrebuilt mailfromd would break at runtime if libmailutils9t64 were upgraded in place. Each wrapper is a trivial default-argument call to its _ext/_unquote counterpart, so restoring them as real exported functions is fully ABI-compatible with 3.20 and earlier -- this is not a source-level behavior change, only a visibility one. Carry this patch until upstream 3.22 does a real SONAME bump (see the bug above); drop it then along with the corresponding symbols file entries, since the whole libmailutils.so.9 API/ABI will be superseded. =================================================================== |
Jordi Mallach <jordi@debian.org> | yes | upstream | 2026-08-18 |