ports/134016: multimedia/libdvdread still needs libdvdcss to read encrypted DVDs
Josh Paetzel
jpaetzel at FreeBSD.org
Sun Apr 26 11:30:05 UTC 2009
>Number: 134016
>Category: ports
>Synopsis: multimedia/libdvdread still needs libdvdcss to read encrypted DVDs
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Apr 26 11:30:04 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator: Josh Paetzel
>Release: 7.1-RELEASE
>Organization:
>Environment:
FreeBSD 7.1-RELEASE #0: The Jan 1 14:37:25 UTC 2009 root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
>Description:
Previous to the import of mplayer's libdvdread to multimedia/libdvdread the libdvdread depended on multimedia/libdvdcss to read encrypted DVDs, and that dependancy was hard wired in to the port. After the import, the dependancy vanished completely.
My assumption was the libdvdread project had somehow internalized the decrypting of DVDs, but it turns out this is not the case. It still needs libdvdcss, and builds against it if it is there. This was exposed by the shared library bump that the new version of libdvdcss underwent.
I also went ahead and duped maintainership of multimedia/libdvdread and set it for removal, since it apparently had no more uses. I'll be reversing that, we also need to figure out a way to make this a dependancy again, as well as sort out the shared library bump.
I suggest making it an OPTION, but I'm torn on whether it should default to on or off.
I'll be sending patches later today.
>How-To-Repeat:
Attempt to read an encrypted DVD using anything that depends on libdvdread without having it built against libdvdcss
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list