[Desktop-packages] [Bug 1636514] Re: nautilus crashed with SIGSEGV in gtk_tree_view_set_cursor_on_cell()

2016-12-09 Thread David B
I've had this bug when copying between a NFS mount and another NFS mount, or 
NFS mount and USB drive. The copy completes, but crashes nautilus.
I've tested a few scenarios and it only seems to occur across remote mounted 
file systems or usb mounted devices.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1636514

Title:
  nautilus crashed with SIGSEGV in gtk_tree_view_set_cursor_on_cell()

Status in Ubuntu GNOME:
  Invalid
Status in nautilus package in Ubuntu:
  Invalid

Bug description:
  This crash occurred just after I had asked Nautilus to move several
  large files (in groups) to several different locations. Then I believe
  that I minimized Nautilus and in a few minutes noticed the crash.

  ProblemType: Crash
  DistroRelease: Ubuntu 16.10
  Package: nautilus 1:3.22.1-1ubuntu0~yakkety2 [origin: 
LP-PPA-gnome3-team-gnome3-staging]
  ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
  Uname: Linux 4.8.0-26-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Oct 25 13:52:09 2016
  ExecutablePath: /usr/bin/nautilus
  InstallationDate: Installed on 2016-05-15 (162 days ago)
  InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Release amd64 
(20151021)
  ProcCmdline: nautilus .
  Signal: 11
  SourcePackage: nautilus
  StacktraceTop:
   ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
   ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
   gtk_tree_view_set_cursor_on_cell () from 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
   ?? ()
   ?? ()
  Title: nautilus crashed with SIGSEGV in gtk_tree_view_set_cursor_on_cell()
  UpgradeStatus: Upgraded to yakkety on 2016-10-19 (5 days ago)
  UserGroups: adm cdrom dip libvirt libvirtd lpadmin plugdev sambashare sudo
  usr_lib_nautilus:
   dropbox2015.10.28
   gnome-terminal 3.20.2-1ubuntu5

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-gnome/+bug/1636514/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1493888] Re: FGLRX incompatible with gcc 5

2015-11-08 Thread David B Yentzen
Thanks to all who reported, worked on, and fixed this bug! I've been waiting on 
this fix release and using the open source driver for my AMD/ATI:Carrizo.  
Without enabling 'Wily proposed', I've notice the video driver for the AMD 
graphics from fglrx-updates(proprietary) has moved up in the additional drivers 
GUI since the fix was released. Does this mean I can now try to use 
fglrx-updates in place of the open source  without enabling 'Wily proposed'?
Using: AMD A10-8700P Radeon R6

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to fglrx-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1493888

Title:
  FGLRX incompatible with gcc 5

Status in Release Notes for Ubuntu:
  Fix Released
Status in fglrx-installer package in Ubuntu:
  Fix Released
Status in fglrx-installer source package in Wily:
  Fix Released

Bug description:
  SRU Request:

  [Impact]

  The fglrx driver is not compatible with gcc 5.x. This causes the
  kernel module to crash on initialisation. As a result, users will boot
  into a black screen, as X will fail (except on Intel+AMD hybrid
  systems, where intel is used).

  [Test Case]
  1. Either install (or upgrade to) Ubuntu 15.10 and fglrx
  2. Reboot
  3. Check the display, and the output of the "dmesg | grep fglrx" command (to 
see the actual crash)

  Expected results: the system should be able to start X correctly.

  Actual results:
  The kernel module fails and X doesn't start.

  [Regression Potential]
  Low. Forcing fglrx to use gcc 4.9 is only a temporary workaround, and will be 
replaced with the proper fix once AMD makes it available.


  __

  With a R9 280 and FGLRX on ubuntu 15.10 the graphics lock up. I am
  able to SSH into the machine. I booted the older kernel
  (4.1.0-3-generic) and it works with FGLRX. After purging FGLRX and
  using xserver-xorg-video-radeon I am able to get the graphics working,
  but even it has issues with my display port (The DVI ports are working
  correctly).

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: fglrx (not installed)
  ProcVersionSignature: Ubuntu 4.2.0-7.7-generic 4.2.0
  Uname: Linux 4.2.0-7-generic x86_64
  ApportVersion: 2.18-0ubuntu9
  Architecture: amd64
  Date: Wed Sep  9 09:29:54 2015
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2011-01-07 (1705 days ago)
  InstallationMedia: Kubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
  ProcEnviron:
   LANGUAGE=
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: fglrx-installer
  UpgradeStatus: Upgraded to wily on 2015-08-18 (21 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1493888/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1502370] [NEW] Unity does not send UnmapNotify event when window is iconified

2015-10-02 Thread David B
Public bug reported:

To reproduce this bug, run "wish" in a terminal window.  Here's what I did in 
wish:
> wish
% wm tracing 1
% wm iconify .
WaitForMapNotify giving up on .
WaitForMapNotify finished with . (winPtr 0x1af3a50, wmPtr 0x1af3850)
% wm state .
normal
% wm deiconify .
% 

Three symptoms can be seen in the wish session:
 1. wish should not report "WaitForMapNotify giving up on ."
 2. After the "wm iconify ." command, the window disappears; however, the "wm 
state ." should report "iconic" instead of "normal".
 3. The "wm deiconify ." command should make the window reappear, but it does 
not.

I'm struggling with whether this is a Unity bug or a Tk bug.  The problem is 
exhibited under Unity and Gnome Shell, but does not occur under fvwm2 (I ran 
the test under all 3 window managers on the same system).  Under fvwm2:
 1. wish does not report "WaitForMapNotify giving up on ."
 2) The "wm state ." command correctly returns "iconic".
 3) The "wm deiconify ." command correctly makes the window reappear.

Under Gnome Shell and fvwm2, I was able to run "xtrace wish", and repeat the 
session to watch the X11 events (I got a SEGV when I tried this under Unity and 
I filed a bug).  Under Gnome Shell, the xtrace info looks like this:
000:<:0092: 24: Request(16): InternAtom only-if-exists=false(0x00) 
name='WM_CHANGE_STATE'
000:>:0092:32: Reply to InternAtom: atom=0x1dc("WM_CHANGE_STATE")
000:<:0093: 44: Request(25): SendEvent propagate=false(0x00) 
destination=0x009b event-mask=SubstructureNotify,SubstructureRedirect 
ClientMessage(33) format=0x20 window=0x0186 type=0x1dc("WM_CHANGE_STATE") 
data=0x03,0x00,0x00,0x00,0xf0,0x71,0xd0,0x00,0x28,0x3e,0xc4,0x00,0x00,0x00,0x00,0x00,0x06,0x00,0x80,0x01;
000:>:0093: Event PropertyNotify(28) window=0x0186 
atom=0x185(unrecognized atom) time=0x04931165 state=NewValue(0x00)
000:>:0093: Event PropertyNotify(28) window=0x0186 
atom=0x15c("_NET_WM_STATE") time=0x04931165 state=NewValue(0x00)
000:<:0094: 24: Request(20): GetProperty delete=false(0x00) 
window=0x0186 property=0x15c("_NET_WM_STATE") type=0x4("ATOM") 
long-offset=0x long-length=0x0400
000:>:0094:36: Reply to GetProperty: type=0x4("ATOM") 
bytes-after=0x data=;

Under fvwm2, the xtrace info looks like this:
000:<:008b: 24: Request(16): InternAtom only-if-exists=false(0x00) 
name='WM_CHANGE_STATE'
000:>:008b:32: Reply to InternAtom: atom=0x1b1("WM_CHANGE_STATE")
000:<:008c: 44: Request(25): SendEvent propagate=false(0x00) 
destination=0x009b event-mask=SubstructureNotify,SubstructureRedirect 
ClientMessage(33) format=0x20 window=0x01c6 type=0x1b1("WM_CHANGE_STATE") 
data=0x03,0x00,0x00,0x00,0xa0,0x7c,0x34,0x02,0x28,0xce,0x13,0x02,0x00,0x00,0x00,0x00,0x06,0x00,0xc0,0x01;
000:>:008c: Event UnmapNotify(18) event=0x01c6 window=0x01c6 
from-configure=false(0x00)
000:>:008c: Event PropertyNotify(28) window=0x01c6 
atom=0x185(unrecognized atom) time=0x04aa349c state=NewValue(0x00)
000:<:008d:  8: Request(10): UnmapWindow window=0x01c5
000:>:008d: Event PropertyNotify(28) window=0x01c6 
atom=0x15c("_NET_WM_STATE") time=0x04aa349d state=NewValue(0x00)
000:<:008e:  4: Request(127): NoOperation 
000:<:008f: 24: Request(20): GetProperty delete=false(0x00) 
window=0x01c6 property=0x15c("_NET_WM_STATE") type=0x4("ATOM") 
long-offset=0x long-length=0x0400
000:>:008f:36: Reply to GetProperty: type=0x4("ATOM") 
bytes-after=0x data=;

Note that fvwm2 returns the UnmapNotify event to the client (in response
to the ClientMessage event), but Gnome Shell (and presumably Unity)
doesn't.  As a result, wish does not send the UnmapWindow request to the
window manager under Gnome Shell.

The ICCCM (section 4.1.4) says "Clients can select for StructureNotify
on their top-level windows to track transitions between Normal and
Iconic states. Receipt of a MapNotify event will indicate a transition
to the Normal state, and receipt of an UnmapNotify event will indicate a
transition to the Iconic state.

The relevant Tk code is in the tk8.6 source package
(http://packages.ubuntu.com/source/trusty/tk8.6).  At the bottom of
unix/tkUnixWm.c the TkpWmSetState() function calls XIconifyWindow(),
followed by WaitForMapNotify().  It is WaitForMapNotify() that prints
out the message that it is giving up.  There's an interesting  comment
in WaitForMapNotify() that says "There are some bizarre situations in
which the window manager can't respond or chooses not to (e.g. if we've
got a grab set it can't respond).  If this happens, then just quit."
The problem is that just quitting leaves Tk  with an incorrect
impression of the window's state.  Under fvwm2, the UnmapNotify event
causes Tk to call XUnmapWindow(), which seems to straighten things out.

As I previously said, I'm torn on whether this is a Tk bug or a
Unity/Gnome Shell bug.  Since both Unity and Gnome Shell get the same
answer, and WaitFo

[Desktop-packages] [Bug 887821] Re: "Show copy dialog" right click launcher entry doesn't work (on nautilus copy)

2013-10-23 Thread David B
This should be backported to 12.04 (you know, the stable LTS ubuntu).
It's a serious user experience bug. I accidentally hit show desktop (why does 
alt-tab even have "show desktop" by included by default??), only to have my 
large file transfer irretrievably disappear. Wacky behaviour like this puts 
people right off Unity.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/887821

Title:
  "Show copy dialog" right click launcher entry doesn't work (on
  nautilus copy)

Status in Unity:
  Fix Released
Status in Unity 5.0 series:
  Won't Fix
Status in Unity 6.0 series:
  New
Status in “nautilus” package in Ubuntu:
  Fix Released
Status in “unity” package in Ubuntu:
  Fix Released
Status in “nautilus” source package in Precise:
  Fix Committed
Status in “unity” source package in Precise:
  Invalid

Bug description:
  Impact:
  the nautilus copy dialog don't get properly focussed by unity

  Test Case:
  - log into an unity session
  - copy a not too small file (so you have time to interact with the copy 
dialog)
  - minimize the copy dialog
  - right click on the corresponding unity-launcher's icon, and pick "show copy 
dialog"
  -> the dialog should be displayed

  Regression testing:
  Check that there is no focus issue with that dialog and the launcher

  --

  While copying a large (8 gig) file across an SMB network, I minimized
  it.  The right click on the Nautilus Unity bar showed a "Show copy
  dialog" item.  Clicking on that item did nothing.  The only way to get
  the dialog back up was to open one of the two minimized Nautilus
  windows and then minimize the one on top.  After that minimize, then
  the copy dialog was displayed on top of the other Nautilus window.  I
  couldn't find any way to get the copy dialog back on screen without
  clicking around somewhat aimlessly displaying and minimizing Nautilus
  windows until it appeared.  The "Show copy dialog" right-click menu
  appeared to have no affect.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: nautilus 1:3.2.1-0ubuntu2
  ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
  Uname: Linux 3.0.0-12-generic x86_64
  NonfreeKernelModules: wl fglrx
  ApportVersion: 1.23-0ubuntu4
  Architecture: amd64
  Date: Tue Nov  8 18:12:10 2011
  ExecutablePath: /usr/bin/nautilus
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/887821/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp