Debian Patches
Status for mit-scheme/12.1-12
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-chacha.i-rm-_POSIX_C_SOURCE.patch | chacha.i rm _POSIX_C_SOURCE Drop ineffective late (re)definition of _POSIX_C_SOURCE in chacha.i chacha.i is not a translation unit of its own: it is included at the *end* of chacha8.c, chacha12.c and chacha20.c, each of which has already included <stdint.h> and hence <features.h>. Defining _POSIX_C_SOURCE in chacha.i therefore has no effect on which declarations the libc headers expose, but it does redefine a macro <features.h> has already set. That redefinition used to be benign because glibc happened to pick the same value, 200809L. Current glibc defines _POSIX_C_SOURCE as 202405L, so the values differ and gcc reports chacha.i:32:9: error: '_POSIX_C_SOURCE' redefined [-Werror] which is fatal because the microcode is built with -Werror. Nothing in chacha.i or chacha.h needs anything beyond <stdint.h>, so drop the (re)definition rather than hoisting it into the three including files. md5.c, keccak.c and blowfish.c keep theirs: those define _POSIX_C_SOURCE before any #include so it works as intended. |
"Barak A. Pearlmutter" <bap@debian.org> | no | debian | 2026-09-04 | |
| 0002-blowfish.c-stack-overflow.patch | blowfish.c stack overflow There is an 8-byte stack overflow in the self test for blowfish.c, blowfish_selftest() sets up the IV for each of the six chained-mode tests with memcpy(block, IV, 16); but both IV and block are uint8_t[8] -- Blowfish has a 64-bit block, so an 8-byte IV is what makes sense. The copy thus reads 8 bytes past the end of IV and writes 8 bytes past the end of block, into whatever follows it on the stack (in practice buf[], which is overwritten immediately afterwards, which is why this has gone unnoticed). It is still undefined behaviour, and with _FORTIFY_SOURCE it might become a runtime abort when the compiler stops being able to prove otherwise. gcc already sees it: In function 'memcpy', inlined from 'blowfish_selftest' at blowfish.c:537:2: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: '__builtin___memcpy_chk' forming offset [8, 15] is out of the bounds [0, 8] of object 'block' with type 'uint8_t[8]' [-Warray-bounds=] Use sizeof(IV), which is what was meant. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-05 | ||
| 0003-confshared.h-ppc64.patch | confshared.h ppc64 Fix two 64-bit PowerPC problems in confshared.h on ppc64el both the __ppc__ and the __ppc64__ blocks were included, so MACHINE_TYPE and CURRENT_FASL_ARCH were each defined twice. The microcode is built with -Werror, so on ppc64el every file that includes confshared.h failed: error: 'MACHINE_TYPE' redefined [-Werror] error: 'CURRENT_FASL_ARCH' redefined [-Werror] PowerPC, but the __ppc64__ block set only MACHINE_TYPE and CURRENT_FASL_ARCH, while __x86_64__ and __aarch64__ also set HEAP_IN_LOW_MEMORY. (That was masked because of issue above which loaded the 32-bit PowerPC block which does define it.) |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-11 | ||
| 0004-info-sos-rm-extra-siblings.patch | info sos rm extra siblings There is a stray sibling menu in the Introduction node of sos.texi which messes up the info structure and should be deleted. Introduction is @unnumbered, so it is a sibling of the Classes ... Printing chapters, not their parent, and the Top node's master menu already lists all seven at the same level. The extra menu at the end of Introduction claims those six chapters as its children, which contradicts the up pointers in their own @node lines: sos.texinfo:123: warning: node up pointer for `Classes' is `Top' but up is `Introduction' in menu ... and the same for Instances, Slots, Generic Procedures, Methods and Printing. Note that an identical list to the one deleted is in Top's menu one screen earlier. |
"Barak A. Pearlmutter" <bap@debian.org> | invalid | 2026-09-05 | ||
| 0005-texinfo-rm-setfilename.patch | texinfo rm setfilename @setfilename has not been needed since Texinfo 5.0, which takes the output name from the input file name, and giving it is now discouraged. Each of these names its output exactly as the file itself is named, so the line says nothing. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-13 | ||
| 0006-allow-autoreconf-force.patch | allow autoreconf force autoreconf --force in src/ regenerates configure without expanding MIT_SCHEME_NATIVE_CODE, and says nothing about it: no aclocal.m4 there, and nothing tells aclocal where the macro lives. - move src/microcode/aclocal.m4 to src/microcode/mit_scheme_native_code.m4, aclocal.m4 being aclocal's own output file - name that directory with AC_CONFIG_MACRO_DIR in both configure.ac |
"Barak A. Pearlmutter" <barak+git@cs.nuim.ie> | invalid | 2013-07-22 | ||
| 0007-automake-doc.patch | automake doc The hand-written rules ran texi2any and texi2dvi several times over one .texinfo in one directory, so the split and unsplit HTML runs shared an intermediate directory and the PDF and PostScript runs shared the TeX aux files. info_TEXINFOS gives each output its own --build-dir, and .NOTPARALLEL goes. automake takes the info, pdf, ps and html names from the source file name, so the four top-level sources are renamed to the names they install under. The split HTML tree is the one output automake does not cover; it keeps an explicit rule, with its own --output. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-12 | ||
| 0008-automake-microcode.patch | automake microcode The hand-written Makefile.in already imitated automake (aux_PROGRAMS, scheme_SOURCES, install-auxPROGRAMS), and carried 440 lines of hand-maintained header dependencies that automake derives itself. findprim keeps a hand-written rule: it runs during the build, so it is built with HOST_CC rather than CC, which automake cannot express. cmpauxmd keeps its m4 -> .s -> .o chain for the same reason. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-12 | ||
| 0009-automake-src.patch | automake src Mostly scaffolding: the Scheme build is a driver that runs Scheme to compile Scheme, so the bespoke rules stay as they are and hang off all-local, install-data-local and the clean hooks. compile-<plugin>-c ran the same recursive make as compile-<plugin>, so a -j build reaching a plugin by both routes ran two makes in one directory, one relinking x11-const while the other executed it. Only the C back end uses the -c variants, so they are guarded with @IF_LIARC@ and do not exist elsewhere. automake insists `all' is the default goal, so the aggregate that was called `all' is now build-all, and --with-default-target selects it. SUBDIRS becomes SRC_SUBDIRS, being a list for Clean.sh and Tags.sh to walk rather than sub-packages to recurse into. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-12 | ||
| 0010-src-makefile-tools.patch | src makefile tools Of Makefile.tools.in's 27 substitutions only three were live: MIT_SCHEME_EXE, HOST_COMPILER_HEAP and mit_scheme_native_code. The rest was a boilerplate block of directory and install variables nothing referenced, and srcdir, which the file sets to "." itself. Pass the three in from the makefile that invokes it and no .in is needed. It stays a separate makefile: it defines the same seventeen syntax-* and compile-* targets as Makefile.am, for the host toolchain rather than the target, and "make -f" is what keeps the two apart. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-12 | ||
| 0011-automake-microcode-makegen.patch | automake microcode makegen makegen.scm wrote the whole Makefile.in from Makefile.in.in, plus Makefile.deps. automake derives the objects and the header dependencies itself, so all that is left to generate is the source lists: it now writes makegen/sources.am, which Makefile.am includes, and Makefile.in.in goes. configure looks for a Scheme. With one, editing a makegen/files-*.scm is enough: make refreshes the fragment while remaking its makefiles, and automake lists the fragment as a prerequisite of Makefile.in, so the change carries through to the object list. The fragment is shipped, so a build without a Scheme uses it as it stands. The fragment carries no timestamp, so regenerating it when nothing has changed leaves the file alone and starts no rebuild. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-13 | ||
| 0012-AUXDIR_NAME-override.patch | configure: let AUXDIR_NAME be set from the environment src/microcode/configure.ac already defaults it with ":${AUXDIR_NAME:=...}", so it can be chosen from outside; src/configure.ac assigned it unconditionally and then exported it, which overrode that and left no way to select the auxiliary directory name. Default it the same way. The name is otherwise unchanged, so this only matters to a caller that sets the variable -- to install two flavours of one version side by side, for instance. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2013-07-03 | ||
| 0013-man-page.patch | mit-scheme.1: escape literal hyphens In roff a bare "-" is a hyphen, which renders as an en dash in some output formats and breaks both copy-and-paste of option names and apropos(1) searches for them. Option names and the command name want "\-"; the dash in the NAME line is a real dash, so it becomes "\(em". |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2020-06-09 | ||
| 0014-info-dircategory.patch | info dircategory File the info manuals under "The Algorithmic Language Scheme" The MIT/GNU Scheme manuals were by themselves under "Programming Languages" in the top-level Info directory, while other Debian Scheme systems (Guile, SCM, SLIB, XlibScm) all use section "The Algorithmic Language Scheme". Use the same @dircategory as everybody else, in all seven manuals (the four in doc/ plus the three plugin manuals under src/), so that they are listed together, and update doc/info-dir -- the fallback top-level Info node, installed only when none exists -- to match. |
"Barak A. Pearlmutter" <bap@debian.org> | not-needed | debian | 2026-09-04 | |
| 0015-configure-host-heap.patch | configure: size the host compiler heap by the host, not the target --heap 10000 was given whenever the target was 32-bit SVM. On a 64-bit host cross-compiling to svm1-32le that is a cut from the 128MB default to 80MB, and compile-runtime dies with "Aborting!: out of memory". Ask the host Scheme its word size instead. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-17 | ||
| 0016-sf-target-fixnum-bounds.patch | sf: integrate the fixnum bounds of the target, not the host usual-integrations integrates fx-greatest, fx-least and fx-width by value, and the values were the host's, cached when the sf band was built. Cross-compiling 64 -> 32, 2^57-1 lands in a 26-bit datum as all ones, so fx-greatest is -1 on the target: (int:+ fx-greatest 1) is a bignum zero and the cold load dies in initialize-cache-numbers!. Compute them from target-bytes-per-object, remember what word size the cache was built for, and rebuild it if that has changed by the time a usual-integrations declaration is processed. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-17 | ||
| 0017-heap-32bit-default.patch | option.c: 32MB default heap on 32-bit, up from 12MB 3072 blocks is not enough to compile imail-imap.scm any more: ;Compiling file: "imail-imap.bin" => "imail-imap.com"... ;Aborting!: out of memory which is how every 32-bit build of the plugins has been ending, unless MITSCHEME_HEAP_SIZE was set by hand. 4096 suffices today; 8192 leaves room, and with the band's own heap added on load still sits well under the 64MB that HEAP_IN_LOW_MEMORY allows. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-17 | ||
| 0018-clean-keep-makefile-tools.patch | Clean.sh: keep Makefile.tools It is a source file now, not configure output, and "make distclean" must not delete it. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-18 | ||
| 0019-aarch64-dlink-mask.patch | aarch64: strip the type code from the restored dynamic link interface_to_scheme copied REGBLOCK_VAL into the dynamic-link register as is. After an interrupt taken through comutil_interrupt_dlink that value is a stack-environment object, so the register held a tagged pointer. Top-byte-ignore let loads and stores through it succeed, which is why compiled code ran at all; but the stack pointer derived from it was a huge number to every stack check and to the GC, and the build died with SIGSEGV at a point that depended on the memory layout -- reproducibly under sbuild, never in a login session. x86-64 masks the value here; do the same. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-18 | ||
| 0020-confshared.h-riscv64-loong64.patch | confshared.h: recognise riscv64 and loong64 for the SVM back end Neither has a native-code back end, so all that is needed is a machine type for the configuration to be recognised at all, and HEAP_IN_LOW_MEMORY so that the object representation matches the other 64-bit little-endian ports and a band built on one loads on the others. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-22 | ||
| 0021-uxtrap.h-executable-start.patch | uxtrap.h: use __executable_start, not the legacy _init Newer ports do not provide _init at all, so linking the microcode fails on loong64 with "undefined reference to `_init'". __executable_start is supplied by the linker on every ELF target, and the NetBSD/aarch64 case here already redefined _init to it. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-22 | ||
| 0022-reproducible-compilation.patch | Make compilation output reproducible Two things made every build of the same source differ. compiler/base/toplev.scm gave each compiled file a *debugging-key* of (random-bytevector 32), stored in both the .com and its .bci to tie them together. The default random source is seeded from entropy during the cold load and that state is frozen into the band, so every compiler process run from a given band draws the same sequence -- and a band built by the next build draws a different one. Every .com and .bci in the tree therefore differed, by exactly those 32 bytes. Derive the key from the input and output pathnames instead: still unique per compilation unit, and it changes whenever the pair does, so it detects a stale .bci at least as well as a random value did. sf/toplev.scm stamped every .bin with the wall clock. Honour SOURCE_DATE_EPOCH when it is set. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-23 | ||
| 0023-zero-bytevector-padding.patch | Zero the padding at the end of bytevectors and strings Nothing reads those bytes, but fasdump writes whole words, so the heap garbage in them ends up in .bin and .com files and makes the build unreproducible (and leaks heap contents into the output). |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-23 | ||
| 0024-reproducible-bands.patch | Keep the clock and the entropy pool out of saved bands disk-save dumped the heap with the garbage collector's statistics history still in it -- a ring of records holding the universal time and the process- and real-time clock readings of this process's collections -- along with the decoded time it stashes for identify-world, the time the dumping process restored its own band, and the default random source's entropy-seeded state. Every band therefore differed between builds, and since the compiler runs from a band, so did most of what it compiled. Before dumping, clear the statistics, go quiescent so that the dump's own collections record zeros rather than clock readings, forget the restore time, and give the random source a fixed state. Reset and randomize again once the dump is done; a restored band resets through event:after-restore. Take the saved-world time from SOURCE_DATE_EPOCH when it is set. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-23 | ||
| 0025-deterministic-cold-load.patch | Do not seed the cold load from the entropy pool Whatever the cold load draws from the default random source is frozen into the band it produces: comparator.scm's hash salts, dispatch-tag's cache numbers. Entropy there makes every band, and everything later compiled from it, differ between builds. Seed both deterministically. Restoring a band has never reseeded, so a given band has always handed every process that runs it the same sequence -- this only changes which one. (That it does so at all is a separate bug: (random n) returns the same value on every machine running a given band.) |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-23 | ||
| 0026-array-bounds-not-fatal.patch | configure: do not make -Warray-bounds fatal The i386 back end addresses half its compiled-code hooks at negative offsets from Registers[], so that every hook fits in a byte offset; cmpintmd/i386.c explains this and sets "offset = -128". The storage is there: cmpint.c places "void * Regstart [32]" immediately before Registers[] in a single struct. But cmpintmd/i386.c sees only the "extern SCHEME_OBJECT Registers []" declaration, so gcc reasons about the bounds from that alone and rejects all 44 of them: cmpintmd.c:250:4: error: array subscript -6 is outside array bounds of 'SCHEME_OBJECT[536870911]' [-Werror=array-bounds] This is fatal as the microcode is built with -Werror, so the i386 native build does not compile at all. So we demote it to a warning, following the logic and placement of -Wno-error=stringop-truncation. This does not make the access conforming as it *is* still outside the Registers[] object. Addressing it through the enclosing struct would be the real fix. This only stops gcc's detection of an out-of-bounds error from being fatal. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-28 | ||
| 0027-uxtrap-sigcontext-uintptr.patch | uxtrap.c: cast sigcontext registers through uintptr_t On Linux the registers in a signal context are greg_t, which is 64-bit on every x86-64 kernel ABI -- including x32, where a pointer is 32 bits. Casting one straight to SCHEME_OBJECT * is then a narrowing cast between an integer and a pointer, which gcc rejects: uxtrap.c:396:17: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] fatal under the microcode's -Werror, so x32 does not compile at all. Go through uintptr_t: a no-op where the two already agree, and on x32 the truncation is what is wanted, addresses there being 32 bits. |
"Barak A. Pearlmutter" <barak+git@pearlmutter.net> | invalid | 2026-09-28 |