On 12.04 at least, the target is governed by cupsd’s AppArmor profile (see bug #147551) and trying to circumvent it using symlinks fails irrespective of whether the target is on another filesystem or not (”failed to set file mode for PDF file” in /var/log/cups/cups-pdf_log).

As per bug #147551, when the default target directory is changed in cups-pdf.conf, cups-pdf silently fails to print anything until a corresponding change is made in the usr.sbin.cupsd AppArmor profile. The ”Out” key in cups-pdf.conf is preceded by commented notes about the usage, but the AppArmor requisition goes unmentioned, apparently causing confusion among users. I suggest something like the attached patch be applied to cups-pdf.conf to document this.

Just making a note about similarity between this and bug #939301; latter perhaps a duplicate?

umount.crypt doesn’t support lazy unmounting:

jani@saegusa:~$ sudo mount .Backup
Password:
jani@saegusa:~$ grep Backup /etc/mtab
/dev/sdc1 /home/jani/.Backup crypt rw,nosuid,nodev,noauto 0 0
jani@saegusa:~$ sudo umount -l .Backup
Unknown option: -l
Usage: umount.crypt [-fnrv] [-?|–help] [–usage]
Unknown option: -l
Usage: umount.crypt [-fnrv] [-?|–help] [–usage]

The usefulness of -l is documented in umount(8).

Strangely, the Debian BTS claims this feature has already been implemented ages ago [1].

*[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370526

As a workaround for 12.04, here’s a command that replaces the settings file with an unwritable empty one that seems to prevent the issue from occurring:

$ rm -f ~/.openyahtzee && touch ~/.openyahtzee && chmod -w ~/.openyahtzee

This obviously prevents you from saving any settings, but then again you can’t utilize saved settings with the buggy version anyway.

To revert the workaround, remove the unwritable dummy file with:

$ rm -f ~/.openyahtzee

Steps to reproduce:

1. Load a playlist of N files in VLC
2. Set playback to Random
3. Play or jump (with ”Next” button) the playlist forward for N files and observe the playing order
4. GOTO step 3

What happens:
The order in which the files are played in step 3 always repeats itself.

What I expect to happen:
For the files to be played back in a truly random order, without any perpetually repeating pattern.

Further info:
The playing order seems to get shuffled only at the start, so the playlist isn’t played in order, but the once-shuffled order is repeated over and over. To reshuffle the playlist, VLC has to be restarted, but still then it just plays the newly-shuffled playlist over and over.

To be fair, in practice instead of true randomness I suspect most people prefer something from the way the ”Random” now works: that each file on the playlist is played once and once only in every N plays. AFAICT it is not mutually exclusive with reshuffling the playlist between those N plays; just make sure that the two transitional files (last file of shuffled-playlist-1 vs. first file of shuffled-playlist-2) aren’t the same.

I for one though would still prefer even true random over what it currently is.

Of the half a dozen or so randomness-related bugs in VLC’s tracker I was able to find, Ticket #5730 (”New Feature Request: Shuffle & Random for Playlists”) [1] came closest to what I’m reporting here. In fact, it’s a superset of this one and I’d prefer to have it fixed over just mine.

*[1] http://trac.videolan.org/vlc/ticket/5730#trac-ticket-title

No problems with 3.5 either, marking as invalid.

Sorry, I had forgot about this one after it vanished and was only reminded by a private email from someone suffering something similar.

I went through my collection of panic photos and (as my recollection also was) there seem to have been none of this ’warn_slowpath_common’ kind since I last commented.

Except for one just a week ago, on completely new hardware: this one with 3.8.0 rc2 when I was testing it wrt Bug #1096802, which turned out to be caused by bad card reader firmware. It was tied to usb-storage as most if not all of the panics caused by the firmware problem, so it was most likely another symptom of that, but I’m posting that one here too just in case it still contains a hint of the conditions under which ’warn_slowpath_common’ can occur.

Meanwhile, I’m marking this as fixed as per Joseph’s request above. For the record, as far as I’m concerned, a installing 3.3 or newer series kernel was a definite fix for this issue.

I’m happy to report that this seems to have been a firmware issue: with a temporary install of MS Windows, which the card reader manufacturer’s firmware upgrading software required [1], I managed to upgrade the card reader’s bought-with firmware version 551 to manufacturer’s current latest version 563 (released just last month). After this there were no more ”disabled ep” messages in any boot, the reader works just fine and there have been no kernel panics of any kind.

This was with the mainline 3.8 kernel so I’m not marking this bug invalid just yet. I’ve now switched back to the Quantal kernel I initially reported this with and will report here next week on how it goes.

*[1] http://www.akasa.com.tw/update.php?tpl=product/cpu.product.tpl&no=181&type=Card%20Reader/Hub&type_sub=Card%20Reader&model=AK-ICR-17

The lsusb listing attached by apport above seems to not list the card reader at all. This did happen on some sessions, IIRC there were no panics or ”disabled ep” messages then either but naturally, the reader also wouldn’t read any cards, it was as if disconnected.

I’m attaching output of `sudo lsusb -v` here, with the card reader (004:002) detected and showing.