Steps to reproduce:
1. Disable power saving
2. (Re-)boot (logoff may suffice, though I’ve not tested this)
3. Login and don’t touch mouse or keyboard after that
4. Wait

What happens:
Within half an hour (on my system at least) the display signal is turned off (monitor reports ”No signal”).

What you expect to happen:
The screen to stay on as indicated by power saving settings.

Additional info:
1. Any keyboard or mouse activity seems to make it obey the setting: after that the screen won’t go blank on its own (irregardless of whether or not the bug has manifested itself during the session).
2. I’ve disabled screensaver as well, though that probably doesn’t concern this bug.
3. From bug #854624’s comments I picked up this settings listing command, in case it helps:

jani@saegusa:~$ for c in `dconf list /org/gnome/settings-daemon/plugins/power/`; do echo -n ”/org/gnome/settings-daemon/plugins/power/${c}=”; dconf read /org/gnome/settings-daemon/plugins/power/${c}; done
/org/gnome/settings-daemon/plugins/power/sleep-display-ac=0
/org/gnome/settings-daemon/plugins/power/sleep-display-battery=0

Yksi helposti kokeiltava niksi on ottaa laitteistokiihdytys (Hardware Acceleration) pois päältä flashin asetuksissa. (Mikäli sillä ei ole vaikutusta, se kannattanee palauttaa takaisin oletusasetukseen.)

As the title says. Steps to reproduce:

0. Run Maximus.
1. Run gnome-terminal.

What I expect to happen:
Gnome terminal window to open maximized.

What happens instead:
Gnome terminal window opens unmaximized.

Additional notes:
/apps/maximus/exclude_class only has Totem listed (no gnome-terminal).

Totem crashes when trying to use the ’open file’ dialog to navigate to a certain subdirectory (containing only two subdirectories). This happens with 99% certainty. In the remaining 1% it happens when I proceed to one of the two sub-subdirectories. Unlike bug #891460, this is on an ext4 partition.

Mitenkä on, onko bugien raportoinnissa syytä olla tavallista harkitsevaisempi näin varhaisessa vaiheessa kehityssykliä (ennen feature freezeä)? Järjestelmähän on tässä vielä liikkuva maali, eli bugeja tulee ja menee jatkuvien muutosten myötä joka tapauksessa. Vievätkö bugiraportit tällöin kehittäjien resursseja turhaan, vai olisiko ongelmat päinvastoin hyvä raportoida mahdollisimman pian, jotta mahdollisimman monta myös ehditään korjata ennen julkaisua?

Bug still present in Precise.

I believe the correct way, as per the Desktop Application Autostart Specification, is to create user-specific configuration overriding the system default.

1. cd ~/.config/autostart
2. cp /etc/xdg/autostart/bluetooth-applet* .
3. echo ”Hidden=true” | tee -a bluetooth-applet*

In a case such as Sergey’s, where the problem is caused by a faulty vfat rather than some weirdness on Ubuntu’s side, formatting the disk may be avoided by using fsck:

$ sudo fsck.vfat -r /dev/sdg1 # replace sdg1 with your usb drive partition device file

I couldn’t, and neither could I with a 10.10 live, so it’s possibly something that’s changed going from 10.04 to 10.10. I also tried Chromium and Firefox 6 under 10.04; with Firefox 6 the issue persists, whereas with Chromium I can’t reproduce it. There’s of course a more serious bug underlying the browser, as no application issue should bring the entire system to its knees.

(I just realized I used amd64 live discs in the tests whereas the installed 10.04 is an x86 system. Perhaps it makes no difference but I’ll leave judging that to experts.)

I’ll gladly execute more tests if anyone has ideas how to narrow this down even more.

Thanks for your input Timothy, I’ll have to see if I can reproduce this using a 11.04 live disc.