Problem continues on Quantal.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/951585
Title:
gvfsd-afp consumes 100% of processor cycles
To manage notifications about this bug go to:
I see this happening occasionally, some time after browsing an AFP share
on a Mac using Nautilus on Ubuntu. I don't know what specifically
triggers it to start. I have also experienced it on 11.10.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
It just happened again. I had left the machine otherwise idle with an
AFP share connected in Nautilus, showing on the screen. Attaching a
process list - PID 13309 is the culprit - not sure what else is
necessary. Syslog has nothing relevant, .xsessionerrors likewise.
** Attachment added:
Just noticed the OP names gvfsd-afp as the problem process - for me it
turns out to be gvfsd-afp-browse. Maybe it's a different bug.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
I find it hard enough managing my tens of users on an LTSP system using
this tool without proper sorting, it must be a nightmare with hundreds!
I believe this issue should receive a higher priority. Clicking on
column headings to change the sort order is just expected behaviour
these days.
--
This is happening for me too, trying to burn an iso image to a blank CD-R.
Output from Brasero -d:
(brasero:30369): GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT
(object)' failed
The UI says there is no space available.
It is version 0.7.1-3ubuntu1 in Hardy.
Serpentine works
Just to clear up any confusion and speculation, LTSP in Ubuntu uses LDM
for the terminal sessions by default, but earlier versions used to use
GDM via XDMCP from the terminals and it can still be configured do so.
This suits slower, older terminals. LTSP addresses a different need to
XDMCP and
This is a problem for me too with nvidia-settings on Hardy.
--
gnome-screensaver restores default color-correction settings
https://bugs.launchpad.net/bugs/33214
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a direct subscriber.
--
desktop-bugs
The workaround in comment 52 fails on a Gutsy multi-user system, such as
Edubuntu with LTSP, because the first user to logon owns the file /tmp
/session-is-gnome, and because more than one user might be logging on
simultaneously. The flag file name should incorporate a username and/or
session id
Hi Basilio - I have since converted the classroom to use LDM in Edubuntu
Gutsy, and I'm not onsite, so I can't really test MaxPending. However, I
have just run the above test on MaxSession in Hardy using straight
Ubuntu, setting MaxSession and MaxPending to '2' using the steps I gave
above, with
Public bug reported:
Binary package hint: gdm
GDM in Gutsy Edubuntu ignores the MaxSessions and MaxPending settings in
gdm.conf-custom, and uses the default values of 16 and 4 respectively.
To reproduce:
1. Go to system-administration-login window
2. Go to 'Remote' tab and click 'Configure
Xnest has always worked for me, both from other systems and from Gutsy
systems - it is broken when connecting by selecting XDMCP from the GDM
screen, rather than a nested session. It seems to me that during
connection establishment, the remote Gutsy GDM now sends a response that
the local GDM (no
I do have the messages in /var/log/syslog that Grizzly mentioned, on the
local machine, if I use a local Gutsy to try to connect to remote Gutsy
with XDMCP from the GDM login screen (it always works using Xnest on the
local machine instead of GDM).
On reflection I believe this bug has been
Force-downgrading gdm to the version as at gutsy beta (2.20.0-0ubuntu2)
fixes the remote end for me - I can connect to it with other systems;
but it does not fix the client end (I still can't use XDMCP to connect
out from Gutsy).
--
Remote Login via XDMCP is not working in Ubuntu Gusty/7.10
I have come across this too, I believe. However, setting the remote
greeter to 'plain with facebrowser' instead of 'same as local' works
around the issue.
--
Remote Login via XDMCP is not working in Ubuntu Gusty/7.10
https://bugs.launchpad.net/bugs/150193
You received this bug notification
Cannot replicate my workaround on a different remote system, same local
system. May be a red herring.
--
Remote Login via XDMCP is not working in Ubuntu Gusty/7.10
https://bugs.launchpad.net/bugs/150193
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
16 matches
Mail list logo
