Upgrading to Debian Stretch

The process of upgrading from Jessie was painless. It was not until I rebooted into Stretch that odd things happened.

Graphical Login

The setup under Jessie that the sytem presented a normal login prompt on the console. I prefer to start X myself. However, I was now presented with a graphical login from lightdm. Didn't ask for this; didn't want it.

The simplest solution seemed to be:

  sudo apt-get purge lightdm light-locker

I also noted that I did not have a systemd default.target set, so I also rectified this to ensure a console login:

  sudo ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Stretch is now back to my normal.

Sound

Sometime ago, with Jessie, I had changed the web browser from Google Chrome to Firefox. Firefox only supports sound via pulseaudio, so I had to install it for music from the web.

Under Stretch, there was no sound from Firefox or Audacious. Looking at the status of sound via pavucontrol, sound was playing, but nothing was coming out of the speakers. The Profile for Built-in Audio under Configuration->Built-in Audio was set to Digital Stereo (IEC958) Ouput + Analog Stero Input. That's probably the sound capability on the ATI graphics card, not connected to anything. The entry for Analog Surround 7.1 Output was marked as unplugged, but when I set that as the default profile, then sound was heard.

Ripit

My first attempt to rip an audio CD under Stretch resulted in the following:

   Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/(\\%(?:\\=)?(\w|\\{ <-- HERE (?:\w|\\[^\w\\{}]|\\\\\\[\\{}])*\\}|\\\W))/ at /usr/share/perl5/MP3/Tag.pm line 2611. 

   RipIT version 4.0.0-beta20140508. 

   Please update your config-file with option --save 
   to ensure correct settings! Pausing 3 seconds! 

   Argument "" isn't numeric in numeric gt (>) at /usr/bin/ripit line 11650. 
   Argument "" isn't numeric in numeric eq (==) at /usr/bin/ripit line 11735. 

   Process summary: 
   ---------------- 
   File permission will be set to 0644. 
   Normalizeing the CD-tracks. 
   Playlist (m3u) file will be written. 

   Please insert an audio CD!

A couple of problems to deal with here: the regex error and the fact that the audio CD was not seen in the correct drive.

The regex issue had been reported and a patch was available on the web:

  diff -Naurd a/lib/MP3/Tag.pm b/lib/MP3/Tag.pm 
  --- a/lib/MP3/Tag.pm 2016-06-19 22:19:34.000000000 +0200 
  +++ b/lib/MP3/Tag.pm 2016-06-19 22:25:43.968542369 +0200 
  @@ -2607,7 +2607,7 @@ 
       my ($self, $pattern) = @_; 
       $pattern = "^\Q$pattern\E\$"; 
       # unquote %. and %=. and %={WHATEVER} and %{WHATEVER} 
  -    $pattern =~ s<(\\%(?:\\=)?(\w|\\{(?:\w|\\[^\w\\{}]|\\\\\\[\\{}])*\\}|\\\W))> 
  +    $pattern =~ s<(\\%(?:\\=)?(\w|\\(?:\w|\\[^\w\\{}]|\\\\\\[\\{}])*\\}|\\\W))> 
  ( __unquote($1) )ge; 
       # $pattern =~ s/(\\%(?:\\=)?)(\w|\\(\W))/$unquote{$1}$+/g; 
       return $self->parse_rex_prepare($pattern);

Now for the drive issue. amber has a DVD RW drive and a DVD-ROM drive. Ripping from the DVD RW drive is much slower that the DVD-ROM drive, which is why I prefer to rip from the latter. From dmesg, these drives are detected as follows:

  [    2.429846] sr 0:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
  [mark@amber:~] sudo dmesg|grep sr
  [    2.429846] sr 0:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
  [    2.430051] sr 0:0:0:0: Attached scsi CD-ROM sr0
  [    2.441138] sr 0:0:1:0: [sr1] scsi3-mmc drive: 4x/40x cd/rw xa/form2 cdda tray
  [    2.441328] sr 0:0:1:0: Attached scsi CD-ROM sr1
  [    4.876407] systemd[1]: usr.mount: Unit is bound to inactive unit dev-sda7.device. Stopping, too.
  [    5.135052] sr 0:0:0:0: Attached scsi generic sg0 type 5
  [    5.136338] sr 0:0:1:0: Attached scsi generic sg1 type 5

The sr devices are aliased in /dev like this:

  [mark@amber:~] ls -l /dev/cdrom /dev/dvd*
  lrwxrwxrwx 1 root root 3 Jul 11 09:31 /dev/cdrom -> sr0
  lrwxrwxrwx 1 root root 3 Jul 11 09:31 /dev/dvd -> sr1
  lrwxrwxrwx 1 root root 3 Jul 11 09:31 /dev/dvdrw -> sr0

And, in ~/.ripit/config, the default ripping device was set to:

  cddevice=/dev/cdrom

So, since /dev/cdrom is linked to the DVD RW drive, that explains the drive issue. I set the default device to /dev/dvd. I suspect this might not be the most optimal solution. (See below).

Now, ripit was working, but there was still an error:

  13:57:00: Ripping "01_darkness,_darkness"... 
  Argument "" isn't numeric in numeric lt (<) at /usr/bin/ripit line 3937.

Looking through the source code, this error appeared to be caused by the offset being unset. Sure enough, in the ripit config file, I saw:

  # offset: User definable sample offset for the CD ripper. This will
  # trigger option -O when using cdparanoia and option -o when using rip.
  # Icedax (cdda2wav) seems not to provide a sample offset.
  # Possible values: integers
  # Example: 48
  # Default: 0

  offset=

Setting the value of offset to 0 fixed the issue. No idea why it was empty in the first place.

Renaming the DVD devices

Rather than changing the ripit config, I figured I could use udev rules to alter the assignment of the /dev/cdrom and /dev/dvd symlinks. The device attributes can be dumped by udevadm:

  sudo udevadm info --name=/dev/sr1 --attribute-walk

This gives sufficient information to identify the drives and assign the appropriate symlink. In the file /etc/udev/rules.d/z21_persistent-local.rules, I put the following:

  ATTRS{model}=="DVD-ROM DDU1615 ", SYMLINK+="cdrom"
  ATTRS{model}=="DVD RW DW-G120A ", SYMLINK+="dvd"

The rules can be reloaded to see their effect:

  [mark@amber:/etc/udev/rules.d] sudo udevadm control --reload-rules
  [mark@amber:/etc/udev/rules.d] ls -l /dev/cdrom /dev/dvd*
  lrwxrwxrwx 1 root root 3 Jul 11 16:04 /dev/cdrom -> sr1
  lrwxrwxrwx 1 root root 3 Jul 11 14:54 /dev/dvd -> sr0
  lrwxrwxrwx 1 root root 3 Jul 11 14:54 /dev/dvdrw -> sr0

That seems to work.

Later (September) ...

At some point, the above udev rules stopped working. The /dev/cdrom and /dev/dvd links were pointing to /dev/sg[01] devices. These are generic SCSI devices and ripit didn't like them. I'm not sure what the change was; maybe my testing wasn't as robust as it should have been, or maybe it was my failure to use udevadm trigger to trigger the new rules.

I dug around and discovered some default debian udev rules (in /lib/udev/rules.d. One of these files, 60-cdrom_id.rules unconditionally links /dev/cdrom to /dev/sr0. It is possible to turn off the default rules by creating a file of the same name in the /etc/udev/rules.d directory, linked to /dev/null. I just wanted to override the defaults, so after some experimentation, this is what worked:

  KERNEL=="sr[0-9]*", ATTRS{model}=="DVD-ROM DDU1615" , SYMLINK+="cdrom",\
  OPTIONS+="link_priority=100"

All these attributes are required to link /dev/cdrom to /dev/sr1. KERNEL to force using an sr device (otherwise it defaults to an sg device). The OPTIONS keyword is required to trump the link set by the default debian rules.