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).

Steps to reproduce:
1. Set up a ~/.netrc with credentials for a given server
2. Verify that automatic login with those credentials works when using command-line ftp
3. In a Nautilus window, select Connect to Server, enter given server and choose FTP (with login) as type

What happens:
Nautilus prompts for login credentials (User name, Password) with nothing in the fields pre-filled.

What I expect to happen:
For the fields to be automatically filled with the credentials I’ve already specified in ~/.netrc.

Additional info:
Nautilus apparently has its own way of storing credentials (i.e. different from ~/.netrc). When it has credentials of its own for a server, those should obviously come first. But when it doesn’t, it should utilize ~/.netrc if possible.

More accurate upstream target; previous was fixed but didn’t fix the issue reported here.