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.

> Why would you trust the site if it has insecure javascript?

Now let’s see tse…@chromium.org’s profile page [1]… Whoa! It has insecure JavaScript on it! We’d better not trust what this person says. ;-)

* [1] https://code.google.com/u/103427653469784489849/

jani@saegusa:~$ nautilus –version
GNOME nautilus 3.4.0

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

This looks like a duplicate of bug 538432 [1] though it refers to a different memo, RFC1738.

* [1] https://bugzilla.gnome.org/show_bug.cgi?id=538432

I reported this on Launchpad [1] and was forwarded 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 [2]).

* [1] https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/963061
* [2] https://bugs.launchpad.net/bugs/963042