| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| no_git_version | Don't check git tags for versioning | Michael R. Crusoe <michael.crusoe@gmail.com> | no | |||
| define_PATH_MAX.patch | Define PATH_MAX as it is done in cram/open_trace_file.c if not existent. The definition should be removed from this C file since the header file affects all three C files where this definition is used. |
Andreas Tille <tille@debian.org>, | no | debian | ||
| fPIC.patch | Build with -fPIC instead of -fpic It doesn't make a difference on x86, but is required for linking the library on s390x and sparc64. |
Adrian Bunk <bunk@debian.org> | no | |||
| testShebang.patch | Build with -fPIC instead of -fpic It doesn't make a difference on x86, but is required for linking the library on s390x and sparc64. |
Adrian Bunk <bunk@debian.org> | no | |||
| fix_float_precision | ppc64el float handling fix I dug a bit further and it looks like that sam_parse1() is actually generating a different value for the floats in question, so when they are loaded back for the comparison they are already screwed up because strtod() is used in float_to_le() and so also in u32_to_le(), which are inlined and float_to_le() takes a float and not a double as the first argument the use strtof() instead of strtod() in there looks the best, avoiding a truncation from double to float, which might cause precision issues, specially between different archs (like casts) plus optimization. So the following change fixed the issue for me. |
Gustavo Romero <gromero@linux.vnet.ibm.com> | no | |||
| cram_to_bam_export.patch | Exports the cram_to_bam function to support the sambamba package. | Roel Janssen <roel@gnu.org> | no | |||
| 273c5e76a1694aa2a13fd51c133abed2ef8ab4d3.patch | [PATCH] Variable name used in dlsym corrected. The hfile irods plugin depends on a constructed symbol name which was no longer being used. |
Andrew Whitwham <whitwham@users.noreply.github.com> | no | debian | 2020-09-30 |