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 file
Patch File delta Description
01 libdvdcss.patch | (download)

src/dvd_input.c | 9 8 + 1 - 0 !
1 file changed, 8 insertions(+), 1 deletion(-)

 print information about the css readme.

02 md5 symbols.patch | (download)

src/md5.h | 9 9 + 0 - 0 !
1 file changed, 9 insertions(+)

 Fixing symbol conflicts with other MD5 implementations (Closes: #522512).

03 endian.patch | (download)

src/bswap.h | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 use correct endianess on big-endian machines (closes: #531621).

04 version.patch | (download)

src/dvdread/dvd_reader.h | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 bumping version to match original upstream (closes: #532438).

05 hurd.patch | (download)

src/dvd_reader.c | 63 48 + 15 - 0 !
1 file changed, 48 insertions(+), 15 deletions(-)

 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 !
1 file changed, 34 insertions(+), 3 deletions(-)

 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 !
1 file changed, 1 insertion(+), 1 deletion(-)

 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 !
1 file changed, 6 insertions(+)

 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).