Emanuele: You’ll need to go through some hoops via the Overview page linked to on top of this report, until you get to https://launchpad.net/ubuntu/precise/+source/unity-greeter/0.2.0-0ubuntu4 where you need to pick the build for your architecture. Use dpkg –install to install the .deb file. Good luck!

After yesterday’s upgrades including libindicator7, unity-greeter crashes repeatedly until failsafe kicks in, and even then, after selecting low graphics mode for the session, it crashes. I managed to get X working again by downgrading unity-greeter back to 0.2.0-0ubuntu4 which I’m filing this report with. The crashing update was version 0.2.0-0ubuntu5.

I’m attaching the crash file.

It seems I’m not able to reproduce this on my other computer (also running up-to-date Precise), so I’ll look for differences in the setups.

(Doing this in reverse order, as I think the steps are best represented by what I actually type in.)

Premise:
I’m a newbie who tries to do the nasty and make grep output always colored using GREP_OPTIONS. I have a file called test, with numbers 1-9 each on its own line.

What I expect to happen:
For all the numbers I grep from my file except 2 to be colored.

What actually happens:
Neither when preceding the grep with GREP_OPTIONS when I grep 4, nor when GREP_OPTIONS is exported prior to grepping 5, is the resulting output colored.

What does work:
Passing –color=always as a genuine grep parameter. Passing (for example) -V in GREP_OPTIONS either on the same line or exported.

Additional notes:
This crippling might be some kind of a safety measure to prevent all the breakage that doing what I’m attempting to do risks inflicting on the system. But I’ve not been able to find any documentation about such a design decision having been made, and in contrast, the man page to my understanding implies that this should, in fact, work.

Steps to reproduce:

jani@saegusa:~$ printenv | grep -i grep
jani@saegusa:~$ grep 1 test # colored
1
jani@saegusa:~$ grep 2 test | cat # not colored
2
jani@saegusa:~$ grep –color=always 3 test | cat # colored
3
jani@saegusa:~$ GREP_OPTIONS=’–color=always’ grep 4 test | cat # NOT colored!
4
jani@saegusa:~$ export GREP_OPTIONS=’–color=always’
jani@saegusa:~$ grep 5 test | cat # NOT colored!
5
jani@saegusa:~$ export GREP_OPTIONS=’-V’
jani@saegusa:~$ grep 6 test | cat # control
grep (GNU grep) 2.10
Copyright © 2011 Free Software Foundation, Inc.
Lisenssi GPLv3+: GNU GPL versio 3 tai myöhäisempi
Tämä on vapaa ohjelma: voit vapaasti muuttaa ja jakaa sitä edelleen.
Ohjelmalla EI OLE TAKUUTA siinä laajuudessa kuin laki sen sallii.

Tekijät: Mike Haertel ja muut, katso .

Steps to reproduce:
1. jani@ritoru:~$ LC_ALL=C eog Kuvat/Kuvakaappaus\ 2012-01-21\ 11\:46\:17.png
2. From the Edit menu, choose Toolbar.
3. From the Toolbar Editor, pick Edit, drag and drop it onto the toolbar in the main window.

3.2.0-10 #17 kernel panic pid: 1, comm: init printk+0x2d/0x2f (1019.6 KiB, image/jpeg)

Robert, I tested your kernel. Unfortunately there’s little to report: here it still panics when bringing up X with -intel. Should I perhaps file a different bug about these?

I’ll attach a picture of the output. Looks like the freezing with just the mouse cursor occurs about 1/3 of boots, in 2/3 it manages to switch back to the logging terminal with the panic.

Oggs, AVI’s affected as well. Apparently it’s just MKV’s that either don’t exhibit this or just manifest it differently.

Actually, with the MP3 it’s Bug #918077 (which I just reported). Could be the same underlying issue, but I felt it best to report these separately as the symptom differs slightly.

See Bug #907644 for a similar issue with MKV files.

With MP4 and MP3 files, with just one such file on the playlist and looped (with repeat mode on), the file is played through twice with no problem, then it just stops at the end. Restarting the video by double-clicking on the playlist item works.

As in #907644, if you add another file (or another instance of the same file) to the playlist and let it loop between the two, there’s no problem. But with the single file repeating the bug is 100% reproducible. Not reproducible with VLC.

Steps to reproduce:
1. Load an MP3 or MP4 in Totem.
2. Set ’Repeat Mode’ on.
3. Let the file play through two rounds.

What happens:
At the end of second play, the playing stops and does not start again by itself.

What I expect to happen:
For the file to repeat ad infinitum.

No problem, thank you for your rapid response to this and for the learning I gained! I’ve modified the scripts accordingly and it all works smoothly (and as intended) now.

I can’t tell if you can see it from the Apport-attached files, so I’ll add that I’m running Unity 2D here.