In bug #235712, user davide attached an ebuild for media-video/dvdbackup-0.4.1. This doesn't work out of the box with newer versions (i.e. >=4.1.3) of media-libs/libdvdread. http://dvdbackup.sourceforge.net/ hosts a patch to re-add the removed DVDFileStat functions to libdvdread-4.1.3. However, this patch needed slight modifications for 4.1.3_p1168. Find attached a diff to the current media-libs/libdvdread-4.1.3_p1168.ebuild and a working patch derived from the one on the dvdbackup site. Since it doesn't change functionality, but only adds some functions to the library, it shouldn't break compatibility to any other packages. Can this be included by default and the dvdbackup ebuild from bug #235712 finally added to portage? Best regards Torsten Reproducible: Always Steps to Reproduce:
Created attachment 212239 [details, diff] libdvdread-4.1.3_p1168.ebuild.patch
Created attachment 212241 [details, diff] libdvdread-4.1.3_p1168-DVDFileStat.patch
It might be just me, but that sounds very wrong. How long are we supposed to carry this patch in libdvdread around until this application (dvdbackup) which isn't even in Portage will work without them? I think your options are: a) convince mplayer devs to re-add the functions to libdvdread or b) patch dvdbackup to work without these functions from libdvdread I'd go with b)
(In reply to comment #3) > I'd go with b) That sounds reasonable. Anyhow, my knowledge of C is much less than sufficient to accomplish such patching... Any volunteers? ;-)
Update: I asked the dvdbackup developers about the possibilities of adapting to different versions of libdvdread. See https://answers.launchpad.net/dvdbackup/+question/93323
(In reply to comment #5) > Update: I asked the dvdbackup developers about the possibilities of adapting to > different versions of libdvdread. > > See https://answers.launchpad.net/dvdbackup/+question/93323 > I've found this on launchpad: „This question was expired because it remained in the 'Open' state without activity for the last 15 days.” Maybe just fill it as a bug there?
This should be taken upstream. It is not something we want to fix locally (meaning in Gentoo only).
