Sorry, the GM965 Express is the chipset, that one has a Mobile Intel GMA X3100 display adapter.

Confirming this on another G31 (MSI MS-7525). Haven’t seen similar on 5 other Precise setups I have, including laptops with Intel 855GM and GM965 Express on the graphics (the G31 has GMA 3100).

Here’s why this is broken: logging out != shutting down. Why does the sync block logout instead of continuing in the background, and just blocking any attempts to *actually* shut down? The way it currently is makes it impractical to use U1 to sync my users’ config, because they’re blocked from fast user switching by the wait on every logout.

• initialize self.nma and self.nm as they are on watch_name_owner events Edit (931 bytes, text/plain)

Here’s a patch that worked for me. It adds some lines to what becomes /usr/share/pyshared/blueman/plugins/applet/NMPANSupport.py during installation, to set up variables that are otherwise left initialized to ’None’, hence the error when they’re used later on.

Note that I don’t know anything about DBus, have barely glimpsed at Python prior to this, and in particular have no knowledge of how Blueman’s developer intended for things to work, so apply at your own risk.

Steps to reproduce:

1. Select a tag (with photos attached to it)
2. Select the associated photos (Ctrl-A)
3. From the Events menu, select ”New Event…”
4. Repeat steps 1. & 2. for another tag
5. Try to create a new event as in step 3.

What I expect to happen:
To be able to create a new event just as before.

What happens instead:
The ”New Event…” menu item is ghosted and won’t become enabled again unless I shut down Shotwell and restart it.

Still very much an issue in 12.04.

Sumana: Thanks. I’m fairly new here and to Git in general, so I’d rather not, but it’s fine by me if Pranav wants to.

Most of the problems (”freezing”) seen by the user would probably fall under Bug #994306, which I’ve now witnessed on this system. The one I reported above is different, and apparently much rarer in occurrence.

Steps to reproduce:
1. $ chromium-browser –temp-profile # just to rule out custom configuration
2. Go to youtube.com/html5, opt in to html5
3. Go to http://www.youtube.com/watch_popup?v=-JryxdydOj0&vq=480

What happens:
The tab goes Aw, Snap! and dmesg says ”chromium-browse[12042] trap invalid opcode ip:7f4e637e1c7d sp:7fff4a10d878 error:0 in chromium-browser”.

What I expect to happen:
I haven’t bothered to check how it should behave, but at least it shouldn’t crash.

Additional information:
Seems to happen with both chromium-codecs-ffmpeg and chromium-codecs-ffmpeg-extra (from Medibuntu) alike.

I’m attaching a backtrace. I did my best with it, but I’ll readily admit I have no idea of its value. Please do advise me if I more -dbg packages or something else is needed.

Wind buntu, have you by any chance opted in to YouTube’s HTML5 programme (see the bottom of page at [1])? I’ve found Chromium is all too eager to crash with WebM, which is the video format used in YouTube’s HTML5 experiment.

It’s not limited to WebM though, there are issues with YouTube videos without HTML5 enabled as well.

*[1] http://www.youtube.com/html5