[Bug 293832] Re: printer prints page at wrong position, page cut
Confirming with a Brother MFC-5460CN on Lucid. Please re-open this. -- printer prints page at wrong position, page cut https://bugs.launchpad.net/bugs/293832 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 293305] Re: [patch] Inactive import folder in f-spot
Is it going to be backported or updated in intrepid too? -- [patch] Inactive import folder in f-spot https://bugs.launchpad.net/bugs/293305 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to f-spot in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 295560] Re: Hardware and software don't agree on brightness level
** Changed in: gnome-power Importance: Undecided = Unknown Bugwatch: None = GNOME Bug Tracker #568341 Status: New = Unknown -- Hardware and software don't agree on brightness level https://bugs.launchpad.net/bugs/295560 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 295560] Re: Hardware and software don't agree on brightness level
my conclusion is that gnome power manager can: notify change events to the user (brightness bar) (ok here) dim the screen after a period of inactivity, if user wishes so. (and set it back the previous level) (probably ok too, when the xrandr issue is fixed) and must not: 1: use xrandr 2: set brightness upon login/battery/ac events A couple of new gconf settings could give the user enough control to impose this behaviour. eg brightness_method = auto | hal | xrandr | wathever (fixes 1) brightness_on_power_change, a boolean (fixes 2) (should also disable set brightness to slider in preferences) -- Hardware and software don't agree on brightness level https://bugs.launchpad.net/bugs/295560 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 275952] Re: Unread search folder removes messages as soon as their unread flag is toggled
Non unread vFolders still have a wrong unread message count for me. In general this new Evolution (since intrepid) is handling read/unread count totally wrong. Can we hope in another minor release in the future? -- Unread search folder removes messages as soon as their unread flag is toggled https://bugs.launchpad.net/bugs/275952 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 291881] Re: Search folders have the wrong Unread count
I still have this after the update. However it seems less severe. It is probably counting spam and automatically marked as read for unread messages. I hope in a new bugfix release... -- Search folders have the wrong Unread count https://bugs.launchpad.net/bugs/291881 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 295560] Re: Hardware and software don't agree on brightness level
** Description changed: - Binary package hint: hal + Binary package hint: gnome-power - The following description is a little complicated, but if you just play - around with brightness controls, you will easily see for yourself what I - am talking about. - - Since Intrepid (and Fedora 10) Gnome has found a new way of setting - brightness on my laptop (Dell Latitude D630) which interferes with the - FN-buttons and the old libsmbios way. - - I don't know how it does it, since ACPI does not support brightness setting on my model: - cat /proc/acpi/video/VID*/LCD/brightness - not supported - not supported + Since Intrepid (and Fedora 10) gnome-power-manager has found a way using + xrandr of setting brightness on my laptop (Dell Latitude D630) which + interferes with the FN-buttons and the old libsmbios way. The brightness applet now works decently. It has many different possible - levels and change of brightness is continuous, though not immediate and - responsive. On hardy it worked with 8 levels of brightness, but maybe a - little smother. + levels and change of brightness is continuous, though not immediate. On + hardy it worked with 8 levels of brightness, but maybe a little smother. + + The FN-keys (in my understanding) instead handle the brightness in + hardware using 8 possible levels and the BIOS notifies the event to the + operating system, so that the user can see a bar indicating the level + just set. The BIOS also remember what value is currently set for ac and + battery modes on its own, and changes that when power supply changes. + + In hardy this way of handling the brightness was the only and so it was + coherent. Now having two mechanisms causes confusion between them. + + ___ + The following description is a little complicated, but if you just play around with brightness controls, you will easily see for yourself what I am talking about. Changing trough the FN-keys is a different story: It takes 9 key strokes to go from maximum to minimum brightness, the brightness level indicator that pops out on the screen has 20 steps. On the contrary going from minimum to maximum requires all the 20 steps, even though some of them, especially the first 4, don't seem to do anything. This mismatch causes confusion and weird behaviour of gnome-power-manager, as the effective brightness is different than the reported brightness. Basically the screen is never bright exactly as you want it to be... the whole thing is just buggy. I tried using dellLcdBrightness and found out that it gets confused too. - It only has 8 possible levels. - It's hard to fully explain, but basically I can easily have gnome think - that brightness is 100% when it is actually at minimum or viceversa. - That goes for dellLcdBrightness as well. + It's hard to fully explain, but basically I can easily have gnome think that brightness is 100% when it is actually at minimum or viceversa. That goes for dellLcdBrightness as well. + __ - A quick way to fix this is to revert to the old libsmbios based mode of - handling this model's brightness, though it had only 8 levels and did - not work with a BIOS password. + A quick way to fix this is to revert to the old libsmbios based mode of handling this laptop's brightness, though it had only 8 levels and did not work with a BIOS password. + Another (nicer) way would be to make the BIOS completely stop handling brightness when gnome-power-manager starts, making the Fn keys normal keys. Can it be done, Dell? + The best way would be to make libsmbios and xrandr agree. ** Changed in: gnome-power-manager (Ubuntu) Sourcepackagename: hal = gnome-power-manager ** Changed in: gnome-power-manager (Fedora) Sourcepackagename: hal = gnome-power-manager -- Hardware and software don't agree on brightness level https://bugs.launchpad.net/bugs/295560 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 295560] Re: Hardware and software don't agree on brightness level
** Also affects: hal Importance: Undecided Status: New -- Hardware and software don't agree on brightness level https://bugs.launchpad.net/bugs/295560 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 295560] Re: Hardware and software don't agree on brightness level
I did some further investigation and updated the description. I think that some kind of cooperation between all the project marked as affected is necessary, at least for an initial decision. I would like to know (from Dell?) if the bios can be made stop handling brightness at all from userspace (and if there are errors in my description) It's now been some time and I like to see this bug at least triaged and acknowledged; especially since it took _me_ a lot to find the cause of that other problem with brightness that caused crashes on Latitudes with a bios password, only to have brightness not working again in a few months. As of now I think I've done all that I can. -- Hardware and software don't agree on brightness level https://bugs.launchpad.net/bugs/295560 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 291259] Re: smb:// URI's do not work
you rock! Now the package can be fixed... btw, the schema is missing as well. -- smb:// URI's do not work https://bugs.launchpad.net/bugs/291259 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 292565] [NEW] smb://host bookmark not opening from places menu [regression]
Public bug reported: Binary package hint: gnome-panel software involved: Ubuntu Intrepid, gnome-panel version 1:2.24.1-0ubuntu2 to reproduce: 1: use nautilus to browse a samba server's shares list. For example smb://localhost 2: add a nautilus bookmark to that location 3: open the new bookmark trough the gnome places menu (also drag the new icon on the panel and launch it from there to get the same result) result: An error message about the impossibility of opening the position and no application registered to handle that file. expected result, as it was in Hardy: a nautilus windows as in step 1 to reproduce. what works: opening the bookmark from the bookmarks menu in nautilus, bookmarking a share on a host (e.g. smb://localhost/share) opening the same URI from the command line (e.g nautilus smb://localhost) As a side note, I keep not understanding why gnome-panel must use an internal format for some launchers like logout and those in places. This makes them not moveable/draggable on the desktop. There should be almost only .desktop files that execute commands, it's really this simple. A bookmark in the places menu would just execute nautilus $URI and that would not trigger a stupid little bug like this one. ** Affects: gnome-panel (Ubuntu) Importance: Undecided Status: New -- smb://host bookmark not opening from places menu [regression] https://bugs.launchpad.net/bugs/292565 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-panel in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy with BIOS password set
A detailed new bug report as been opened, now that we got to the root of this: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/244606 please mark this as closed and anyone interested move to the new one. -- [hardy]computer and touchpad is buggy with BIOS password set https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: computer and touchpad is buggy with BIOS password set
After many comments and investigations, found the root cause! ** Changed in: hal (Ubuntu) Sourcepackagename: linux = hal Assignee: Ubuntu Kernel Team (ubuntu-kernel-team) = (unassigned) Status: Triaged = New -- HAL crashes dell laptops with a BIOS password https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: HAL crashes dell laptops with a BIOS password
** Summary changed: - computer and touchpad is buggy with BIOS password set + HAL crashes dell laptops with a BIOS password ** Description changed: - This bug happens with a freshly installed hardy beta 1 when the computer - is running on battery or at the moment I plug/unplug the electric cable - into my computer. + This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first. + The problem reported here and its cause have already been confirmed by at least 5 users. + This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault. - If I let the computer unused for some minutes (2-5 minutes), when I come - back and try to use the mouse, the mouse move of some centimeters, - suddenly freeze for almost 5 seconds, and then come back to life. It can - be reproduced since it continually happens each time I use my computer - after reading a short text or spooke to somebody. If I plug or unplug - the electric cable, the mouse freeze again for a 7 seconds. If any - sounds are playing during the time that the mouse freeze, the sound is - also corrupted and freeze. + Symptoms: + very frequent temporary lock-ups on input after some inactivity + frequent hard lock-ups with CAPS lock and NUM lock flashing + very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg + [ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away. + [ 807.405427] psmouse.c: resync failed, issuing reconnect request + [ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9 + [ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10 - This bug does not happen when the electric cable is plugged, and it - happens with metacity as much as compiz. + Affected hardware: + dell laptops with a BIOS password set (probably all/most of them) - Each time that the mouse suddenly freeze, I get this in dmesg : - [ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away. - [ 807.405427] psmouse.c: resync failed, issuing reconnect request - [ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9 - [ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10 + Releases affected + hardy for sure, probably intrepid too. gusty is not affected. + Other distro are affected too, e.g. Fedora 9. - This bug is not a hardware failure because it is not reproducible under - Linux Ubuntu Gutsy and Windows XP. + What is known so far: + gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input. + This is a default setting, so the user has no clue of what might be causing the issue. + gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting. - Dell Inspiron 9300, i386 + Libsmbios needs the BIOS password even to change the brightness and HAL + has no way to tell it that password, as of now. Some users have also + reported that libsmbios does not work even from the command line + utility, specifying the pass. - Update : It has been found that this bug only appears when there is a - BIOS password set on laptop computers. + However, instead of just printing an error when it fails, it makes the + computer lock for a few seconds, due to the direct interaction with the + bios on a very low level. The kernel has then problems reading input + events and might crash. These lock-ups should also be avoided in + libsmbios, as that is really ugly. However it needs root privileges and + it's HAL who is calling it again and again when it should not, so the + lockups are more HAL's fault. + + Testing/repoducing: + 1: of course using gnome and gnome-power-manager, setting Dim display when idle to enabled. + Same effects can be achieved by: + 2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package. + Here's a command that rapidly switch brightness 10 times: + for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done + #Warning it may hang your machine + 3: the brightness applet of the gnome-panel. + + A possible elegant solution: + * Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added. + Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned) + Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL
[Bug 189814] Re: HAL crashes dell laptops with a BIOS password
I really did not know that I could alter the original description and do the other stuff myself. Dell guys please read the description, this matters to you. ** Also affects: libsmbios Importance: Undecided Status: New -- HAL crashes dell laptops with a BIOS password https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
Just answer me an apparent silly question if you are experiencing this. Do you have a BIOS password set? -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
I think I now where the problem lies ultimately. Can you just do a small test for me? Add a brighness applet to the gnome panel and try to see if that works smoothly. On my d630 it does not work with a bios password set, but does without. Il giorno lun, 30/06/2008 alle 08.53 +, BackwardsDown ha scritto: No, never had. -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
This is my idea: gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input. gnome-power-manager calls HAL to do the job. HAL has multiple methods of handling brightness of LCD panels. On dell machines, since hardy it uses a libsmbios. Libsmbios has only rudimentary support for setting the brightness thought. For example it does not work if a BIOS password it set and apparently on some dell models. However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. There is a very easy way to try if it work on your computer using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package. Here's a command that rapidly switch brightness 10 times: for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done #Warning it may hang your machine Without a BIOS password it works fine on my laptop (D630) Another way could be with the brightness applet of the gnome-panel. A possible elegant solution: Correct HAL's detection of this capability, so that it only reports it when brightness can be set with no errors. Maybe also add some way for HAL to read the bios password from config files if the user wishes so. Oh and fix libsmbios to avoid stalling on error, that is ugly. Less elegant: turn off HAL's usage of libsmbios in some config file and have users who want it to manually set it. possible temporary workaround: blacklist the dcdbas kernel module disable dimming in gnome-power I don't know how to disable it from HAL, but that would be the best workaround. NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash. I hope this info proves useful. -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
I really took interest in fixing this and it seems I finally hit the root of the problem. Thanks to you all for your comments and trials, as without the hint on gnome-power-manager I would never have though of such a thing. The community is always great! If others having this problem confirm that it disappears with no BIOS password, probably the best thing is to open a new bug against HAL with concise infos. I'll be glad to do it myself tomorrow if nothing new shows up here. It's nice to have stability again. -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
With the heat of these last days it seems to happen even more. Kernel parameters did not solve the issue. Yesterday I also uncovered something. I was watching a video on youtybe and had the screensaver coming in every minute, so I touched the touchpad everytime the screen started to go black. This mostly resulted in a few second of audio looping and gui freeze. Interesting is that it happened with the touchpad, the touchpoint and the keyboard itself. So it is not specific to touchpads or the tiny blue touch point, but also can be triggered by the keyboard. Can also someone CC dell on this bug? PS happened a total of three times during writing of this and crashed my laptop around 3 times a week since hardy installation, so how about setting priority to high? If it does not get solved I will have to switch distro... -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
You might want to give a try to adding i8042.nomux=1 to your kernel command line. It is *maybe* working for me. And if someone knows what does that mean, I'd like to know... -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
still present with 2.6.24-19-generic. Here are my findings: 1 battery or not battery it happens 2 it starts when using again the touchpad after a period of inactivity. (Maybe on battery this period can be shorter) when it starts it freezes everything for some seconds, CPU usage get to 100% on all cores. At this point if you keep insisting on the touchpad you can really crash the machine. If you let go it usually just pass but you have to notice quickly. 3 sometimes the touchpad looses touchpad functionalities (eg scrolling on the right border). 4 dmesg entry psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing N bytes away. not always shows. 5 many people are having this problem, someone also on fedora, someone since 2.6.15, mostly on dell laptops. I think I could get to reproduce it anytime I want, so I can produce any debug/crash information. Just tell me what to do and I'll do it. -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 189814] Re: [hardy]computer and touchpad is buggy when running on battery
I have this very same problem with 2.6.24-17 generic on a dell latitude d630. And it really bothers me. My latitude has a touch point, a sort of secondary mouse in the middle of the keyboard. I was wondering if this bug is somewhat related only to similar hardware configurations. Is there someone that does NOT have another mouse/touch point and experience this problem? Ironically I was trying fedora 9 because of this problem with the thouchpad and related instability and got it there too. So it is 99% sure not Ubuntu specific and it is not being fixed in 2.5.25! That's one sneaky and evil bug. From what I've seen many people are having this and complaining about and probably there are lots more that didn't properly identified the issue, as dell laptops are pretty common. I would really like the priority of this to be set to High, as it is a regression too, coming from gutsy. PS I think this bug is the same of 207919. -- [hardy]computer and touchpad is buggy when running on battery https://bugs.launchpad.net/bugs/189814 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 84876] Re: Gnome settings manager error to start desktop
Allright, I have this very same problem on three different machines. Lots of people have it. It's not a showstopper, but it's a scary thing to have in a stable release for this many months. Let's raise the priority, let's look into this. Looks like a synchronization problem to me. Did anyone have this on a single core machine? Also found a dupe: https://bugs.launchpad.net/ubuntu/+bug/155164 -- Gnome settings manager error to start desktop https://bugs.launchpad.net/bugs/84876 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
