| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Mark-mutex-with-owner-not-retained-threads-test-as-u.patch | Mark "mutex with owner not retained" threads test as unresolved. As per discussion with upstream, mark this test as unresolved since it may produce false negatives, depending on the behavior/timing of the garbage collector. |
Rob Browning <rlb@defaultvalue.org> | no | 2012-03-18 | ||
| 0002-Look-for-guile-procedures.txt-in-pkglibdir.patch | Look for guile-procedures.txt in pkglibdir Look for guile-procedures.txt in %guile-build-info's pkglibdir first since the content is not architecture independent. |
Rob Browning <rlb@defaultvalue.org> | yes | debian upstream | 2016-08-12 | |
| 0003-Disable-sandbox.test-1e6-alloc-loop-allocation-limit.patch | Disable sandbox.test "1e6 alloc loop" "allocation limit" test The test suite would eventually hang on sandbox.test when run in a "make -j5 check" loop. The last test printed to the log was the one before "1e6 alloc loop", and after commenting out that test, the loop doesn't appear to hang, so disable it for now. |
Rob Browning <rlb@defaultvalue.org> | no | 2018-02-20 | ||
| 0004-Disable-intermittently-failing-test-out-of-memory-te.patch | Disable intermittently failing test-out-of-memory test for now After checking with upstream, disable a test-out-of-memory test that appears to have been causing a FTBS on a number of architectures. (Running test-suite/standalone/test-out-of-memory in a loop reproduces the problem very quickly on amd64 here.) |
Rob Browning <rlb@defaultvalue.org> | no | debian | 2018-02-20 | |
| 0005-Disable-more-of-test-out-of-memory-test.patch | Disable more of test-out-of-memory test | Rob Browning <rlb@defaultvalue.org> | no | 2018-02-21 | ||
| 0006-gc.test-after-gc-hook-mark-unresolved-on-failure-eve.patch | gc.test: after-gc-hook - mark unresolved on failure (everywhere) Previously this was done for just mips and mipsel, 59d9bcd468aab0d97d763595fd4e934044dc7590 "gc.test: after-gc-hook - mark unresolved on failure for mips(el)", and then fd4ba18bca1c6000fc0dd417a5b489e1ac60e0d9 "Fix gc.test "after-gc-hook gets called" failures" attempted to fix it upstream, but as of 2.2.6 it's failing again, this time on amd64, so just mark it as unresolved everywhere for now. |
Rob Browning <rlb@defaultvalue.org> | yes | debian upstream | 2019-09-01 | |
| 0007-Mark-test-out-of-memory-as-an-expected-failure-for-n.patch | Mark test-out-of-memory as an expected failure for now Since this test has been failing for a long time on various architectures, mark it as expected to fail for now so that we'll still run it and can see the results, but won't be blocked by it. There are known issues with the test upstream, and at least in some past cases it's been possible to reproduce the failure quickly by running test-suite/standalone/test-out-of-memory in a loop. |
Rob Browning <rlb@defaultvalue.org> | yes | debian upstream | 2018-02-20 |