The patch referenced in post #17 won't correct this issue.
It's adding the following condition:
x"$DESKTOP_SESSION" = x"xfce"
However, that's not the value of DESKTOP_SESSION:
$ env | grep DESKTOP
DESKTOP_SESSION=xubuntu
XDG_SESSION_DESKTOP=xubuntu
XDG_CURRENT_DESKTOP=XFCE
A more correct check
Downloading the latest Debian build will only push this issue out. The
problem is that upstream (Jamie Zawinski) has added code that checks to
see if the current time is more than 12 months from when xscreensaver
was compiled. I can't seem to find the current revision control
repository for the U
Are the debian/rules changes from upstream? Near as I can tell, upstream
does not have a debian directory in its source tree:
https://chromium.googlesource.com/chromium/src.git/+/37.0.2062.120
Or are you referring to a different upstream?
--
You received this bug notification because you are a
It's not called out specifically in the change log. The existing
entries in the change log are very concerning for the 12.04 LTS update:
chromium-browser (37.0.2062.120-0ubuntu0.12.04.1~pkg917) precise-
security; urgency=medium
* Release to stage
chromium-browser (37.0.2062.120-0ubuntu1) UNRE
Yes, that is the same issue, this report would be the solution to that
issue.
The updated patches appear to correct the hanging issue. I've updated
my PPA builds with the latest patches.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to g
PPA builds with Ross Lagerwall's patches can be found here:
https://launchpad.net/~jcollins/+archive/gvfs
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/250517
Title:
gvfs performs slowl
The addition of sliding window support makes gvfs sftp transfers behave
more like openssh sftp file transfers, resulting a significant
throughput increase for connections with moderate to high latency (see
below).
The hang is being handled within one of the original bug reports, specifically:
http
Looks like there may be some issue with the patches as I have been able
to create reproducible hangs copying large (750M) files with the patched
GVFS packages. This has been reported upstream. Will update this
report when it's been resolved.
--
You received this bug notification because you are
Public bug reported:
Please pull the upstream patches for sliding window support from these bug
reports:
https://bugzilla.gnome.org/show_bug.cgi?id=523015
https://bugzilla.gnome.org/show_bug.cgi?id=532951
https://bugzilla.gnome.org/show_bug.cgi?id=711247
I've built packages with them already. T
For some reason this is working now, after a reboot. Not entirely sure
what's changed, or why it wasn't working before. Resolving.
** Changed in: policykit-desktop-privileges (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Desktop
Package
When prompted, the following appears in /var/log/auth.log:
Nov 5 08:43:23 odin polkitd(authority=local): Registered Authentication
Agent for unix-process:9487:464692 (system bus name :1.100 [udisksctl
mount -b /dev/mmcblk0p1], object path
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en
Public bug reported:
Similar reports to this were filed previously:
#1005643 & #1069234
While 1069234 was marked as a duplicate of 1005643, and 1005643 was
marked as resolved, this problem still exists with 13.10.
When attempting to mount any of my local volumes through a graphical
file manager
The attached script disconnects all currently attached bluetooth devices
on suspend, thus completely avoiding this bug.
Place the script in /etc/pm/sleep.d/10_bluetooth-input, and ensure that
its executable.
** Attachment added: "/etc/pm/sleep.d/10_bluetooth-input"
https://bugs.launchpad.net/
To be clear, this issue is present with any bluetooth connected evdev
input (keyboard or mouse) that is not disconnected prior to a suspend
resume cycle.
** Summary changed:
- Apple wireless bluetooth keyboard not working after suspend/resume
+ bluetooth keyboards and mice not working after suspe
This is a seriously annoying bug. I'm not sure this is reported against
the correct subsystem. This strikes me as more an evdev or udev issue
than a bluez issue.
To work around this for now, I've got a script that will disables any
xinput device with "mouse" in it's name.
** Attachment added: "
** Summary changed:
- network-manager becomes unresponsive, requiring a service restart
+ nm-applet becomes unresponsive, requiring a restart
** Description changed:
- After network-manager has been running for a while (overnight) it becomes
unresponsive:
+ After nm-applet has been running for
Should also be noted that simply killing nm-applet and restarting it are
sufficient to restore functionality:
killall nm-applet; sleep 1; nohup nm-applet &
** Bug watch added: GNOME Bug Tracker #691516
https://bugzilla.gnome.org/show_bug.cgi?id=691516
** Also affects: network-manager-applet v
All that is necessary to reproduce this bug is lots of changes in the
wireless networks seen by the system. Nothing more.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager-applet in Ubuntu.
https://bugs.launchpad.net/bugs/8
I'm also finding that alsa-hda-dkms won't install under 12.10 and need
it to solve #1064621.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1055238
Title:
PCI/internal sound card
The attached file is a very permissive work around for the issue, it
will allow local admins to do any of the potential udisk2 actions.
Simply place it in /var/lib/polkit-1/localauthority/50-local.d.
** Attachment added: "udisk2.pkla"
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utilit
Public bug reported:
With 12.10 it looks like gnome-disk-utility has moved to using udisks2
behind the scenes. However, it appears that polkit entries were not
created for most of the potential actions that can be taken within
gnome-disks. Many of the actions result in an error like the followin
Per the referenced site, nfs-lan does not appear to have support for
Nautilus 3.x
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-vfs2 in Ubuntu.
https://bugs.launchpad.net/bugs/29263
Title:
No nfs:// support
Status in Gnome VFS
For xbindkeys users, this bug is reported against Debian here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628654
The work around is to simply create a ~/.xbindkeys.noauto file (note the
leading period on the file name). This will prevent the Xsession
startup script from launching xbindkeys
Great logic. So, since cars and planes shouldn't crash perhaps we don't
need safety features developed for them? Seriously, this is faulty
logic. Software will from time to time crash. Sure, it shouldn't. But
if reasonable steps can be taken to prevent data loss, they should.
This doesn't real
24 matches
Mail list logo
