FWIW, based on the above comments and my experience I’d lay at least some of the blame on this on nouveau: I have two setups affected by the Plymouth no-show, both with Nvidia graphics:
01:00.0 VGA compatible controller: NVIDIA Corporation G73 [GeForce 7300 GT] (rev a2) (prog-if 00 [VGA controller])
and
00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] (rev a2) (prog-if 00 [VGA controller])
At the same time all the other systems I have access to that run Precise on non-Nvidia graphics (some half dozen computers, old and new) don’t manifest it, i.e. they display Plymouth’s boot logo screen just fine on every boot without any workarounds. (The Nvidias need either FRAMEBUFFER=y or plymouth:force-drm.)
Also, on the G73, Grub menu shows at a low resolution without GRUB_GFXMODE specified, but on the C61 it’s ”Out of range”. It shows on both if I specify 1280×1024 (the maximum supported by the connected LCDs) as GRUB_GFXMODE. This too is Nvidia-specific, though I suppose the Grub menu is outside nouveau’s jurisdiction.
Hi Gary. I now tested this in a VM running up-to-date Precise and am happy to report the problem no longer occurs. I’m thus marking this as being fixed.
Apparently this is now supported; at least the following seems to work under 12.04:
$ qdbus org.gnome.Nautilus /org/gnome/Nautilus org.gnome.Nautilus.FileOperations.CopyFile "file:///source/directory" "*" "file:///destination/directory" ""
where /source/directory is the absolute path to your source directory, * is the glob for file[s] to copy,/destination/directory is your destination directory and the last ”” is for destination file name. Note that you need to have the last one there even if it’s empty as in here, to fulfill the method signature. Also, if you specify a target name and have multiple source files, they’ll all get copied to that one destination file, giving an overwrite prompt for each file after the first one (which may or may not be what you want).
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.
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.
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.