Bryce; no problem (and thanks for your working on this), for me the fbdev workaround is good enough to work and live with on this setup. If others affected by this feel differently, do take over with upstream.
Steps to reproduce:
1. In (gnome-control-center) Keyboard settings’ Shortcuts, set the shortcut for ’Lock screen’ to Scroll Lock.
2. Press Scroll Lock.
What happens:
Nothing (screen doesn’t get locked).
What I expect to happen:
For the screen to get locked.
What works:
* Setting ’Lock screen’ shortcut to Shift + Scroll Lock, Ctrl + Scroll Lock etc.
* Setting ’Lock screen’ shortcut to, for example, the Pause/Break key (which is right next to Scroll Lock on common keyboards).
* Setting Scroll Lock as the ’Lock screen’ shortcut in Unity 2D.
Other notes:
Pressing Scroll Lock does nothing whether set as screen locking hotkey or not, so it shouldn’t be tied to some other function either.
Strangely, with Chromium 18 I could no longer reproduce this with new profiles, but with my old profile it was still there.
Ah, sorry about that, I thought you wanted both updated logs from Lucid *and* tests with newer versions.
I just gave the current 12.04 Beta a spin and am happy to report that the issue seems to have been fixed there: despite my best efforts I couldn’t make it crash with the gallery site. It did remain somewhat sluggish to browse but the Oops never occurred.
I cannot get X working with the latest Mainline build for Lucid (2.6.35-rc1-lucid [1]) nor with linux-image-generic-lts-backport-maverick (which I figured I’d also try, as it’s also a build of 2.6.35). Both end with ”[drm] failed to open device” and ”No devices detected” in the log (I’ll attach one to this comment).
If I’m interpreting Nouveau Wiki’s Troubleshooting document [2] and the logs correctly, KMS is working (fb0 is there), which means there’s ”a version mismatch between the Nouveau DRM and libdrm”. Any help there would (also) be appreciated.
*[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc1-lucid/
*[2] http://nouveau.freedesktop.org/wiki/TroubleShooting#Xorg_fails_to_start_with_.22.28EE.29_.5Bdrm.5D_failed_to_open_device.22
Whoopsie, looks like I sent the updated logs twice. Oh well.
I’ll test upstream next.
Steps to reproduce:
1. touch ~/foo_åäö
2. In Nautilus, point at the file created in step 1
3. Right-click for context menu
4. Select Move to Trash
5. Press Ctrl-Z/Select Undo from the Edit menu
What happens:
Nothing
What I expect to happen:
For the file to recover from trash to ~.
What works:
* Undoing Move to Trash with files with no scandinavian letters in their path/filename.
* Recovering foo_åäö by opening Trash and selecting Recover from context menu.
More info:
* Could be that more characters, perhaps all non-ASCII characters render Nautilus’ Undo impotent — I’ve only tested å, ä and ö.
* The Finnish translation for Desktop (~/Desktop) is Työpöytä, which means files moved to trash from Desktop can’t be recovered. Nasty.
Happened just now with at least Gmail, Facebook and Google Reader open. Can’t pinpoint any specific trigger, and hasn’t happened before IIRC.
@d3mia7, maybe you could try 3.3 too? FWIW, I haven’t seen this since installing 3.3.0-030300rc4-generic a month ago now. If your system’s prone to freeze this way, testing 3.3 could provide further evidence as to whether the issue’s fixed upstream.
Steps to reproduce:
1. In Nautilus, select Connect to Server
2. Enter ftp server address, select FTP (with login) as type
3. Enter credentials,
4. select ”Remember this password”
5. Connect.
6. Disconnect.
7. Do steps 1.-2. again with the same server.
What happens:
The User name and Password fields remain empty. You have to enter your credentials again if you want to connect.
What I expect to happen:
For the Password field (at the very least) be automatically filled when I enter the associated user name. Better yet, remember and suggest (as default) both the User name and Password used previously.
Alternatively, just use ~/.netrc if that’s available and has the credentials (see Bug #963042).