Debian Patches
Status for dact/0.8.42-7
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 02-lzo2.patch | configure.in: odified configure to check for lzo2 by Riku Voipio <riku.voipio@iki.fi> | Jari Aalto <jari.aalto@cante.net> | no | 2010-05-24 | ||
| 10-Docs--dact.1.patch | Docs/dact.1: Fix hyphens etc. | Jari Aalto <jari.aalto@cante.net> | no | 2010-05-24 | ||
| 20-Makefile.in.patch | adjust Makefile.in for proper Debian package build Tommaso Moroni <moronito@debian.org>: commented module_dir param to disable modules Disable Magic file install. This is job for file(1). . David da Silva Polverari <polverari@debian.org>: made install target honor DESTDIR and restore original Makefile.dep and dact.conf files upon the execution of the clean target, due to the reduction of debian/rules to a minimal DH invocation form. |
David da Silva Polverari <polverari@debian.org> | no | 2024-05-19 | ||
| 30-fix-lzo-comp.patch | update Makefile include files to use liblzo2 After converting debian/rules to use a minimal DH invocation, it no longer issued the `sed -i 's/llzo$$/llzo2/' *.lnk` command to update the *.lnk files included by the Makefile to use liblzo2 instead of liblzo. . This patch functionally replaces the removed command on debian/rules by updating the linker flags directly on the include files. |
David da Silva Polverari <polverari@debian.org> | no | 2024-05-19 | ||
| 40-uniform-api-algorithms.patch | Declare a uniform interface for compression algorithms In C23, having no parameter in a function declaration no longer means an "unspecified" number of arguments [1]. In order to specify the complete expected function signature in algorithms array declaration, define a compatible interface for all of them. This means declaring the out_block an unsigned char pointer instead of a signed one. Although most algorithms don't declare this interface, they actually expect to be operating on an unsigned array. It is clear by the local variable declarations in most of them, namely: - delta - rle - snibble (explicit casting) - text - textrle The `plain` algorithm is also clear, as it is essentially a memcpy(3). Finally, the ones from liblzo2-dev (that is, lzoox, lzooy, lzota) are passed directly to their specific functions, which expect an lzo_bytep, that is, a pointer to unsigned char. Bitsums and factor aren't yet implemented. Thus, they can take an unsigned char as well. Similarly, the special `fail` algorithm doesn't use any provided parameter at all. [1] https://gcc.gnu.org/gcc-15/porting_to.html |
"Henrique F. Simoes" <henriquesimoes@riseup.net> | no | debian | 2025-10-09 | |
| 41-uniform-api-ciphers.patch | Declare a uniform interface for ciphers Cipher functions are assigned to an array of supported ciphers. However, no parameter is specified in its declaration, which makes it incompatible with C23 [1]. Resolve this by specifying the expected parameters. To do so, change the functions signatures to match a common one. This means changing the inblock, outblock, and key arguments from char to unsigned char in Serpent and Chaos ciphers. Although this changes the type, all functions can actually properly handle unsigned data without changing their output, as explained below. For cipher_serpent, it only uses its key for initialization. During this phase, it resets its bytes using memset(3) and later copies a sequence of chars with memcpy(3). None of these change the output when operating on an unsigned type. Then, it is forwarded to be read by mcrypt_generic_init, which takes a pointer to void in its second argument. Internally, it memmove(3)s the `key` to td->keyword_given, which is actually an unsigned char. Therefore, `unsigned char` is an appropriate type for its key. Furthermore, its input buffer is simply memcpy(3)'ed and forwarded to mcrypt_generic(), which expects an array of bytes. On the other hand, for cipher_chaos, its bytes are converted to an integer by atoi(3). As such, bytes are expected to be greater than zero so they are in the number range for ASCII (48-59). Any characters beyond 127 will make the program behave exactly was it was before, as none of them are valid digits nor spaces. Nevertheless, a explicit cast is added, so signedness match. In addition, its input buffer is processed by bitwise ORing it with another byte, whose output is the same as with signed bytes. In both cases, the output block can be safely declared as unsigned char as well, as it will only be later forwarded to write(2), which expect an array of bytes. [1] https://gcc.gnu.org/gcc-15/porting_to.html |
"Henrique F. Simoes" <henriquesimoes@riseup.net> | no | debian | 2025-10-12 |