Feature #7674

Allow users to watch CSS protected DVDs

Added by cypherpunks almost 3 years ago. Updated over 1 year ago.

Status:ResolvedStart date:07/28/2014
Priority:LowDue date:
Assignee:-% Done:

100%

Category:Hardware support
Target version:Tails_2.2
QA Check:Pass Blueprint:
Feature Branch:feature/7674-libdvdcss2 Easy:No
Type of work:Code Affected tool:

Description

To watch a DVD on Tails, one must either have the luck of using only unencrypted DVDs or they must have the luck of knowing how to install the following packages: https://www.videolan.org/vlc/download-debian.html

I'd like to see libdvdcss ship with Tails.

Users currently download random .deb files and install them on Tails to watch DVDs. This is dangerous.

0001-add-libdvdcss2-to-tails.patch Magnifier (2.7 KB) hybridwipe, 02/11/2016 09:21 PM


Related issues

Blocked by Tails - Bug #10455: Totem cannot access DVD readers Resolved 10/29/2015

History

#1 Updated by intrigeri almost 3 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from Allow users to watch (nearly all) DVDs to Allow users to watch CSS protected DVDs
  • Status changed from New to Confirmed
  • Priority changed from Normal to Low

#2 Updated by BitingBird over 2 years ago

libdvdcss is not in Debian (legal issues).

#3 Updated by hybridwipe almost 2 years ago

There is source available from videolan.org to compile it yourself:
http://download.videolan.org/pub/libdvdcss/last/

would it be acceptable to build/package it within tails?

#4 Updated by intrigeri almost 2 years ago

There is source available from videolan.org to compile it yourself: [...]

That's the upstream source code. There's something more interesting (a Debian source package) on https://www.videolan.org/developers/libdvdcss.html.

would it be acceptable to build/package it within tails?

It might be acceptable to build our own binary package from the aforementioned source package, and ship it in Tails. Perhaps start a discussion on tails-dev@ about it before putting too much time into it?

#5 Updated by intrigeri almost 2 years ago

  • Type of work changed from Debian to Discuss

Next step is to make a policy decision.

#6 Updated by intrigeri almost 2 years ago

Implementation wise: https://tracker.debian.org/pkg/libdvd-pkg should help.

#7 Updated by intrigeri almost 2 years ago

  • Status changed from Confirmed to In Progress
  • Assignee set to hybridwipe
  • % Done changed from 0 to 10

#8 Updated by hybridwipe almost 2 years ago

  • File patch added
  • Category set to Hardware support
  • Type of work changed from Discuss to Code

Initial patch attached. I haven't figured out why libdvdcss keeps getting purged.

#9 Updated by intrigeri almost 2 years ago

  • Assignee changed from hybridwipe to intrigeri
  • QA Check set to Ready for QA

#10 Updated by intrigeri almost 2 years ago

  • Assignee changed from intrigeri to hybridwipe
  • Target version set to Tails_1.7
  • QA Check changed from Ready for QA to Dev Needed

Initial patch attached.

Thanks! Note that your patch contains unrelated changes, such as commenting ./build-wiki.

Here's an initial review:

  • First of all: great job, it looks clean and one can see that you've put quite some thinking into it. Congrats!
  • Why install the package from sid, while it's in testing?
  • Why do we fetch and verify the tarball ourselves? Isn't it precisely the purpose of libdvd-pkg?
  • What's the purpose of dpkg-reconfigure --force libdvd-pkg?
  • The various http_proxy environment variables should already be exported in the environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I haven't figured out why libdvdcss keeps getting purged.

I'm not sure what you mean here exactly. Perhaps seeing the relevant parts of a build log would help me understand.

#11 Updated by hybridwipe almost 2 years ago

  • File tails-i386-devel-1.7-20150811.iso.buildlog added

intrigeri wrote:

Initial patch attached.

Thanks! Note that your patch contains unrelated changes, such as commenting ./build-wiki.

Here's an initial review:

  • First of all: great job, it looks clean and one can see that you've put quite some thinking into it. Congrats!
  • Why install the package from sid, while it's in testing?

No strong reason, they ship the same version of the package, simple enough to change.

  • Why do we fetch and verify the tarball ourselves? Isn't it precisely the purpose of libdvd-pkg?

I started by simply adding libdvd-pkg to config/chroot_local-packageslists/tails-common.list, but that doesn't work. I later get a failure like:
libdvd-pkg: Downloading orig source...
I: libdvdcss_1.3.99
wget --tries=3 --timeout=40 --read-timeout=40 --continue -O libdvdcss_1.3.99.orig.tar.bz2 \
http://download.videolan.org/pub/libdvdcss/1.3.99/libdvdcss-1.3.99.tar.bz2 \ || uscan --noconf --verbose --rename --destdir=/usr/src/libdvd-pkg --check-dirname-level=0 --force-download --download-current-version /usr/share/libdvd-pkg/debian
--2015-08-11 08:37:00-- http://download.videolan.org/pub/libdvdcss/1.3.99/libdvdcss-1.3.99.tar.bz2
Resolving download.videolan.org (download.videolan.org)... [Aug 11 08:37:00] PERROR torsocks16354: socks5 libc connect: Connection refused (in socks5_connect() at socks5.c:185)
failed: Non-recoverable failure in name resolution.
wget: unable to resolve host address `download.videolan.org'
/bin/sh: 3: uscan: not found
make: *** [get-orig-source] Error 127

  • What's the purpose of dpkg-reconfigure --force libdvd-pkg?

It should attempt to build libdvdcss and install it (once the source package is in place), as those steps can't run while dpkg is locked (e.g., when installing libdvd-pkg as a group of other packages).

  • The various http_proxy environment variables should already be exported in the environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I was confused by that not working as well, this solution was based on the tbb solution, as I would've expected just to add libdvd-pkg to tails-common.list along with a pinning override, but that didn't work.

I haven't figured out why libdvdcss keeps getting purged.

I'm not sure what you mean here exactly. Perhaps seeing the relevant parts of a build log would help me understand.

Sure, I'll attach the full log, but you can see here that libdvd-pkg/libdvdcss2 are installed:
Setting up libdvd-pkg (1.3.99-1-1) ...
libdvd-pkg: dpkg database is locked. You may need to use command "sudo dpkg-reconfigure libdvd-pkg".
libdvd-pkg: Building and installation of package(s) [libdvdcss2 libdvdcss-dev] postponed till after next APT operation.
+ dpkg-reconfigure --force libdvd-pkg
libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.3.99.orig.tar.bz2: OK
libdvd-pkg: Unpacking and configuring...
libdvd-pkg: Building the package... (it may take a while)
libdvd-pkg: Build log will be saved to /usr/src/libdvd-pkg/libdvdcss2_1.3.99-1~local_i386.build
libdvd-pkg: Installing...
Selecting previously unselected package libdvdcss-dev:i386.
(Reading database ... 159861 files and directories currently installed.)
Unpacking libdvdcss-dev:i386 (from .../libdvdcss-dev_1.3.99-1~local_i386.deb) ...
Selecting previously unselected package libdvdcss2:i386.
Unpacking libdvdcss2:i386 (from .../libdvdcss2_1.3.99-1~local_i386.deb) ...
Setting up libdvdcss2:i386 (1.3.99-1~local) ...
Setting up libdvdcss-dev:i386 (1.3.99-1~local) ...
+ apt-get --yes install libdvdcss2
Reading package lists...
Building dependency tree...
Reading state information...
libdvdcss2 is already the newest version.

shortly after that:
The following packages will be REMOVED:
build-essential* debhelper* dh-autoreconf* dkms* dpatch* dpkg-dev* equivs*
g++* g++-4.7* gcc* gcc-4.7* gcc-4.8* intltool-debian* libc6-dev* libdvd-pkg*
libdvdcss-dev* libdvdcss2* libstdc++6-4.7-dev* libtool*
linux-compiler-gcc-4.8-x86* linux-headers-3.16.0-4-586*
linux-headers-3.16.0-4-amd64* linux-headers-3.16.0-4-common*
linux-kbuild-3.16* linux-libc-dev* make* po-debconf* virtualbox-guest-dkms*
0 upgraded, 0 newly installed, 28 to remove and 0 not upgraded.

then looking at the final package list, no libdvd{cssdvd,-pkg}:
austin@debian-laptop:~/src/tails$ grep libdvd *packages
libdvdnav4 4.2.0+20120524-2
libdvdread4 4.2.0+20120521-2

#12 Updated by intrigeri almost 2 years ago

Hi again,

sorry for the delay, I was busy at DebConf.

Thanks! Note that your patch contains unrelated changes, such as commenting ./build-wiki.

Please address this one in your next iteration.

  • Why install the package from sid, while it's in testing?

No strong reason, they ship the same version of the package, simple enough to change.

OK => please do it (preferably in a Git branch, so that it's easier for me to track what additional changes you made on top of your initian patch).

  • Why do we fetch and verify the tarball ourselves? Isn't it precisely the purpose of libdvd-pkg?

I started by simply adding libdvd-pkg to config/chroot_local-packageslists/tails-common.list, but that doesn't work. I later get a failure like:
[...]
Resolving download.videolan.org (download.videolan.org)... [Aug 11 08:37:00] PERROR torsocks16354: socks5 libc connect: Connection refused (in socks5_connect() at socks5.c:185)

I don't understand why we see torsocks errors in there. How exactly are you building the ISO? Are you adding torsocks to the loop yourself? If yes, then I suspect that it's causing this build failure.

  • What's the purpose of dpkg-reconfigure --force libdvd-pkg?

It should attempt to build libdvdcss and install it (once the source package is in place), as those steps can't run while dpkg is locked (e.g., when installing libdvd-pkg as a group of other packages).

My understanding is that this should not happen if libdvd-pkg/post-invoke_hook-install is set to true in debconf (in this case, an APT hook is installed to run this automatically once apt-get is done). Maybe try preseeding it?

  • The various http_proxy environment variables should already be exported in the
    environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I was confused by that not working as well, this solution was based on the tbb solution, as I would've expected just to add libdvd-pkg to tails-common.list along with a pinning override, but that didn't work.

I see that firmware-b43-installer.postinst explicitly fetches APT's proxy configuration. IMO libdvd-pkg should simply do the same => please file a bug against the Debian package about it, preferably with a patch attached.

I haven't figured out why libdvdcss keeps getting purged.

I'm not sure what you mean here exactly. Perhaps seeing the relevant parts of a build log would help me understand.

shortly after that:
The following packages will be REMOVED:
build-essential* debhelper* dh-autoreconf* dkms* dpatch* dpkg-dev* equivs*
g++* g++-4.7* gcc* gcc-4.7* gcc-4.8* intltool-debian* libc6-dev* libdvd-pkg*
libdvdcss-dev* libdvdcss2* libstdc++6-4.7-dev* libtool*
linux-compiler-gcc-4.8-x86* linux-headers-3.16.0-4-586*
linux-headers-3.16.0-4-amd64* linux-headers-3.16.0-4-common*
linux-kbuild-3.16* linux-libc-dev* make* po-debconf* virtualbox-guest-dkms*
0 upgraded, 0 newly installed, 28 to remove and 0 not upgraded.

libdvd-pkg depends on build-essential, that we explicitly remove, so it's fully expected that libdvd-pkg is removed. That's not a problem in itself, is it?

The problem is that the generated package depends on libdvd-pkg, so to prevent its removal from also removing the generated package, we need to 1. install libdvd-pkg; 2. let it do its job; 3. replace it with an equivs-generated fake package that satisfies the dependency from the generated package on libdvd-pkg => and then, libdvd-pkg can be removed while leaving the generated libdvdcss2 package installed. OK?

#13 Updated by hybridwipe almost 2 years ago

intrigeri wrote:

Hi again,

sorry for the delay, I was busy at DebConf.

Thanks! Note that your patch contains unrelated changes, such as commenting ./build-wiki.

Please address this one in your next iteration.

Ok.

  • Why install the package from sid, while it's in testing?

No strong reason, they ship the same version of the package, simple enough to change.

OK => please do it (preferably in a Git branch, so that it's easier for me to track what additional changes you made on top of your initian patch).

Requested one.

  • Why do we fetch and verify the tarball ourselves? Isn't it precisely the purpose of libdvd-pkg?

I started by simply adding libdvd-pkg to config/chroot_local-packageslists/tails-common.list, but that doesn't work. I later get a failure like:
[...]
Resolving download.videolan.org (download.videolan.org)... [Aug 11 08:37:00] PERROR torsocks16354: socks5 libc connect: Connection refused (in socks5_connect() at socks5.c:185)

I don't understand why we see torsocks errors in there. How exactly are you building the ISO? Are you adding torsocks to the loop yourself? If yes, then I suspect that it's causing this build failure.

No, I'm simply running rake build.

  • What's the purpose of dpkg-reconfigure --force libdvd-pkg?

It should attempt to build libdvdcss and install it (once the source package is in place), as those steps can't run while dpkg is locked (e.g., when installing libdvd-pkg as a group of other packages).

My understanding is that this should not happen if libdvd-pkg/post-invoke_hook-install is set to true in debconf (in this case, an APT hook is installed to run this automatically once apt-get is done). Maybe try preseeding it?

K.

  • The various http_proxy environment variables should already be exported in the
    environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I was confused by that not working as well, this solution was based on the tbb solution, as I would've expected just to add libdvd-pkg to tails-common.list along with a pinning override, but that didn't work.

I see that firmware-b43-installer.postinst explicitly fetches APT's proxy configuration. IMO libdvd-pkg should simply do the same => please file a bug against the Debian package about it, preferably with a patch attached.

Okay.

I haven't figured out why libdvdcss keeps getting purged.

I'm not sure what you mean here exactly. Perhaps seeing the relevant parts of a build log would help me understand.

shortly after that:
The following packages will be REMOVED:
build-essential* debhelper* dh-autoreconf* dkms* dpatch* dpkg-dev* equivs*
g++* g++-4.7* gcc* gcc-4.7* gcc-4.8* intltool-debian* libc6-dev* libdvd-pkg*
libdvdcss-dev* libdvdcss2* libstdc++6-4.7-dev* libtool*
linux-compiler-gcc-4.8-x86* linux-headers-3.16.0-4-586*
linux-headers-3.16.0-4-amd64* linux-headers-3.16.0-4-common*
linux-kbuild-3.16* linux-libc-dev* make* po-debconf* virtualbox-guest-dkms*
0 upgraded, 0 newly installed, 28 to remove and 0 not upgraded.

libdvd-pkg depends on build-essential, that we explicitly remove, so it's fully expected that libdvd-pkg is removed. That's not a problem in itself, is it?

The problem is that the generated package depends on libdvd-pkg, so to prevent its removal from also removing the generated package, we need to 1. install libdvd-pkg; 2. let it do its job; 3. replace it with an equivs-generated fake package that satisfies the dependency from the generated package on libdvd-pkg => and then, libdvd-pkg can be removed while leaving the generated libdvdcss2 package installed. OK?

Ok.

#14 Updated by hybridwipe almost 2 years ago

hybridwipe wrote:

intrigeri wrote:

  • The various http_proxy environment variables should already be exported in the
    environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I was confused by that not working as well, this solution was based on the tbb solution, as I would've expected just to add libdvd-pkg to tails-common.list along with a pinning override, but that didn't work.

I see that firmware-b43-installer.postinst explicitly fetches APT's proxy configuration. IMO libdvd-pkg should simply do the same => please file a bug against the Debian package about it, preferably with a patch attached.

Okay.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

#15 Updated by hybridwipe almost 2 years ago

hybridwipe wrote:

hybridwipe wrote:

intrigeri wrote:

  • The various http_proxy environment variables should already be exported in the
    environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I was confused by that not working as well, this solution was based on the tbb solution, as I would've expected just to add libdvd-pkg to tails-common.list along with a pinning override, but that didn't work.

I see that firmware-b43-installer.postinst explicitly fetches APT's proxy configuration. IMO libdvd-pkg should simply do the same => please file a bug against the Debian package about it, preferably with a patch attached.

Okay.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

The bug was closed as WONTFIX, with the suggestion that we configure a proxy that works for wget.

#16 Updated by hybridwipe almost 2 years ago

hybridwipe wrote:

hybridwipe wrote:

hybridwipe wrote:

intrigeri wrote:

  • The various http_proxy environment variables should already be exported in the
    environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I was confused by that not working as well, this solution was based on the tbb solution, as I would've expected just to add libdvd-pkg to tails-common.list along with a pinning override, but that didn't work.

I see that firmware-b43-installer.postinst explicitly fetches APT's proxy configuration. IMO libdvd-pkg should simply do the same => please file a bug against the Debian package about it, preferably with a patch attached.

Okay.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

The bug was closed as WONTFIX, with the suggestion that we configure a proxy that works for wget.

I dug into this more, and the problem is that in config/chroot_local-includes/usr/local/bin/wget, /usr/bin/wget is replaced with a torsocks wrapper, which explains the error:
Resolving download.videolan.org (download.videolan.org)... [Aug 31 19:19:45] PERROR torsocks5439: socks5 libc connect: Connection refused (in socks5_connect() at socks5.c:185)

that was done for Feature #6623. We don't do that to curl, which continues to work. Obviously it's not worth potentially compromising users to remove that wrapper. So afaict, our options are to have upstream use curl, or curl it ourselves like we do tbb.

I'm open to other ideas.

#17 Updated by hybridwipe almost 2 years ago

hybridwipe wrote:

hybridwipe wrote:

hybridwipe wrote:

intrigeri wrote:

  • The various http_proxy environment variables should already be exported in the
    environment at this point (e.g. they're already used transparently by firmware-b43-installer), so I don't think you need to get them from Acquire::http::Proxy.

I was confused by that not working as well, this solution was based on the tbb solution, as I would've expected just to add libdvd-pkg to tails-common.list along with a pinning override, but that didn't work.

I see that firmware-b43-installer.postinst explicitly fetches APT's proxy configuration. IMO libdvd-pkg should simply do the same => please file a bug against the Debian package about it, preferably with a patch attached.

Okay.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

The bug was closed as WONTFIX, with the suggestion that we configure a proxy that works for wget.

An alternate patch was accepted:
https://anonscm.debian.org/cgit/pkg-multimedia/libdvd-pkg.git/commit/?id=f777c54

as a workaround, doing export PATH="/usr/bin:$PATH" before dpkg-reconfigure also works. I'll push a branch soon somewhere that has libdvdcss2 support, with an important caveat: totem doesn't work for me. Installing vlc from (not in this branch), however, does work.

That's a separate issue, I think.

#18 Updated by hybridwipe almost 2 years ago

Okay. Here's the cleaned up patchset. I emailed tails-sysadmins but never got a reply, so I pushed to github instead:
https://github.com/austin987/tails/compare/7674-libdvdcss2

totem complains that it can't read the DVD (though vlc can just fine), saying permissions are wrong. Doing a sudo chmod 777 /dev/sr0 gets it slightly further, then complaining that it can't decode the DVD and requesting that I ensure that I have libdvdcss2 installed.

The second patch is for testing that libdvdcss works, it is not meant to be committed as is. I think VLC should certainly be considered, given that it is IMO much more flexible and featureful than totem, though it may have security implications/etc.

I tried pre-seeding apt's config, but it didn't make a difference, an explicit dpkg-reconfigure is required. Furthermore, the $PATH hack can be removed whenever an updated libdvd-pkg is packaged upstream.

#19 Updated by intrigeri almost 2 years ago

I emailed tails-sysadmins but never got a reply

Sorry about that. We're busy and such requests can sometimes take a week or so to be processed.

so I pushed to github instead:

That's fine.

Now, please read https://tails.boum.org/contribute/merge_policy/#submit to learn how to let reviewers know that they should look at your work :)

#20 Updated by hybridwipe almost 2 years ago

  • Assignee deleted (hybridwipe)
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to feature/7674-libdvdcss2

#21 Updated by intrigeri almost 2 years ago

anonym, please take this one, and feel free to ask me about any crazy Debian bits that you might not be 100% confident about.

#22 Updated by intrigeri almost 2 years ago

  • Assignee set to hybridwipe
  • QA Check changed from Ready for QA to Info Needed

hybridwipe wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

The bug was closed as WONTFIX, with the suggestion that we configure a proxy that works for wget.

Sad, but well. I thought we already exported http_proxy into the build environment, don't we?

#23 Updated by hybridwipe over 1 year ago

intrigeri wrote:

hybridwipe wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

The bug was closed as WONTFIX, with the suggestion that we configure a proxy that works for wget.

Sad, but well. I thought we already exported http_proxy into the build environment, don't we?

I don't know enough about Tails' build system to answer that question. What I can say is that I do not run any HTTP proxy explicitly when building tails, and libdvdcss fails without some hack (either manually bundling the upstream tarball, or a $PATH hack). The patch I sent upstream should take care of it, when that is packaged upstream (but who knows how long that will take).

That said, I made a fix for the wget/FTP IP address leak that also takes care of this problem. See #10364. With that fix applied, I don't need any hacks, building works (again, without manually configuring a proxy).

#24 Updated by intrigeri over 1 year ago

  • Feature Branch changed from feature/7674-libdvdcss2 to https://github.com/austin987/tails/tree/feature/7674-libdvdcss2

#25 Updated by intrigeri over 1 year ago

  • QA Check changed from Info Needed to Dev Needed

We've missed the merge window for next major release, mainly because the ticket metadata was wrong (it's still assigned to you so others won't notice they should be acting on it — please read the contributors doc I've pointed you at) => this will have to wait for Tails 1.9 in three months => IMO we should ensure the Debian package is updated by then (ask the maintainer for an ETA, let them know that we're waiting, maybe propose help) and be prepared to drop the PATH hack. Thanks for your contribution to Debian.

I had a look at the branch and it's getting much better!

It would be good to do the work in a temporary directory. See other hooks that use equivs for inspiration :)

We're lucky that Stretch's libdvdnav4 and libdvdread4 work as-is on Wheezy. Isn't the version from wheezy-backports good enough?

I would remove libdvdcss-dev in the same hook that installs it, so that it's a bit more self-contained.

Lastly, the replacement of Totem with VLC has nothing to do in this branch, please revert it (I would normally add "and start the discussion somewhere relevant" but it's been asked so often that it looking for answers should be easy). I think the "Totem can't play DVDs" issues is probably caused by AppArmor. Can you please check and report a dedicated bug if this is confirmed?

#26 Updated by hybridwipe over 1 year ago

  • File add-libdvdcss2-to-tails.patch added

intrigeri wrote:

We've missed the merge window for next major release, mainly because the ticket metadata was wrong (it's still assigned to you so others won't notice they should be acting on it — please read the contributors doc I've pointed you at) => this will have to wait for Tails 1.9 in three months => IMO we should ensure the Debian package is updated by then (ask the maintainer for an ETA, let them know that we're waiting, maybe propose help) and be prepared to drop the PATH hack. Thanks for your contribution to Debian.

Actually, now that b9fd6312435d55dd0bc0b6abdb7994da4d66e2b2 is in, the PATH hack is no longer needed (nor is the updated package needed either).

I had a look at the branch and it's getting much better!

It would be good to do the work in a temporary directory. See other hooks that use equivs for inspiration :)

Actually, I had looked at others which is where I got that from ;) (see 50-virtualbox, I may send a patch for that soonish). Anyway, fixed in this revision.

We're lucky that Stretch's libdvdnav4 and libdvdread4 work as-is on Wheezy. Isn't the version from wheezy-backports good enough?

I'm not sure if it was in wheezy-backports when I first looked at this, but yes, this version works as well.

I would remove libdvdcss-dev in the same hook that installs it, so that it's a bit more self-contained.

Sure, good idea.

Lastly, the replacement of Totem with VLC has nothing to do in this branch, please revert it (I would normally add "and start the discussion somewhere relevant" but it's been asked so often that it looking for answers should be easy). I think the "Totem can't play DVDs" issues is probably caused by AppArmor. Can you please check and report a dedicated bug if this is confirmed?

Thanks for the suggestion, AppArmor is indeed the cause. sudo /etc/init.d/apparmor teardown lets Totem play the DVD. I filed #10455 for that.

#27 Updated by hybridwipe over 1 year ago

  • Assignee changed from hybridwipe to intrigeri

#28 Updated by intrigeri over 1 year ago

  • Blocked by Bug #10455: Totem cannot access DVD readers added

#29 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_1.7 to 246

It would be nice to either update the Git branch (best), or empty the "feature branch" field (why not, but really, attached patches are OK'ish for easy changes that one gets right at first try, but we're not at it anymore here).

Also, please read https://tails.boum.org/contribute/merge_policy/#submit :)

#30 Updated by intrigeri over 1 year ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Dev Needed to Ready for QA

(anonym: don't blindly trust the feature branch field.)

#31 Updated by hybridwipe over 1 year ago

  • Feature Branch deleted (https://github.com/austin987/tails/tree/feature/7674-libdvdcss2)

#32 Updated by sajolida over 1 year ago

  • Target version changed from 246 to Tails_2.0

#33 Updated by intrigeri over 1 year ago

  • Assignee set to anonym

(A month after submission of the latest patch, explicitly putting on the RM's plate.)

#34 Updated by hybridwipe over 1 year ago

  • File 0633-feature-7674-add-libdvdcss-support-to-tails-allows-w.patch added

I rediffed my patch against the current feature/jessie branch (at 237e8ef06e5b78fbb4cff5ef44dd3a07d272ff04).

Now that #10455 is fixed, this patch is all that is needed for Tails to play DVDs in Totem. Currently watching one now ;)

#35 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_2.0 to Tails_2.2

Yay!

(The feature freeze for Tails 2.0 was a few days ago.)

#36 Updated by hybridwipe over 1 year ago

FWIW the wget > /usr/bin/wget fix is now fixed upstream in Debian:
https://tracker.debian.org/news/738022
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

that's libdvd-pkg-1.4.0-1-1. We aren't affected anymore now that we've removed the /usr/local/bin/wget wrapper.

@anonym, have you had any time to look at this?

#37 Updated by anonym over 1 year ago

  • Assignee changed from anonym to hybridwipe
  • QA Check changed from Ready for QA to Dev Needed

hybridwipe wrote:

FWIW the wget > /usr/bin/wget fix is now fixed upstream in Debian:
https://tracker.debian.org/news/738022
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797113

that's libdvd-pkg-1.4.0-1-1. We aren't affected anymore now that we've removed the /usr/local/bin/wget wrapper.

@anonym, have you had any time to look at this?

Sorry, I apparently didn't. :(

I do not know why, but the attached file is missing from Redmine (clicking the link => 404). Could you please upload the patch again? This time I promise to look at it ASAP.

BTW, you may want to consider hosting your Git repo somewhere (Git labs, Bitbucket, whatever) so you can send pull requests that way. It just fits the reviewers' workflow better, and works a lot better for conributions of >1 commits. Just a thought, but this is of course not a requirement, so if you feel it would hinder you in any way, definitely do not bother for this patch at least. :)

#38 Updated by hybridwipe over 1 year ago

Rebased patch for jessie. I'm unable to test, build fails with vagrant issues for me:
austin@debian-laptop:~/src/tails$ rake build
rake aborted!
LoadError: cannot load such file -- vagrant
/home/austin/src/tails/Rakefile:23:in `<top (required)>'
(See full trace by running task with --trace)

Also pushed here:
https://git-tails.immerda.ch/hybridwipe/tails/?h=feature/7674-libdvdcss2

#39 Updated by hybridwipe over 1 year ago

  • File deleted (0633-feature-7674-add-libdvdcss-support-to-tails-allows-w.patch)

#40 Updated by hybridwipe over 1 year ago

  • File deleted (tails-i386-devel-1.7-20150811.iso.buildlog)

#41 Updated by hybridwipe over 1 year ago

  • File deleted (patch)

#42 Updated by hybridwipe over 1 year ago

  • File deleted (add-libdvdcss2-to-tails.patch)

#43 Updated by anonym over 1 year ago

  • % Done changed from 10 to 40

Thanks for your contribution! Here's a review:

--- a/config/chroot_apt/preferences
+++ b/config/chroot_apt/preferences
...

Do we actually need these pinnings any more? By default we already pin packages from Jessie higher than any other dist.

+++ b/config/chroot_local-hooks/59-libdvd-pkg
...
+set -x

While useful for debugging, let's not put set -x into production.

+local tmp

You cannot use local in the global scope, only inside functions. This currently causes a fatal error.

  1. Create and install fake libdvd-pkg package

Please expand add an explanation why we need to do this. If I understand it correctly it's so we later can remove build-essential, which libdvd-pkg depends on, while still providing for libdvdcss2. That's not so obvious when just reading this script, and surprised me. :)

+Package: libdvd-pkg-${LIBDVD_PKG_VERSION}

So we create a package with the version included in the name. If we really want that we'd have to sanitize it, cause versions can include characters not allowed in package names, which currently is the case and causes a fatal error. I think I'd prefer something like:

LIBDVD_PKG_VERSION="$(dpkg-query -s libdvd-pkg | grep Version | cut -d ' ' -f2)+fake1" 
...
Package: libdvd-pkg
Version: ${LIBDVD_PKG_VERSION}
...
dpkg -i "${tmp}/libdvd-pkg_${LIBDVD_PKG_VERSION}_all.deb" 
...

Then you can also drop the Provides field.

+cd "${tmp}"
...
+cd -

IMHO a better pattern is to do the change of directory and the operations needing it in a sub-shell:

(
    cd "${tmp}" 
    ... stuff to be done inside ${tmp} ...
)

This is safe as long as we don't need to modify the original shell (e.g. store something in a variable) which we do not in this case.

Sorry for the less than optimal state of Vagrant. :/ I'll email you about this and perhaps we can solve it. I realize that it'll be hard to test your changes without being able to build Tails but hopefully we can

#44 Updated by hybridwipe over 1 year ago

anonym wrote:

Thanks for your contribution! Here's a review:

--- a/config/chroot_apt/preferences
+++ b/config/chroot_apt/preferences
...

Do we actually need these pinnings any more? By default we already pin packages from Jessie higher than any other dist.

Probably not then, thanks for tip. I changed when rebasing to devel (previously it was wheezy-backports).

+++ b/config/chroot_local-hooks/59-libdvd-pkg
...
+set -x

While useful for debugging, let's not put set -x into production.

OK.

+local tmp

You cannot use local in the global scope, only inside functions. This currently causes a fatal error.

Thanks.

  1. Create and install fake libdvd-pkg package

Please expand add an explanation why we need to do this. If I understand it correctly it's so we later can remove build-essential, which libdvd-pkg depends on, while still providing for libdvdcss2. That's not so obvious when just reading this script, and surprised me. :)

Correct. Comment added.

+Package: libdvd-pkg-${LIBDVD_PKG_VERSION}

So we create a package with the version included in the name. If we really want that we'd have to sanitize it, cause versions can include characters not allowed in package names, which currently is the case and causes a fatal error. I think I'd prefer something like:

[...]

Then you can also drop the Provides field.

OK.

+cd "${tmp}"
...
+cd -

IMHO a better pattern is to do the change of directory and the operations needing it in a sub-shell:
[...]
This is safe as long as we don't need to modify the original shell (e.g. store something in a variable) which we do not in this case.

Sure, good point.

Sorry for the less than optimal state of Vagrant. :/ I'll email you about this and perhaps we can solve it. I realize that it'll be hard to test your changes without being able to build Tails but hopefully we can

Thanks. I'd very much like to be able to build again. I've got some other stuff I want to work on that would definitely require building to write/test :).

All changes were pushed to feature branch (as separate commits).

#45 Updated by intrigeri over 1 year ago

  • Assignee changed from hybridwipe to anonym
  • QA Check changed from Dev Needed to Ready for QA

#46 Updated by anonym over 1 year ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 40 to 50
  • Feature Branch changed from https://git-tails.immerda.ch/hybridwipe/tails/?h=feature/7674-libdvdcss2 to feature/7674-libdvdcss2

Thanks again, hybridwipe!

I tried your branch, and it didn't build, so I pushed two fixes (one for something I already mentioned, the local declaration; one thing that was fixed in the code examples I provided above) for that and some style fixes, see the new feature branch. Now that you have a working build system (right?) I hope you can test your changes in the future! :)

Despite my fixes, there are still issues:

1. When I try to play a DVD in Totem I get no sound. If run in a terminal I can see this error:

** Message: Missing plugin: gstreamer|1.0|totem|DVD AC-3 (ATSC A/52) decoder|decoder-audio/x-private1-ac3 (DVD AC-3 (ATSC A/52) decoder)
** Message: Automatic missing codec installation not supported (helper script missing)

Installing gstreamer1.0-plugins-ugly removes the error message and enables sound. Note that we are installing the gstreamer0.1 variant of this package. Hmm. Perhaps we actually should switch to 1.0, or do we explicitly depend on the 0.1 packages still?

2. While installing that package I noticed this in the apt-get install output:

N: Ignoring '88libdvdcss-pkg' in directory '/etc/apt/apt.conf.d/' as it is not a regular file

and indeed,
$ ls -l /etc/apt/apt.conf.d/88libdvdcss-pkg
lrwxrwxrwx 1 root root 35 Feb 23 14:29 /etc/apt/apt.conf.d/88libdvdcss-pkg -> /usr/lib/libdvd-pkg/88libdvdcss-pkg

$ ls -l /usr/lib/libdvd-pkg/88libdvdcss-pkg
ls: cannot access /usr/lib/libdvd-pkg/88libdvdcss-pkg: No such file or directory

I guess that symlink should be removed. In any case, we do not want the out-of-APT automated update crap it provides.

So, I actually do not think this branch is completely ready for inclusion in Tails 2.2 but I do not want to discourage you by having to wait another 3 months, until the next major Tails release, so I'll give this a try any will merge it for the 2.2 RC any way with even more fixes (yes, I changed my mind about this while writing this comment). :) Worst case, we revert the merge for the final release of 2.2, but let's make that not happen!

intrigeri, can you please review (probably after 2.2~rc1, but before 2.2 final) my commits:

6cb3565 Remove illegal 'local' in shell script.
0fe243c Reformat comment.
316b414 Lessen scope of subshell invocation.
0226644 Drop unnecessary 'cd' (due to subshell).
2b04e17 Fix paths and cleanup in subshell invocation.
87a0014 Remove dangling symlink left by the libdvd-pkg package.
39dd882 Install gstreamer1.0-plugins-ugly for audio during DVD playback.

#47 Updated by anonym over 1 year ago

  • % Done changed from 50 to 80

Merged! Let's hope there are no remaining issues.

#48 Updated by hybridwipe over 1 year ago

anonym wrote:

Thanks again, hybridwipe!

I tried your branch, and it didn't build, so I pushed two fixes (one for something I already mentioned, the local declaration; one thing that was fixed in the code examples I provided above) for that and some style fixes, see the new feature branch. Now that you have a working build system (right?) I hope you can test your changes in the future! :)

Yes, I do. The recent build fixes broke it again, but that's now resolved with a different ruby-net-ssh (2.9.1-1).

If there are future issues with this I'll take a look. The patch was tested and working OOB on wheezy, but since I wasn't able to build jessie until recently, I couldn't prevent the bitrotting.

#49 Updated by intrigeri over 1 year ago

  • Assignee changed from intrigeri to anonym

intrigeri, can you please review (probably after 2.2~rc1, but before 2.2 final) my commits:

I'll try, but my plate is already seriously too full wrt. "what I have to do before 2.2 final", so I would appreciate if you asked other people.

#50 Updated by anonym over 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 80 to 100
  • QA Check changed from Ready for QA to Pass

Now it's in Tails 2.2, so no reason to keep it open any longer. Yay!

Also available in: Atom PDF