Package: libdvdread / 4.2.0+20120521-2
Metadata
Package | Version | Patches format |
---|---|---|
libdvdread | 4.2.0+20120521-2 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
01 libdvdcss.patch | (download) |
src/dvd_input.c |
9 8 + 1 - 0 ! |
print information about the css readme. |
02 md5 symbols.patch | (download) |
src/md5.h |
9 9 + 0 - 0 ! |
Fixing symbol conflicts with other MD5 implementations (Closes: #522512). |
03 endian.patch | (download) |
src/bswap.h |
5 5 + 0 - 0 ! |
use correct endianess on big-endian machines (closes: #531621). |
04 version.patch | (download) |
src/dvdread/dvd_reader.h |
2 1 + 1 - 0 ! |
bumping version to match original upstream (closes: #532438). |
05 hurd.patch | (download) |
src/dvd_reader.c |
63 48 + 15 - 0 ! |
libdvdread FTBFS on hurd-i386 due to PATH_MAX usage, which is not defined on GNU/Hurd. The attached patch fixes these problems by using dynamic buffer allocation (Closes: #640803). |
06 descriptor.patch | (download) |
src/dvd_udf.c |
37 34 + 3 - 0 ! |
libdvdread is very likely to fail on discs/images that store their File System Descriptor at the end of the disc/image rather than at the beginning. This is due to the "strategy" libdvdread uses to find it: libdvdread scans sequentially from the beginning of the disc/image for the File System Descriptor and identifies it by a single byte tag. . Aside from wasting lots of time on discs/images that store their File System Descriptor at the end there is quite a good chance to stumble across a random data block that accidentally starts with this tag (and failing on it) before finding the real File System Descriptor. . As far as I can see, at least CDBurnerXP seems to (be able to) create such images - at least if my interpretation of the Implementation Identifier "NMS DVDProLib" is correct. . This... well, let's call it ugly hack fixes this by obtaining the File System Descriptor location from the Logical Volume Descriptor (Closes: #663512). |
07 vts tmapt.patch | (download) |
src/ifo_read.c |
2 1 + 1 - 0 ! |
Stifle the "Please send bug report - no VTS_TMAPT ??" message. Upstream indicates it's merely a warning and not an indication of a bug that needs reported (Closes: #281186, #281575, #316926, #541723). |
08 array.patch | (download) |
src/ifo_read.c |
6 6 + 0 - 0 ! |
In the file ifo_read.c, function ifoRead_TT_SRPT, where a structure array is allocated, but another variable, extracted from the DVD info determines the lenght of the array, resulting in read/writes beyond the array. I truncate the read, but perhaps a better solution would be to expand the malloc to include the data off the DVD. I believe that, however could lead to out of memory errors if the DVD data was bad/invalid. . With the applied patch, dvdbackup no longer segfaults (Closes: #649790). |