Here’s the steps I can currently reproduce this with on my system:
0. Have Gdebi associated with .debs
1. Download http://launchpadlibrarian.net/89242455/linux-generic_3.2.0.8.8_i386.deb in Chromium
2. Click the downloaded file in Chromium’s downloads bar to open it in Gdebi
This results in Gdebi launching and the crash triggering. If I then close Gdebi, it triggers the same crash again (apport points me to this report in both instances).
(I have yet to install the upgrades from this weekend. If any of those change this, I’ll report back.)
Happens at least daily. Nothing I do in particular to pinpoint as the trigger. Now that the crash has occurred, the lens doesn’t seem to work (clicking the files it shows does nothing). I’ll try it again on another session prior to the SIGSEGV happening.
This is a terse report, I know, but I’ll provide any additional info anyone might care to ask for if needed.
Jason: As with Davide, it was indicator-power that was missing here. The greeter log didn’t show that though, it claimed libdatetime.so was missing even though indicator-datetime is in fact installed.
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.
